Хватит писать промпты. Проектируй цикл.

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

Эта эпоха заканчивается. Эдди Османи, директор по AI в Google Cloud, дал имя тому, что приходит на смену: loop engineering — проектирование циклов. Вы перестаёте быть человеком, который пишет промпты агенту. Вы проектируете цикл, который пишет промпты за вас.

В моей формулировке: вы перестаёте быть тем, что выполняется, и начинаете проектировать то, что выполняется. Рычаг смещается на слой выше.

Рычаг сместился на слой выше

Те, кто строят эти инструменты, уже совершили переход. Питер Штайнбергер публикует ежемесячное напоминание: «Вы не должны больше писать промпты AI-агентам. Вы должны проектировать циклы, которые пишут промпты вашим агентам».

Борис Черный, возглавляющий Claude Code в Anthropic, говорит то же самое о своей работе. Он больше не пишет промпты Claude. У него работают циклы, которые пишут промпты Claude и решают, что делать дальше — сканируя тикет-трекер, командный чат и таймлайн того, что нужно построить. «Моя работа — писать циклы».

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

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

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

Пять строительных блоков и один — который держит всё вместе

Разберите loop engineering на части, и получится примерно пять блоков плюс одно место для хранения памяти. И Claude Code, и Codex уже имеют все пять. Названия местами различаются, возможности — одинаковые.

1. Автоматизации — сердцебиение

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

2. Worktrees — чтобы параллельность не превращалась в хаос

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

3. Skills — намерение, записанное вовне

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

4. Коннекторы — чтобы цикл касался реальных инструментов

Построенные на MCP (Model Context Protocol), они позволяют агенту читать тикет-трекер, запрашивать базу данных, обращаться к staging API или отправлять сообщение в чат. Это разница между агентом, который говорит «вот исправление», и циклом, который открывает пул-реквест, линкует тикет и пингует канал, когда CI становится зелёным.

5. Субагенты — чтобы создатель не оценивал сам себя

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

Шестой элемент: память

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

Что удерживает цикл от развала

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

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

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

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

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

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

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

Когда цикл доходит до продакшена

Большая часть этих размышлений выросла вокруг прикладного кода, где неудачный запуск стоит вам revert'а. Когда цикл добирается до инфраструктуры, радиус поражения — простой в продакшене, а не revert, и планка верификации должна подняться соответственно. Плюс в том, что инфраструктура даёт циклу лучший оракул, чем прикладной код. Plan diff детерминирован и машиночитаем, проверка политик возвращает жёсткий вердикт, а дрейф и стоимость — это числа, на которые можно поставить порог. Ревьюер, человек или агент, может прочитать изменение «холодным», без памяти о промпте, который его породил. Эта холодная проверка — именно то, что нужно циклу без присмотра, и именно поэтому инфраструктурный цикл может держаться, пока вы спите.

С чего начать

Выберите цикл, которому вы действительно можете доверять. По порядку:

1. Начните там, где «готово» однозначно. Триаж CI, поднятие зависимостей, охота на flaky-тесты, падающая задача, которую вы постоянно перезапускаете вручную. Циклам нужен оракул, так что начинайте там, где он уже есть.
2. Напишите файл памяти до цикла. Один markdown-файл или доска. Что сделано, что дальше, что пробовали и не сработало. Это позвоночник, на котором висит всё остальное.
3. Разделите создателя и проверяющего. Используйте /goal с верифицируемым условием или второго агента с собственными инструкциями. Никогда не позволяйте агенту, сделавшему работу, решать, что работа закончена.
4. Ограничьте, затем прочитайте всё. Максимальное количество итераций, бюджет токенов, шаг завершения. Запустите один раз, от начала до конца, затем прочитайте каждую строку, которую цикл поставил. Первый запуск — это измерение, а не результат.

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

Цикл сделает набор текста. Мышление — это работа.