Хватит промптить. Пиши циклы

«Вы больше не должны промптить кодящих агентов. Вы должны проектировать циклы, которые промптят их за вас.» — Peter Steinberger

В ноябре Boris Cherny — создатель Claude Code — удалил IDE. Не пользовался. В свежем интервью он говорит прямо: «Я больше не промпчу Claude. У меня крутятся циклы, которые промптят его и сами решают, что делать. Моя работа — писать циклы». И добавляет: это переход, который рынок будет проживать весь оставшийся год.

Сдвиг простой на словах и огромный по последствиям. Раньше ты в чате: промпт → ответ → правка → снова промпт. Человек — горлышко в каждой итерации. Теперь ты один раз проектируешь систему, которая сама находит работу, раздаёт агентам, проверяет результат, пишет что сделано и решает, что дальше. И тыкает агентов вместо тебя.

Лестница абстракций

Daniel Demmel разложил это в лестницу, где промптинг — нижняя ступень:

1. Prompt engineering — как сформулировать запрос.
2. Context engineering — что дать в контекст.
3. Feedback-loop engineering — дать агенту увидеть последствия своей работы: тесты, логи, реальные API.
4. Harness engineering — управление всем аппаратом: что запускается, что проверяет, когда зовёт человека.

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

Анатомия цикла

Цикл закрывается без человека по одной причине: у кода есть дешёвый объективный оракул — компиляция, тесты, линт, запуск. Агент сам видит, что соврал. Так строят «closed-loop»: агенты компилируют, гоняют, скриншотят, бьются о реальные ключи — верифицируют себя.

Сам цикл сводится к формуле: найти работу → ограниченное действие → верификация → отчёт → эскалация. Это формализуют как одностраничный контракт на каждый цикл:

trigger:  когда запускается
scope:    что трогает / что нет
budget:   max попыток / время / файлов
stop:     условия эскалации к человеку
report:   куда писать итог

Шесть примитивов оркестрации

Anthropic описал шесть паттернов, из которых агент собирает себе harness под конкретную задачу — как из деталей конструктора:

• Classify-and-act — роутинг по типу. Входящее (issue, письмо, тикет, ошибка) классифицируется, и каждый тип уходит своему обработчику. Это «диспетчер» на входе цикла: не делать всё одинаково, а сначала понять, что именно пришло.
• Fan-out-and-synthesize — задача дробится на независимые куски, каждый решается параллельно в чистом контексте, потом результаты сводятся в одно. Так агент анализирует большую кодовую базу десятком под-агентов сразу, а синтезатор собирает общую картину. Параллелизм там, где куски не зависят друг от друга.
• Adversarial-verify — отдельный агент-скептик проверяет результат против рубрики, и его задача — опровергнуть, а не подтвердить. Это снимает self-preferential bias: автор не должен сам ставить себе зачёт. Ключевой паттерн доверия — проверяет не тот, кто делал.
• Generate-and-filter — нагенерить много кандидатов, отфильтровать по качеству, выкинуть дубли. Полезно, когда дешевле произвести десять вариантов и отобрать, чем пытаться угадать один правильный с первого раза.
• Tournament — несколько агентов решают одну и ту же задачу разными подходами, судьи сравнивают их попарно, пока не останется победитель. Это для случаев, где пространство решений широкое и заранее не ясно, какой путь лучше.
• Loop-until-done — спавнить агентов, пока не выполнится стоп-условие: ничего нового не находится, ноль ошибок, цель достигнута. Так делают исчерпывающий обход — например, ищут баги, пока два прохода подряд не вернут пусто.

Обрати внимание на главное: почти каждый примитив держится на шаге верификации — adversarial-verify проверяет, filter отбирает, until-done смотрит на «ноль ошибок». То есть все они снова упираются в оракул. Без способа объективно сказать «это верно» примитивы превращаются в красивую видимость работы.

Порядок имеет значение: тесты до кода

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

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

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

Трезвый риск

Addy Osmani бьёт честно: цикл делает ошибки без присмотра — и они так и остаются незамеченными. Растёт comprehension debt: код едет быстрее, чем твоё понимание. И «cognitive surrender» — когда перестаёшь формировать мнение и принимаешь всё, что выдала машина. Его формула: «Строй цикл. Но строй как тот, кто намерен остаться инженером, а не просто нажать “пуск”».

Как это выглядит на практике: от контракта к дев-loop

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

Шаг 0. Заказчик отдаёт контракт, а не таску. В нём три вещи, делающие его пригодным для цикла:

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

Шаг 1. Дев-loop стартует от приёмки, не от кода. Агент читает критерии → пишет тесты, кодирующие их (test-first, из контракта) → реализует → гоняет тесты и линт → красное чинит сам в пределах budget → повторяет до зелёного.

Шаг 2. Эскалация — только настоящие развилки. Цикл зовёт человека, когда «контракт говорит X, а в коде Y» или «критерий неоднозначен». Не зовёт на «забыл скобку».

Шаг 3. Выход — PR и прогон тестов. Ревью идёт по PR и контракту, а не пошагово за агентом.

Что меняется для разработчика, конкретно:

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

Честная граница. Это едет там, где приёмка объективна и контракт заземлён. Где оракула нет — дизайн, продуктовый выбор «ту ли вещь строим» — человек на гейте, цикл не сходится сам. И test-first обязателен: без него агент грейдит сам себя.

А зачем тогда senior-инженер?

Доведём логику до конца, не отводя глаз. Если заказчик отдаёт проверяемый контракт, а цикл реализует и верифицирует — зачем senior-инженер?

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

Поэтому контракт не передаётся одним актом — это цепочка обогащения:

Три вещи делают это рабочим.

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

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

Объём обогащения пропорционален архитектурной новизне. Тривиальная фича — обогащать нечего, loop едет почти прямо от контракта, сеньор едва касается. Сложная — обогащение и есть основная ценность сеньора. Участие масштабируется сложностью, а не числом фич.

Отсюда симметрия, в которой весь вывод. Заказчик владеет гейтом замысла — у «та ли это фича» нет оракула. Senior владеет гейтом архитектуры — у «тот ли дизайн, верен ли он под нагрузкой, гонкой, атакой» оракула тоже нет. Цикл заполняет проверяемую середину. Убери любой гейт — получишь confident-wrong в масштабе: либо не ту фичу, либо красиво описанную фичу на наивной небезопасной архитектуре, что прошла мелкие тесты.

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

Вывод одной строкой: loop поднимает всех вверх — туда, где оракула нет, — и стирает середину, покрытую оракулом. Он удаляет не роль, а оракул-покрываемую часть роли. Заказчик — на замысле. Senior — на архитектуре. Цикл — посередине, и едет ровно настолько далеко, насколько проверяем контракт с обоих концов.

По мотивам Boris Cherny, Peter Steinberger, Addy Osmani и Anthropic Engineering.