Лонгрид · сентябрь 2026 · @tk_3826

После вайб-кодинга: как управлять агентами, циклами и ИИ-командой в Codex

Практическое пособие по Codex: проверяемые циклы, субагенты, состав ИИ-команды, критерии достаточности и экономия токенов.

Вайб-кодинг обычно начинается с приятного открытия: задачу, для которой раньше требовался программист, можно описать обычными словами — и получить работающий файл, сайт, сценарий или автоматизацию. Следующая ступень выглядит заманчиво: собрать «команду» из архитектора, исследователя, разработчика, критика и тестировщика, а потом отойти в сторону.

Но индустрия сейчас сходится не на лозунге «больше агентов», а на более трезвой формуле:

Сначала один агент и проверяемый цикл. Затем — субагенты только там, где разделение работы даёт измеримую пользу.

Это важный поворот. Рост начинается не тогда, когда в интерфейсе появилось семь цифровых сотрудников, а когда у работы появились цель, внешняя проверка, границы, право на остановку и понятный следующий шаг. 🧭 Агентность без этих вещей — не команда, а дорогая импровизация.

Пять понятий, которые не надо смешивать

Агент

Агент — это не просто чат с моделью. OpenAI определяет агента как систему, которая самостоятельно выполняет задачи с помощью модели, инструментов и инструкций. Такой агент получает цель, выбирает следующие действия, читает файлы, запускает команды, работает с браузером и проверяет результат.

Codex в отдельной задаче — именно такой агент. Он не только отвечает текстом, но и может исследовать проект, менять файлы, запускать проверки и возвращаться к ошибке.

Цикл

Цикл — повторяющаяся последовательность:

1. понять ближайшее наблюдаемое поведение;
2. установить способ проверки;
3. сделать минимальное изменение;
4. запустить проверку;
5. исправить или закрепить результат;
6. решить, продолжать ли дальше.

Модель внутри агента тоже работает циклом: оценивает состояние, выбирает действие, получает результат инструмента и снова оценивает состояние. Но пользователю важнее внешний цикл — тот, в котором успех подтверждается не словами агента, а тестом, скриншотом, открывшейся страницей, совпавшей суммой, найденной записью или другим наблюдаемым фактом.

Луп-инжиниринг

«Луп-инжиниринг» — полезное рабочее название, а не строгий отраслевой стандарт. Это проектирование самого цикла обратной связи: что агент меняет, что ему разрешено не менять, какой сигнал считается улучшением, когда результат откатывается и при каком условии работа прекращается.

Андрей Карпати, исследователь ИИ, показал в проекте autoresearch цикл «изменить один файл → запустить короткий эксперимент → измерить результат → сохранить улучшение или отбросить неудачу». Человек задаёт программу исследования и фиксированный измеритель. Ключевой объект здесь не промпт и не модель, а контур с неизменяемым измерителем.

В бытовой задаче роль метрики может выполнять не число. Для таблицы это совпадение итогов с контрольным примером. Для сайта — скриншоты на компьютере и телефоне плюс отсутствие ошибок и горизонтальной прокрутки. Для разбора документов — список утверждений с прямыми ссылками на первоисточники.

Субагент

Субагент — отдельный агент, которому главный агент делегировал ограниченную часть текущей работы. В Codex работа субагента идёт в отдельном потоке, который можно открыть, проверить, направить или остановить. Субагент получает собственный контекст и расходует собственные токены.

Например, главный агент может поручить одному субагенту найти все места, где используется функция, второму — проверить документацию, а затем сам сопоставить результаты. Это полезная параллельная разведка. Если же оба одновременно переписывают один и тот же файл, возникает конкуренция правок и польза быстро исчезает.

Команда и «рой»

Команда агентов — заранее выбранные роли, границы и порядок передачи результата. «Роем» часто называют более динамический вариант: главный агент создаёт исполнителей по мере необходимости, они исследуют разные направления, возвращают сжатые отчёты, после чего координатор решает, кого вызвать дальше.

Поэтому субагент и рой — не одно и то же. Субагент — единица делегирования. Рой — способ организовать множество таких единиц. Команда может состоять всего из двух агентов и не быть роем. Один агент может создать пару субагентов на пять минут и не превращать проект в постоянную организацию.

Что на самом деле советуют лидеры индустрии

Здесь важно не приписывать руководителям компаний то, чего они не говорили. Прогнозы Альтмана и Амодея задают направление, а конкретные правила ниже взяты прежде всего из инженерных публикаций OpenAI и Anthropic, публичных экспериментов Карпати и Мартина и документации Codex.

Сэм Альтман, руководитель OpenAI, описывает приход агентов в рабочую среду как один из ближайших этапов развития ИИ. Это стратегическое направление: всё больше задач будет выполняться программами, способными действовать, а не только отвечать. Но из этого не следует, что каждую заметку нужно отдавать «отделу» из семи моделей.

Дарио Амодей, руководитель Anthropic, предупреждает, что ИИ надо встраивать в рабочий процесс целиком, а не добавлять к нему отдельной кнопкой. Инженеры Anthropic при этом советуют начинать с простого и добавлять агентную сложность только тогда, когда она доказуемо улучшает результат. Открытый агент оправдан там, где заранее неизвестно количество шагов.

В исследовательской системе Anthropic главный агент распределяет независимые направления между субагентами, а затем сводит их ответы. На внутренних оценках это дало сильный прирост качества, но потребовало примерно в пятнадцать раз больше токенов, чем обычный чат. Сами авторы подчёркивают: схема хороша для задач, где можно параллельно исследовать широкое пространство, и гораздо слабее для тесно связанных задач, где всем нужен один и тот же постоянно меняющийся контекст.

Карпати даёт самый прикладной урок: зафиксируйте измеритель, меняйте по одному существенному элементу, ведите журнал попыток и не разрешайте агенту переписывать правила оценки ради красивого результата.

Роберт Мартин, инженер и автор книг о чистом коде, в экспериментальном проекте swarm-forge связывает размер команды с размером задачи и распределяет между ролями отдельные этапы контроля качества. Для небольшой серверной работы у него достаточно пары «разработчик — чистильщик», для средней добавляются постановщик и архитектор, для большой — усиление и приёмка. Это не универсальный стандарт для любого проекта. Ценность примера в том, что каждая новая роль получает отдельный контроль качества, а не ещё одно мнение о том же самом.

Мартин Фаулер, автор работ об архитектуре программ, добавляет полезную поправку к моде на обязательный TDD — разработку через тесты. Небольшой эксперимент Thoughtworks не показал устойчивого преимущества обязательного TDD для качества, зато расход токенов вырос более чем втрое. Вывод для новичка: не поклоняйтесь ритуалу, но всегда создавайте независимый датчик качества — контрольный пример, тест, валидатор, рецензию или наблюдаемое условие приёмки.

Наконец, исследование Anthropic по сотням тысяч сессий Claude Code показало, что пользователи чаще оставляют за собой решения о планировании, а агенту передают исполнение. Для людей без ИТ-профессии это особенно важно: предметная экспертиза — понимание своей бухгалтерии, склада, монтажа, поездки или документооборота — часто важнее умения писать код. Вы отвечаете за что, зачем и как проверить. Агент может взять на себя значительную часть как сделать.

Следующая ступень: не команда, а управляемый цикл

У начинающего есть соблазн компенсировать неясную задачу количеством ролей. Это работает наоборот: неясность размножается. Пять агентов получают пять версий того, что вы имели в виду, а координатор уверенно склеивает их в шестую.

Надёжная лестница выглядит так.

1. Ступень 0
   Обычный инструмент — когда правила полностью определены.
2. Ступени 1–2
   Один агент в проверяемом цикле — базовый рабочий режим.
3. Ступень 3
   Независимый проверяющий — первый полезный субагент.
4. Ступень 4
   Параллельная разведка — несколько независимых направлений чтения.
5. Ступень 5
   Постоянные роли — только для повторяющегося процесса.

Ступень 0. Обычный инструмент

Если задача полностью определяется правилами, агент не нужен. Переименовать сто файлов по точному шаблону, сложить столбец, заменить одинаковую строку — это скрипт, формула или встроенная функция. OpenAI прямо рекомендует сначала проверить, не достаточно ли обычного детерминированного решения.

Ступень 1. Один агент, один результат

Дайте Codex цель, контекст, ограничения и критерий готовности. Попросите сначала изучить существующее состояние, затем сделать изменение и показать проверку.

Для первого рабочего промпта достаточно четырёх блоков:

• цель — что должно измениться для человека;
• контекст — где лежат материалы и что уже известно;
• ограничения — что нельзя трогать, публиковать, удалять или раскрывать;
• готово, когда — какой внешний факт закроет задачу.

Ступень 2. Один агент в цикле

Добавьте датчик до изменения. Для ошибки попросите сначала воспроизвести её. Для файла — сделать копию или работать в новой версии. Для сайта — зафиксировать исходный скриншот и проверить два размера экрана после правки. Для исследования — заранее определить, какие источники считаются первичными.

Если две попытки ломаются одинаково, не просите «попробуй ещё раз». Остановите повторение и поменяйте контур: уточните критерий, дайте пример, добавьте инструмент, разделите задачу или ограничьте область поиска.

Ступень 3. Независимая проверка

Первый действительно полезный субагент — часто не второй исполнитель, а проверяющий. Он не должен верить отчёту автора. Он получает исходные требования, готовый результат и команду искать конкретные нарушения.

Так появляется простая связка:

• основной агент делает;
• проверяющий пытается опровергнуть готовность;
• основной агент исправляет подтверждённые замечания;
• финальный датчик запускается ещё раз.

Ступень 4. Параллельная разведка

Подключайте несколько субагентов, когда работу можно разрезать на независимые вопросы. Например:

• один изучает текущие файлы и ограничения;
• второй сверяет официальную документацию;
• третий составляет набор крайних случаев;
• главный агент синтезирует решение.

Это лучший ранний сценарий для команды: много чтения, мало конфликтующих записей.

Ступень 5. Постоянные роли

Создавать постоянных пользовательских агентов стоит только после повторения одного и того же рабочего процесса. Если вы уже несколько раз вручную объяснили Codex, как проверять источники, оформлять результат и где нельзя вносить изменения, эти устойчивые правила можно вынести в файл AGENTS.md, который Codex загружает перед началом работы, в навык или конфигурацию агента.

Не начинайте с организационной схемы. Начинайте с повторяющейся ошибки или устойчивого узкого места.

Когда команда действительно нужна

Команда оправдана, если выполняются хотя бы два-три условия:

• задачу можно разделить на независимые направления;
• нужно сравнить несколько гипотез или источников;
• объём материалов не помещается в удобный контекст одного агента;
• требуется независимый критик, безопасность или приёмка;
• у частей работы разные инструменты и границы доступа;
• задача достаточно ценная, чтобы оправдать дополнительное время и токены;
• результат каждого участника можно описать коротким форматом передачи.

Хороший признак: вы можете написать для каждого участника отдельную цель, отдельный результат и условие остановки, не пересказывая ему весь проект.

Когда команда избыточна

Оставляйте одного агента, если:

• работа линейная и следующий шаг зависит от предыдущего;
• меняется один небольшой файл или один документ;
• всем «ролям» нужен один и тот же полный контекст;
• несколько исполнителей будут писать в одну область;
• нет способа независимо проверить результат;
• роль существует только ради красивого названия;
• координация займёт больше времени, чем сама задача;
• ошибка рискованна, а границы доступа и человеческое подтверждение ещё не настроены.

⚠️ Самый опасный случай — автономная команда без внешнего критерия готовности. Она может долго и убедительно улучшать собственную версию задачи, всё дальше уходя от вашей.

Как определить состав ИИ-команды

Состав выводится не из списка профессий, а из структуры риска.

Один агент

Для понятной, обратимой работы с одним артефактом: исправить формулу, подготовить письмо, собрать одностраничный сайт, обработать папку по правилам.

Пара: исполнитель и проверяющий

Лучший старт для важной работы. Проверяющий нужен, если ошибка не очевидна сразу: финансовые расчёты, публикация, автоматизация, изменение множества файлов.

Тройка: исследователь, исполнитель, проверяющий

Подходит, когда сначала надо понять незнакомую систему или сверить свежие правила. Исследователь возвращает факты и ограничения, исполнитель меняет систему, проверяющий оценивает результат по исходным критериям.

Координатор и несколько исследователей

Подходит для обзоров рынка, юридической разведки, большого массива документов, поиска разных технических решений. Исследователи получают непересекающиеся направления и одинаковый формат отчёта: вывод, доказательство, источник, уверенность, открытый вопрос.

Несколько параллельных исполнителей

Это уже продвинутый режим. Разносите исполнителей по независимым папкам или веткам. В Codex рабочие деревья Git позволяют нескольким задачам работать с одним проектом без столкновения файлов. Слияние всё равно требует отдельной проверки.

Практическое правило: начните с минимальной команды, которая закрывает разные риски. Обычно это два или три участника, а не семь.

• Главный агент
• Исследователь
• Исполнитель
• Проверяющий

Как это выглядит в интерфейсе Codex

1. Сначала включите режим Plan

Для сложной задачи начните с режима планирования, чтобы отделить решение «что делаем» от массовых изменений. В Codex он открывается командой /plan или переключением режима в поле ввода. Попросите агента исследовать проект, задать только блокирующие вопросы и предложить проверяемые этапы.

2. Поручите делегирование обычными словами

Codex поддерживает субагентов по умолчанию. Можно написать:

Исследуй задачу. Если есть два действительно независимых направления, запусти не более двух субагентов параллельно. Дай каждому узкую цель, границы файлов, формат ответа и условие остановки. Не разрешай параллельную запись в одни файлы. Дождись результатов и синтезируй одно решение.

В приложении работа субагентов видна отдельными потоками. Их можно открыть и проверить. В CLI для переключения между потоками используется /agent. Если субагент ушёл в сторону, его лучше остановить или перенаправить, а не надеяться, что координатор сам исправит отклонение в финале.

3. Зафиксируйте проектные правила в AGENTS.md

Codex читает AGENTS.md перед работой в проекте и объединяет глобальные и локальные инструкции. Туда полезно поместить команды проверки, структуру папок, запреты на публикацию и удаление, правила секретов, формат журнала и критерии завершения. Не превращайте файл в энциклопедию: добавляйте устойчивые правила, особенно после повторяющихся ошибок.

4. Разделяйте параллельную запись

Если несколько задач должны менять код одновременно, создавайте отдельные задачи Codex в рабочих деревьях. Если работа идёт внутри одного запроса, оставьте субагентам чтение, анализ и проверки, а запись сведите к одному владельцу файлов.

5. Проверяйте изменения, а не итоговый рассказ

Откройте панель изменений Codex, просмотрите разницу, запустите ближайший тест и затем более широкую приёмку. Формулировка «всё готово» — отчёт, а не доказательство.

Как экономить токены разными моделями

Токен — небольшой фрагмент текста или кода, который модель читает или создаёт. Вы платите не за количество «сотрудников» на экране, а за суммарную работу их отдельных контекстов: чтение, рассуждение, вызовы инструментов и ответы.

OpenAI рекомендует сначала построить эталон качества на сильной модели и только затем передавать проверенные шаги более быстрым и дешёвым моделям. Иначе экономия неотличима от незамеченного ухудшения.

Рабочая схема для Codex:

• сильная модель — координатор, сложное решение, архитектурный риск и финальный синтез;
• сбалансированная модель — изучение проекта, обычная реализация, запуск проверок;
• быстрая модель — узкий поиск, классификация, извлечение данных, повторяемые проверки;
• повышенное рассуждение — проверяющий, крайние случаи, неоднозначная диагностика;
• обычное или низкое рассуждение — чёткие механические задачи.

На момент публикации Codex предлагает GPT‑5.6 для требовательных ролей, terra для быстрых задач с большим чтением, а luna для узких повторяемых поручений. Названия моделей будут меняться; принцип останется. После накопления собственных проверок даже координатора можно заменить более дешёвой моделью, если его маршрутизация действительно проста и качество не падает.

Экономия чаще достигается не выбором модели, а устройством процесса:

• не запускайте несколько агентов «на всякий случай»;
• не передавайте каждому весь архив проекта;
• требуйте короткий структурированный отчёт вместо дневника действий;
• выносите сортировку, фильтрацию и подсчёты в обычный код;
• ограничивайте число субагентов и глубину делегирования;
• прекращайте цикл сразу после выполнения критериев;
• повторно используйте проверку, а не заново обсуждайте качество словами.

Готовый стартовый промпт проекта

Ниже не ролевая декорация, а договор о работе. Его можно вставить в новую задачу Codex и заменить квадратные скобки.

Цель проекта

[Какой наблюдаемый результат нужен человеку и зачем.]

Исходное состояние

[Где находятся файлы, документы, ссылки и примеры. Что уже работает.]

Границы

• Не меняй: [папки, данные, настройки].
• Не публикуй, не отправляй сообщения, не покупай и не удаляй без моего явного подтверждения.
• Секреты не показывай и не записывай в обычные файлы.

Готово, когда

1. [Проверяемый результат №1.]
2. [Проверяемый результат №2.]
3. [Какая проверка, скриншот, контрольный пример или отчёт подтверждает готовность.]

Рабочий цикл

1. Сначала изучи текущее состояние и зафиксируй исходный сигнал.
2. Предложи самый маленький законченный этап.
3. Сделай минимальное изменение.
4. Запусти ближайшую проверку, затем общую приёмку.
5. Исправь подтверждённые нарушения и повтори ту же проверку.
6. После двух одинаковых неудач остановись, назови недостающее условие и измени подход, а не повторяй попытку.
7. Заверши, когда критерии выполнены; перечисли доказательства и остаточные риски.

Политика команды

• По умолчанию работай одним агентом.
• Субагентов подключай только для независимого исследования, отдельной проверки или изолированной области файлов.
• Одновременно не более [2] субагентов.
• Перед запуском объясни разделение: цель, границы, формат результата, условие остановки.
• Не разрешай двум агентам одновременно менять одни файлы.
• Для параллельной записи используй отдельные рабочие деревья.
• Главный агент отвечает за синтез и финальную проверку.

Право на остановку

Остановись и запроси решение, если требуется публикация, платное действие, необратимое удаление, новый доступ, раскрытие данных или изменение исходной цели.

В простом проекте раздел «Политика команды» можно сократить до одной строки: «Работай одним агентом; подключи одного проверяющего только перед финалом».

Проверка устойчивости перед запуском

Пройдите семь вопросов. Если на два из них нет ответа, команда пока преждевременна.

1. Можно ли увидеть готовность без доверия к словам агента?
2. Что агенту запрещено менять?
3. Кто владеет каждым изменяемым файлом или артефактом?
4. Что субагент вернёт координатору — пять пунктов или весь сырой контекст?
5. Когда цикл обязан остановиться?
6. Какие действия требуют подтверждения человека?
7. Что произойдёт, если агент дважды повторит одну ошибку?

Минимальные предохранители просты: один владелец записи, фиксированный датчик, лимит параллельности, короткий формат передачи, журнал попыток и человеческое подтверждение перед внешним или необратимым действием. После настройки проверьте те же сценарии ещё раз: два агента не пишут в один файл, неудача не зацикливается, публикация не происходит автоматически, секреты не попадают в отчёт.

Практика на первой неделе

Не начинайте с роя. Возьмите реальную задачу на один-два часа и пройдите три опыта.

Опыт 1. Один агент. Дайте Codex цель, границы и три критерия готовности. Попросите показать внешний сигнал до и после изменения.

Опыт 2. Агент плюс проверяющий. После результата запустите одного субагента с исходными требованиями и задачей найти нарушения. Сравните, обнаружил ли он то, что пропустили вы и основной агент.

Опыт 3. Два исследователя. Разделите только чтение: один изучает ваши материалы, другой — официальные источники. Попросите вернуть одинаковую таблицу «факт — доказательство — уверенность — открытый вопрос». Пусть главный агент соберёт решение.

Запишите три показателя: время, расход токенов и число реально найденных ошибок. Если команда не улучшила хотя бы один важный показатель без неприемлемого ухудшения остальных, вернитесь к одному агенту.

Главное правило

Следующая ступень после вайб-кодинга — не «рой». Это переход от просьбы сделай красиво к управляемой системе:

цель → внешний датчик → минимальное действие → проверка → решение о следующем шаге.

Один агент в хорошем цикле обычно сильнее семи агентов без критерия готовности. Субагент полезен, когда у него есть отдельная работа или независимый взгляд. Команда появляется не из желания выглядеть технологично, а из доказанной необходимости разделить контекст, риск или ответственность.

Именно это сегодня объединяет практические советы OpenAI, Anthropic, Карпати, Мартина и Фаулера: усложняйте систему после того, как простая перестала справляться, и заставляйте каждое усложнение доказывать свою ценность.