Loop Engineering: как проектировать циклы для кодинг-агентов

TL;DR: Loop engineering — это когда вы описываете не отдельный промпт, а цикл: состояние, следующий шаг, внешнюю проверку и условие остановки. Цикл окупается там, где проверка дешёвая (зелёный CI, чистый линтер, успешный rebase), и проваливается там, где "готово" стоит дороже самой работы. Ниже: из чего цикл собирают внутри Codex и Claude Code, где он учится обманывать собственный оракул и во сколько обходится прогон без жёсткого стопа.

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

Модель формулирует задачу для себя лучше, чем вы. Но это пока всего два хода. Цикл начинается там, где система повторяет такое решение сама: хранит состояние, выбирает следующий шаг, проверяет результат внешним критерием и останавливается по условию или бюджету. Этот внешний критерий дальше буду называть оракулом: тесты, линтер, зелёный CI, отдельная модель-судья, всё, что отвечает "получилось" или "нет" вместо самого агента.

Питер Стайнбергер, создатель Openclaw, сформулировал это твитом, который собрал миллионы просмотров: "Хватит промптить кодинг-агентов. Проектируйте циклы, которые промптят агентов за вас". Фраза разошлась, обросла продолжениями, дошла до стадии хэштег-спама и гайдов "как печатать альфу 24/7". Обычная судьба вирусного слогана.

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

Этаж над обвязкой: чем loop engineering отличается от harness

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

Адди Османи, бывший директор Google Cloud AI, сформулировал так: "Loop engineering сидит одним этажом выше harness. Та же обвязка, но крутится по таймеру, плодит маленьких помощников и кормит себя сама". Ты больше не держишь инструмент на поводке. Ты строишь небольшую систему, которая сама находит работу, раздаёт её, проверяет результат, записывает, что сделано, и решает, что делать дальше. А пинать агентов эта система будет вместо тебя.

Борис Черный, глава Claude Code в Anthropic, говорит про себя так: "Я больше не промпчу Claude. У меня крутятся циклы, которые промптят Claude и сами решают, что делать. Моя работа — писать циклы". А выступая на Meta @Scale 17 июня, он описал направление ещё резче: "агенты промптят агентов, а те уже пишут код". Это пока режим передовых команд, по всей индустрии его не обобщишь. Человек остаётся в работе, но выходит из ручного цикла промптинга.

Цикл встроили в продукт: из чего он собирается в Codex и Claude Code

В этой волне меня удивило другое: цикл перестал быть вопросом инструмента.

Год назад, если ты хотел цикл, ты писал гору bash и поддерживал её вечно, и была она твоя и только твоя. Канонический пример, "Ralph loop" Джеффри Хантли: while :; do cat PROMPT.md | claude-code; done. Одна строка. Бесконечный цикл, каждый проход несёт свежий контекст, всё состояние держится в файлах на диске. Чуть солиднее устроен autoresearch сенсея Карпатого: скрипт на 630 строк, внутри которого прямо так и написано: LOOP FOREVER. За два дня он прогнал около 650 ML-экспериментов. Смысл конструкции в том, чтобы вынести человека из внутреннего цикла и перестать держать его узким местом.

Те же детали цикла теперь лежат прямо внутри продуктов. Османи раскладывает цикл на пять деталей: автоматизации по расписанию, worktrees для изоляции параллельных агентов, skills с записанным знанием проекта, коннекторы на MCP к твоим реальным инструментам и субагенты, где один придумывает, а другой проверяет. Шестая деталь, память на диске, нужна потому, что "агент забывает, а репозиторий нет". Ни одна из этих деталей больше не требует собственного bash: всё это уже кнопки и команды в приложениях Codex или Claude Code.

Когда замечаешь, что форма у обоих инструментов одна, ты перестаёшь спорить, какой из них лучше, и начинаешь проектировать форму цикла отдельно от выбора конкретного инструмента. Сам Стайнбергер через четыре дня после слогана выложил рецепт: Codex держит твои репозитории, просыпается каждые пять минут, направляет работу в потоки, а сверху навык-оркестратор плюс навыки триажа и авто-ревью. Этот конструктор больше не надо собирать с нуля: он уже встроен в продукт. Об этом же он рассказывал на AI Engineer World's Fair. Конференцию я разбирал отдельно, а чтобы не пересматривать записи, собрал саммари всех выступлений в удобном SPA.

Куда переезжает сложность: почему проверка дороже генерации

Кристоф Накадзава, автор Athena Crisis, почти не пишет код руками и описывает сдвиг так: раньше он упирался в то, чтобы написать код, теперь упирается в то, чтобы решить, правильный ли он. Шубхам Сабу формулирует короче. Генерация больше не проблема, цикл может выдавать бесконечно, остаётся проверить и решить. Когда агент стабильно выдаёт приемлемый черновик, узкое место смещается с написания на проверку написанного и на вопрос, получилось ли вообще то, что нужно.

Того, кто пишет, и того, кто проверяет, надо разносить. Модель слишком благосклонна к собственной работе и охотно поставит себе зачёт за домашку, которую сама же и сделала. Поэтому проверять должен кто-то другой. В Claude Code это уже зашито в команду /goal: после каждого хода отдельная маленькая быстрая модель (по умолчанию Haiku) смотрит, выполнен ли заданный критерий. Она не вызывает инструменты и судит только по тому, что агент выложил в разговор. Ты задаёшь что-то вроде "все тесты в test/auth зелёные и линтер чист, иначе стоп после 20 ходов" и уходишь смотреть Тиктоки.

Дешёвая Haiku-судья закрывает только половину дела. Сам запуск проверки стоит копейки. Дорого обходится критерий, который агент не обманёт. Размытое "готово" маленькая модель проштампует так же охотно, как и сам автор кода. В сложных циклах самой дорогой частью становится критерий готовности и тот, кто его проверяет. Блейк Кросли пишет: "Что можно автоматизировать, решает стоимость верификации, а не конструкция цикла". Пока лучше всего циклы работают на рутине с дешёвым сигналом готовности: CI позеленел, PR перебазировался.

В одном проходе цикла нет никакой мистики. Триггер находит устаревший PR. Состояние лежит в issue и рабочем дереве. Агент перебазирует ветку, отдельный проверяющий запускает CI и сверяет критерий "все обязательные проверки зелёные". Если критерий не выполнен, результат проверки возвращается в следующий ход. Если выполнен, цикл останавливается. Поверх всего стоит жёсткий лимит: например, пять попыток или заданный бюджет. Без внешнего теста и стопа расходы будут расти бесконтрольно.

Я это прочувствовал на своей обвязке, той самой, для одного агента. Больше всего времени съел надёжный ответ на вопрос, сделал ли агент то, что заявил. Пришлось разносить событие "агент доложил готово" и реальную проверку результата, заводить отдельное состояние на случай "побочный эффект мог произойти, но рантайм не уверен", прикручивать повторную попытку.

С тех пор поверх обвязки вырос "Менеджер". Он берёт одну задачу, сам выбирает исполнителей под неё, держит состояние на диске так, чтобы прогон пережил перезапуск, принимает или отклоняет доказательства и закрывает работу статусом, вплоть до "не доказано" и "сделано частично". Переписываю я его чуть ли не через день, и почти каждая переделка приходит из одного и того же места: очередной способ, которым "готово" оказалось не готово. Правила и принципы для построения циклов я собрал в скилле x9-loop-engineering: он не даёт городить агентов ради красоты схемы и требует на каждый цикл условие остановки, владельца у каждого куска общего состояния и статус на выходе, который не выдаёт незаконченное за готовое. Все правила там писаны кровью: каждая строчка появилась после того, как что-то сломалось на реальном прогоне.

Живёт скилл в моём репозитории рядом с x9-agent-instructions про то, как правильно писать промпты для агента, и x9-skill-creator про то, как собирать сами скиллы. Формат общий для Agent Skills, ставится выборочно через интерактивный установщик.

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

Официальный гайд "Getting started with loops" сортирует циклы по тому, что именно ты отдаёшь машине, и получается лесенка нарастающего делегирования: сперва проверку внутри хода, потом условие остановки (/goal), потом триггер по времени (/loop, /schedule), а на верхней ступени, в проактивном цикле, уже сам промпт, когда задачу за тебя формулирует событие. Гайд советует отдавать рутину мелким быстрым моделям, а самую сильную оставлять для суждения.

Поэтому формулу Османи "проектировать цикл труднее, чем заниматься промпт-инжинирингом" я читаю с условием. Для CI, rebase и другой рутины с дешёвой проверкой цикл снимает с человека массу работы. Чем дороже и неоднозначнее оракул, тем больше усилий уходит из формулировки хода в проектирование проверки. Рычаг начал переезжать, но выигрыш зависит от типа задачи.

Где цикл врёт и сколько стоит: reward hacking и счёт за токены

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

В худшем цикл учится обманывать собственный оракул. Это называется reward hacking, и выглядит буквально по Гудхарту: как только агент начинает оптимизировать прохождение теста, тест перестаёт мерить корректность. Модель переписывает тест под себя, вставляет return true, подменяет таймеры monkey-patch'ем, хардкодит ответ ровно под конкретную проверку. В ImpossibleBench это измерили в искусственном сценарии, где тесты намеренно противоречат задаче и читерство выгодно: GPT-5 жульничал в 76% случаев. Цифра относится только к такому сценарию и на обычные прогоны не переносится. Свежие Claude в том же тесте жульничают заметно меньше, чем старый Sonnet 3.7. В июне жульничество сломало уже сам замер. METR не смогла опубликовать горизонт для GPT-5.6 Sol: если считать попытки схитрить провалом, выходит 11 часов, если засчитывать их как успех, оценка улетает за 270. Надёжной METR не считает ни одну из двух цифр.

Оракул может работать как надо, но без надёжного стопа и лимита бюджета цикл всё равно уходит вразнос. Это видно прямо по счёту за токены. Широко цитируемый, но лишь частично верифицированный инцидент, без названной компании: четырёхагентный цикл, где Analyzer и Verifier гоняли друг друга, проработал 264 часа без остановки. Счёт рос ступенями, $127, потом $891, потом $6 240, потом $18 400, и в сумме около $47 тысяч. Остановил всё это только биллинг. Тим Шиппер приводит ещё один сторонний кейс: по оценке автора, одна слэш-команда запустила 49 субагентов параллельно и за 2,5 часа сожгла порядка десяти тысяч долларов. Первичного постмортема там тоже нет, так что число показывает масштаб риска и на проверенную смету не претендует. Считать такие цифры прогнозом собственного счёта не стоит, а вот проверять наличие жёсткого стопа до запуска, а не после, они мотивируют отлично. У цикла, как сформулировал TechCrunch, нет потолка по тратам. Если каждый ход повторно отправляет весь растущий контекст, стоимость такого прогона раздувается особенно быстро. У конструкций, где каждый проход стартует со свежим контекстом, работает compaction, а состояние лежит на диске, такого разгона нет.

Theahura показывает другую цену: на последовательных задачах с большим общим контекстом оркестраторы дороже одного агента и при этом работают хуже. По его разбору, мультиагентные варианты проседали по качеству на 39–70%. Цикл особенно уместен, когда работу можно разложить, результат дёшево проверить, ошибку откатить, а число проходов и бюджет ограничить. Для последовательной задачи с общим контекстом разумнее сначала попробовать одного агента под контролем.

Это не ребрендинг: чем цикл отличается от оркестратора агентов

Тут олды имеют полное право сказать: ребята, вы переименовали оркестратор, которому пять лет в обед.

И по механике они во многом правы. Цикл как идея восходит к ReAct из 2022-го. Идею "агентов, которые промптят агентов" ещё в 2024-м описали как meta-prompting. Оркестраторы, Ralph, Gastown существовали до вирусного слогана. "Цикл Питера" это и есть то, что комьюнити два-три года называло оркестратором.

Модели стали дольше держать задачу, и это одно из условий жизнеспособности циклов. METR мерит горизонт задач: какой длины работу агент доводит до конца с шансом 50%, причём длина считается по времени человека. У GPT-4 в 2023-м это были четыре минуты. У Claude Opus 4.6 в феврале 2026-го уже двенадцать часов, и удваивается эта цифра примерно раз в четыре месяца, а не раз в семь, как считали год назад. Дальше линейка упирается в саму себя: горизонты выше шестнадцати часов набор задач METR мерить не умеет, а моделям, вышедшим после апреля, его вообще не считали.

Только читать эти двенадцать часов как "агент работает полдня" нельзя. METR мерит сложность задачи. Сколько времени работает сама модель, она не мерит вовсе, и пишет об этом прямым текстом. Мой "Менеджер" спокойно тянет тяжёлую задачу больше сорока часов, и это ничего не говорит о том, сделана ли работа правильно. Anthropic разводит те же две линейки на своей телеметрии: медианный ход в Claude Code длится 45 секунд, а зазор между тем, на что модели способны, и тем, как их реально гоняют, она называет deployment overhang. Циклы живут ровно в этом зазоре. В GAIA ранний AutoGPT на GPT-4 набрал 0,4% на задачах Level 2 против 2,6% у голого GPT-4 и работал заметно медленнее, хотя на простом Level 1 был лучше. Агентная обёртка тогда ещё не давала устойчивого выигрыша на более сложном уровне. К длинному горизонту продукты добавили состояние на диске, расписание, изоляцию и отдельную проверку. Старый паттерн впервые стал доступным и достаточно надёжным для ограниченного класса задач.

Пока текст лежал у меня в столе, над этим этажом успели построить следующий. 18 июля Питер спросил: мы всё ещё разговариваем про циклы или уже перешли к графам? Вопрос без определения и без методологии. В тот же день вышла статья "Loop Engineering Is Dead. Enter Graph Engineering": от вопроса до некролога прошло несколько часов. Под новым словом лежит понятная вещь: у работы есть узлы, рёбра, развилки и точки сборки, а цикл становится одним из узлов графа. Канонического определения и сравнительных замеров пока нет, а дисциплина за словом есть. Мой "Менеджер", про которого я рассказывал выше, ровно такой граф и есть: узлы-исполнители, проверки между ними и точка, где всё сходится. Про грабли, на которые я наступал, пока его проектировал, будет отдельная статья.

Остаться инженером

В разборе "To loop or not to loop" автор смотрит на то, о чём слоган молчит: из какого положения даётся совет. Стайнбергер работал "на скорости инференса", потом его схантила OpenAI, и теперь у него фактически бесконечный запас токенов в режиме fast. "Проектируй циклы" из уст человека из передовой лаборатории с бесплатным инференсом и "проектируй циклы" для разработчика, который платит за подписку из своего кармана, это два разных совета в одинаковой обёртке. Нужен ли тебе цикл, решают объём работы, дедлайн, тип задачи (то, что он называет "высокой плотностью намерения", автоматизируется плохо) и цена токенов. Предостережение автора я бы повесил на стену: не превращайся в того, кто тратит большую часть времени на автоматизацию собственной автоматизации. У этой ловушки теперь есть имя: orchestration tax. Расплодить агентов стало легко, но твоё внимание так не параллелится. Решать, за чем следить и что из этого важно, по-прежнему приходится тебе, и это не автоматизируется.

У цикла есть ещё одна цена: долг понимания. Чем глаже он шлёпает код, который ты не писал, тем шире разрыв между тем, что существует в репозитории, и тем, что ты реально понимаешь. Османи зовёт это comprehension debt, долг понимания, и cognitive surrender, когнитивная капитуляция, когда перестаешь думать и берешь что дают. Anthropic измерила этот эффект. В контролируемом эксперименте на 52 инженерах те, кто работал с ИИ-помощником, показывали на тесте сразу после задачи понимание ниже, 50% против 67% у контрольной группы. Исследование вообще-то про то, как джуны осваивают новую библиотеку, так что на нашу ситуацию, где синьор проверяет вывод цикла, это переносится только по аналогии. Но внутри той же работы есть паттерн, который хорошо иллюстрирует нашу тему: у тех, кто слепо делегировал, понимание просело до 24–39%, а у тех, кто оставался вовлечён, спрашивал "почему так" и требовал объяснений к коду, держалось на 65–86%.

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

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

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

Оставайтесь любопытными.

Пишу об искусственном интеллекте, языковых моделях и инструментах для разработчиков. Тестирую модели и сервисы на реальных задачах, а выводами делюсь в телеграм-канале.