Loop-инженерия

Вместо того чтобы самому давать промпты агенту, вы проектируете систему, которая делает это за вас. Пять строительных блоков -- и Claude Code, и Codex уже имеют все пять.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Loop-инженерия

Loop Engineering. Автор: Addy Osmani Оригинальный текст:

Loop-инженерия -- это когда вы заменяете себя как человека, который промптит агента. Вместо этого вы проектируете систему, которая делает это сама. Цикл (loop) здесь можно представить как рекурсивную цель: вы задаёте назначение, а ИИ итерирует, пока задача не будет выполнена. По сути, это пять строительных блоков, и Claude Code вместе с Codex теперь имеют все пять.

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

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

Окей, и что всё это значит?

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

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

Что меня удивило -- это уже не вопрос конкретного инструмента. Год назад, если вам нужен был цикл, вы писали кучу bash-скриптов и поддерживали эту кучу вечно, и она была только вашей. Теперь эти компоненты просто поставляются внутри продуктов. Список Штайнбергера практически точно ложится на приложение Codex, а затем почти так же -- на Claude Code. И как только вы замечаете, что форма одинаковая, вы перестаёте спорить о том, какой инструмент лучше, и просто проектируете цикл, который работает в любом из них.

Пять компонентов и заметки

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

1. Автоматизации -- запускаются по расписанию, самостоятельно обнаруживают задачи и проводят триаж.
2. Worktrees (рабочие деревья) -- чтобы два агента, работающих параллельно, не наступали друг другу на пятки.
3. Навыки (Skills) -- чтобы зафиксировать знания о проекте, которые агент иначе просто угадывал бы.
4. Плагины и коннекторы -- чтобы подключить агента к инструментам, которые вы уже используете.
5. Суб-агенты -- чтобы один из них предлагал идею, а другой её проверял.

И шестой элемент -- память. Markdown-файл, или доска в Linear, что угодно, что живёт за пределами одной беседы и хранит, что сделано и что дальше. Звучит слишком примитивно, чтобы иметь значение. Но это тот же приём, от которого зависит каждый долгоживущий агент -- модель забывает всё между запусками, поэтому память должна быть на диске, а не в контексте. Агент забывает, репозиторий -- нет.

Оба продукта теперь имеют все пять компонентов.

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

Автоматизации -- это пульс системы

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

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

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

Итак, это та часть, которая обнаруживает работу. Всё остальное в цикле -- это то, что действует по результатам.

Worktrees -- чтобы параллельность не превратилась в хаос

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

Codex встраивает поддержку worktree прямо в продукт, чтобы несколько потоков работали с одним репозиторием одновременно и не мешали друг другу. Claude Code даёт ту же изоляцию через git worktree: флаг --worktree для открытия сессии в собственном чекауте и настройку isolation: worktree, которую вы ставите на суб-агента, чтобы каждый помощник получал свежий чекаут, который сам убирается за собой. Я писал о человеческой стороне этого в статье про налог на оркестрацию -- worktrees убирают механические коллизии, но ВЫ по-прежнему остаётесь потолком: ваша пропускная способность по ревью определяет, сколько агентов вы реально можете запустить, а не инструмент.

Навыки (Skills) -- чтобы перестать объяснять свой проект каждый раз

Навык (skill) -- это способ перестать заново объяснять один и тот же контекст проекта каждую сессию, как золотая рыбка. Оба инструмента используют один формат: папка с SKILL.md внутри, содержащая инструкции и метаданные, плюс опциональные скрипты, ссылки, ассеты. Codex запускает навык, когда вы вызываете его через $ или /skills, или автоматически, когда ваша задача соответствует описанию навыка -- поэтому точное скучное описание лучше красивого. Claude Code делает то же самое, и я описал этот паттерн в статье про навыки агентов.

Навыки -- это также то место, где намерение (intent) перестаёт стоить вам снова и снова. Я утверждал в статье про долг намерения, что агент начинает каждую сессию с нуля и заполняет любой пробел в вашем намерении уверенной догадкой. Навык -- это то намерение, записанное снаружи: соглашения, шаги сборки, «мы так не делаем из-за того инцидента» -- записанное один раз там, где агент читает это каждый запуск. Без навыков цикл заново выводит весь ваш проект с нуля на каждой итерации; с навыками он как бы накапливает знания.

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

Плагины и коннекторы -- цикл взаимодействует с вашими реальными инструментами

Цикл, который видит только файловую систему, -- это маленький цикл. Коннекторы, построенные на MCP, позволяют агенту читать ваш трекер задач, делать запросы к базе данных, обращаться к staging API, отправлять сообщение в Slack. И Codex, и Claude Code поддерживают MCP, так что коннектор, написанный для одного, обычно просто работает в другом. А плагины объединяют коннекторы и навыки вместе, чтобы ваш коллега установил вашу конфигурацию за один раз, вместо того чтобы восстанавливать всё по памяти.

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

Суб-агенты -- разделяйте создателя и проверяющего

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

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

Я уже дважды обосновывал этот подход: один раз в статье про оркестр агентов для кода и один раз в статье про состязательное код-ревью. Причина, по которой это особенно важно внутри цикла, в том, что цикл работает, пока вы не смотрите, и верификатор, которому вы действительно доверяете, -- единственная причина, по которой вы можете уйти. Суб-агенты сжигают больше токенов, поскольку каждый из них использует собственную модель и инструменты, так что тратьте их там, где второе мнение стоит того. Это, по сути, то, что /goal в Claude Code делает под капотом: свежая модель решает, закончен ли цикл, вместо той, что выполняла работу -- разделение создателя и проверяющего, применённое к самому условию остановки.

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

Собираем всё вместе -- и один поток превращается в маленькую панель управления. Вот форма, которую я постоянно использую.

Автоматизация запускается каждое утро на репозитории. Её промпт вызывает навык триажа, который читает вчерашние падения CI, открытые тикеты, недавние коммиты и записывает находки в markdown-файл или доску Linear. Для каждой находки, которую стоит обработать, поток открывает изолированный worktree и отправляет суб-агента писать черновик исправления, а второй суб-агент ревьюит этот черновик по навыкам проекта и существующим тестам.

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

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

Что цикл по-прежнему не делает за вас

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

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

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

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

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

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

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

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

Вот почему проектирование циклов сложнее prompt engineering (проектирования промптов), а не проще. Тезис Черни не в том, что работа стала легче. А в том, что точка приложения рычага сместилась.

Стройте цикл. Но стройте его как человек, который намерен оставаться инженером, а не просто тем, кто нажимает кнопку «Запуск».

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot