Примечание редактора: способ использования AI-кодирующих агентов меняется с «ручного написания промптов человеком и пошагового продвижения задач» на «проектирование человеком циклов, которые позволяют системе непрерывно управлять агентом». Loop Engineering (цикловая инженерия), о которой говорит Addy Osmani, заключается в создании рабочего процесса, способного автоматически обнаруживать задачи, распределять их, проверять результаты, фиксировать прогресс и определять следующие шаги.

Этот цикл в целом состоит из пяти модулей: Automations (автоматическое обнаружение и триажирование задач по расписанию), Worktrees (изоляция нескольких параллельных сред разработки), Skills (накопление знаний о проекте и командных соглашений), Plugins/Connectors (интеграция с реальными инструментами, такими как GitHub, Linear, Slack, базы данных), Sub-agents (разделение исполнителя и рецензента), а также внешний слой памяти, например, файлы Markdown или доска Linear, для сохранения состояния и прогресса.

В статье отмечается, что смысл Loop Engineering не только в том, чтобы «запустить ИИ на несколько больше итераций», а в том, чтобы заранее заложить инженерную экспертизу в дизайн системы. Циклы могут значительно увеличить рычаг разработчика, но не заменят проверку, понимание и принятие решений. Настоящий риск заключается не в использовании циклов, а в том, чтобы использовать их как предлог для избегания понимания кода и системы. Ключевой компетенцией для сотрудничества с ИИ в программировании в будущем, возможно, станет не умение написать хороший промпт, а проектирование надежных, проверяемых и устойчиво работающих рабочих процессов агентов.

Далее следует оригинальный текст:

Loop engineering (цикловая инженерия) заменяет вашу роль «человека, пишущего промпты для агента». Вы проектируете систему, которая будет давать промпты агенту вместо вас. Здесь loop (цикл) можно понимать как рекурсивную цель: вы определяете задачу, а ИИ продолжает итерации, пока она не будет выполнена. Он состоит примерно из пяти компонентов, и как Claude Code, так и Codex теперь обладают всеми пятью.

Я считаю, что, возможно, именно так мы будем сотрудничать с кодирующими агентами в будущем. Однако все это находится на ранней стадии, и я сохраняю скептицизм. Безусловно, нужно осторожно относиться к стоимости токенов, так как в зависимости от модели использования она может сильно различаться, особенно если вы «богаты токенами» или «испытываете их нехватку». Также нужен какой-то механизм, гарантирующий, что качество не ухудшится. Опасения по поводу «ИИ-хлама» (slop) тоже обоснованны. Тем не менее, давайте посмотрим, что это такое.

@steipete недавно сказал: «Вам больше не следует писать промпты для кодирующих агентов. Вам следует проектировать циклы, которые будут давать промпты вашему агенту». Аналогично, руководитель Claude Code в Anthropic @bcherny сказал: «Я больше не промптю Claude. У меня запущена куча циклов, которые промптят Claude и сами решают, что делать дальше. Моя работа — писать циклы».

Так что же это значит?

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

Теперь вы строите небольшую систему: она сама находит работу, распределяет задачи, проверяет результаты, фиксирует выполнение и решает, что делать дальше. То есть вы поручаете системе управлять агентом, а не лично снова и снова давать ему промпты. Я раньше писал о его «близком родственнике» — agent harness engineering (инженерия обвязки агента), то есть о создании среды выполнения для одного агента; а также о factory model (фабричной модели), то есть о системе, которая строит ПО. Loop engineering находится на уровень выше обвязки. Он похож на обвязку, но работает по таймеру, создает помощников и сам себя подпитывает.

Меня удивило, что теперь это уже не проблема «уровня инструментов». Год назад, если бы вы хотели цикл, вам пришлось бы писать кучу bash-скриптов и вечно их поддерживать. Это была ваша собственная вещь, только для вас. Теперь эти компоненты встроены прямо в продукты. Способности, перечисленные Штайнбергером, почти один в один соответствуют таковым в приложении Codex и почти так же в Claude Code. Как только вы осознаете, что их структура одинакова, вы перестанете ломать голову над тем, какой инструмент использовать, и начнете проектировать цикл: в каком бы инструменте вы ни работали, он продолжит работать.

Пять компонентов и некоторые пояснения

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

1. Automations (Автоматизации): запускаются по расписанию, автоматически выполняют обнаружение и триажирование.

2. Worktrees (Рабочие деревья): позволяют двум параллельно работающим агентам не наступать на файлы друг друга.

3. Skills (Навыки): записывают знания о проекте, чтобы агенту не приходилось каждый раз угадывать.

4. Plugins and connectors (Плагины и коннекторы): позволяют агенту подключаться к инструментам, которые вы уже используете.

5. Sub-agents (Суб-агенты): один предлагает решение, другой — проверяет его.

И шестая вещь: memory (память). Это может быть файл Markdown, доска Linear или любое место, независимое от отдельного диалога, способное хранить «сделанное» и «следующие шаги». Звучит настолько просто, что кажется неважным, но это тот же самый прием, от которого зависит каждый долгоживущий агент. Я подробно писал об этом в long-running agents: модель забывает между запусками, поэтому память должна храниться на диске, а не в контексте. Агент забывает, но репозиторий — нет.

Теперь обе эти возможности есть в двух продуктах.

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

Automations: это сердцебиение цикла

Automations — это то, что делает цикл настоящим циклом, а не разовой задачей, которую вы однажды запустили вручную. В приложении Codex вы можете создать автоматизацию на вкладке Automations, выбрать проект, промпт для запуска, частоту выполнения, а также будет ли она выполняться в вашей локальной копии или в фоновом worktree. Результаты запусков, обнаружившие проблемы, попадают в Triage inbox (входящие для триажа), а запуски, не обнаружившие проблем, автоматически архивируются, что удобно. Внутри OpenAI тоже используют это для скучных, но необходимых дел: ежедневного триажа issue, подведения итогов сбоев CI, написания сводок по коммитам, отслеживания багов, внесенных кем-то на прошлой неделе. Автоматизации также могут вызывать навыки (skills), поэтому вы можете поддерживать повторяющиеся задачи: вызывать $skill-name, а не вставлять целую стену пояснений в запланированную задачу, которую потом никто не обновит.

Claude Code достигает того же эффекта, но другим путем: через планирование и хуки. Вы можете использовать /loop для запуска промпта или команды через фиксированные интервалы, можете настроить cron-задачу, а также использовать хуки для запуска shell-команд в определенных точках жизненного цикла агента. Если хотите, чтобы все работало и после закрытия ноутбука, можете запустить все это в GitHub Actions. Идея точно такая же: вы определяете автономную задачу, задаете ей ритм, и результаты обнаружения приходят к вам, а не вы ходите и проверяете.

Есть еще одна важная внутрисессионная примитивная конструкция, которая ближе к сути этой статьи. /loop повторяет запуск по расписанию; /goal же будет выполняться непрерывно, пока не будет выполнено определенное вами условие. После каждого раунда отдельная маленькая модель решает, выполнена ли задача, так что агент, пишущий код, не тот, кто сам себя оценивает. Вы можете задать условие, например, «все тесты в test/auth проходят и линтер чист», и уйти. У Codex есть такая же возможность, также называемая /goal. Она будет работать между раундами до тех пор, пока не будет выполнено проверяемое условие остановки, с поддержкой паузы, возобновления и очистки. Одна и та же примитивная конструкция в двух инструментах. Это в основном повторяющаяся в статье модель.

Итак, Automations отвечают за всплытие работы. Остальная часть цикла отвечает за обработку этой работы.

Worktrees: чтобы параллелизм не превратился в хаос

Как только вы запускаете больше одного агента, конфликты файлов становятся точкой отказа. Два агента, одновременно пишущие в один файл, по сути так же проблематичны, как два инженера, изменяющих одну строку кода без обсуждения. git worktree решает эту проблему. Это отдельный рабочий каталог на отдельной ветке, но с общей историей репозитория, поэтому изменения одного агента физически не могут затронуть копию другого.

Codex напрямую поддерживает worktree, поэтому несколько потоков могут одновременно работать с одним репозиторием, не сталкиваясь друг с другом. Claude Code также может обеспечить такую же изоляцию через git worktree: вы можете использовать флаг --worktree, чтобы открыть сессию в отдельной копии, или установить isolation: worktree для суб-агента, чтобы каждый помощник получал новую копию и автоматически очищался после завершения. Я писал о человеческом аспекте этого в the orchestration tax: worktrees устраняют конфликты на механическом уровне, но верхний предел по-прежнему вы. То, сколько агентов вы можете запустить одновременно, определяет не инструмент, а ваша пропускная способность для ревью (review bandwidth).

Skills: чтобы не приходилось каждый раз заново объяснять проект

Skill — это механизм, позволяющий не объяснять заново один и тот же контекст проекта в каждой сессии, как золотой рыбке. Оба инструмента используют одинаковый формат: папка с файлом SKILL.md, содержащим описание и метаданные; плюс опциональные скрипты, справочные материалы и файлы ресурсов. Codex запускает навык, когда вы вызываете его через $ или /skills, а также автоматически, если ваша задача соответствует описанию навыка. Поэтому краткое, простое описание часто лучше умного и вычурного. Claude Code работает точно так же, я писал об этой модели в agent skills.

Skills — это также место, где намерение перестает постоянно расходовать ваши силы. В intent debt я говорил, что агент начинает каждую сессию с чистого листа, и если в вашем намерении есть пробелы, он заполнит их уверенными догадками. Skill — это способ записать это намерение внешне: соглашения по проекту, шаги сборки, «мы так не делаем из-за того инцидента» и т.д., все записывается один раз в месте, которое агент читает при каждом запуске. Без skills каждый раунд цикла приходится заново выводить весь ваш проект с нуля; с skills это похоже на работу со сложным процентом.

Важно различать: skill — это формат записи, plugin — способ распространения. Когда вы хотите поделиться skill между несколькими репозиториями или упаковать несколько skills вместе, вы инкапсулируете их в plugin. Так в Codex, так и в Claude Code.

Plugins and connectors: дают циклу доступ к вашим реальным инструментам

Цикл, который видит только файловую систему, — это очень маленький цикл. Connectors, построенные на MCP, позволяют агенту читать ваш трекер задач, запрашивать базу данных, вызывать staging API или отправлять сообщения в Slack. И Codex, и Claude Code поддерживают MCP, поэтому connector, написанный для одного, обычно работает и в другом. Plugins упаковывают connectors и skills вместе, позволяя вашим коллегам установить полную конфигурацию за раз, а не воссоздавать все по памяти.

Вот разница между «агент говорит вам „вот исправление“» и «цикл сам открывает PR, связывает тикет в Linear и уведомляет канал после прохождения CI». Connectors важны, потому что они позволяют циклу действовать в вашей реальной среде, а не просто говорить вам «если бы я мог, я бы сделал это».

Sub-agents: отделяют создателя от проверяющего

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

Codex создает суб-агентов только по вашему запросу; они запускаются параллельно, а затем объединяют результаты в один ответ. Вы можете определить своих агентов в файлах TOML в .codex/agents/: у каждого агента есть имя, описание, инструкции, а также опционально модель и сила рассуждений. Таким образом, ваш аудитор безопасности может быть мощной моделью с высоким уровнем рассуждений, а ваш исследователь — быстрой, легкой, только для чтения моделью. Claude Code также реализует аналогичные возможности через суб-агентов и команды агентов в .claude/agents/, позволяя нескольким агентам передавать работу между собой. Наиболее распространенное разделение обязанностей в обеих системах: один агент исследует, второй — реализует, третий — проверяет по спецификации.

Я уже дважды излагал эту мысль: один раз в code agent orchestra, другой раз в adversarial code review. В цикле она особенно важна, потому что цикл работает, когда вы не смотрите, и только наличие проверяющего (verifier), которому вы действительно доверяете, дает вам смелость отойти. Sub-agents действительно потребляют больше токенов, потому что каждый агент выполняет свои собственные вызовы модели и инструментов, поэтому их стоит использовать там, где «второе мнение стоит оплаты». Это в основном то же, что делает /goal в Claude Code на низком уровне: новая модель решает, завершен ли цикл, а не та, которая выполняла работу. То есть она применяет разделение «создателя» и «проверяющего» к самому условию остановки.

Как выглядит цикл

Собрав все это вместе, отдельный поток превращается в небольшую панель управления. Вот структура, которую я часто использую.

Каждое утро в репозитории запускается automation. Его промпт вызывает skill для триажа, читает вчерашние сбои CI, открытые issues, недавние коммиты и записывает результаты в файл Markdown или на доску Linear. Для каждой проблемы, требующей обработки, поток открывает изолированный worktree, отправляет суб-агента набросать исправление, а затем отправляет второго суб-агента проверить это исправление на соответствие навыкам проекта (skills) и существующим тестам.

Connectors позволяют этому циклу самому открывать PR и обновлять тикет. Все, с чем цикл не может справиться, попадает в папку для триажа (triage inbox), где я с этим разбираюсь. Файл состояния — это хребет всей системы: он запоминает, что было опробовано, что сработало, что осталось незавершенным. Таким образом, утренний запуск на следующий день продолжается с того места, где остановился сегодняшний.

Обратите внимание, что вы на самом деле делаете. Вы всего лишь проектируете один раз. Эти шаги не выполняются вами лично через написание отдельных промптов. Это и есть практическая версия слов Штайнбергера. Более того, один и тот же цикл может работать и в Codex, и в Claude Code, потому что компоненты одни и те же.

Что цикл все еще не сделает за вас

Цикл меняет способ работы, но не избавляет вас от работы. На самом деле, по мере того как циклы становятся мощнее, три проблемы становятся острее, а не легче.

Верификация по-прежнему зависит от вас. Цикл, работающий без присмотра, может и ошибаться без присмотра. Вы разделяете суб-агента-верификатора и агента-создателя именно для того, чтобы слова цикла «выполнено» хоть что-то значили. Тем не менее, «выполнено» — это утверждение, а не доказательство. Я постоянно повторяю одну фразу в code review in the age of AI: ваша ответственность — поставить код, эффективность которого вы подтвердили.

Если вы пустите дело на самотек, ваше собственное понимание все равно будет деградировать. Чем быстрее цикл поставляет код, который вы лично не писали, тем больше разрыв между тем, что вы понимаете, и тем, что реально существует в системе. Это comprehension debt (долг понимания). Если вы не читаете результаты работы цикла, гладкий цикл только ускорит рост этого долга.

И да, самая удобная позиция, вероятно, и самая опасная. Когда цикл работает сам, слишком легко перестать формировать собственное суждение и просто принимать все, что он возвращает. Я называю это cognitive surrender (когнитивная капитуляция). Если вы проектируете цикл с рассудительностью, это лекарство; если вы проектируете цикл, чтобы избежать мышления, это ускоритель. Одно и то же действие приводит к противоположным результатам.

Стройте циклы, но оставайтесь инженерами

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

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

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

Вот почему проектирование циклов (loop design) сложнее, чем инженерия промптов (prompt engineering), а не проще. Черни имел в виду не то, что работа стала легче, а то, что точка приложения усилий сместилась.

Стройте циклы. Но стройте их как человек, который все еще собирается быть инженером, а не как человек, отвечающий только за нажатие кнопки «Старт».