The Spec Compiler

Контракты, а не задачи

Thu, 30 Jul 2026 00:00:00 GMT

Я замерил, куда на самом деле уходит моя неделя. Декомпозиция одной фичи на точные задачи — какие файлы, какие методы, в каком порядке — стоит мне часов. Потом я посмотрел, что разработчик сделал с моей декомпозицией.

Он вставил её в Claude.

Задержись на этом на секунду — мне понадобилось стыдно долго. Подробный список задач — это, по функции, промпт. Я руками писал промпты самыми дорогими часами в команде — для модели, которая сидит рядом с кодом и перегенерирует тот же план за минуты.

Дубль

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

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

Два прохода по одной работе. И из двух дорогим был мой.

Математика горлышка

Вот почему это не косметическая неэффективность:

Шаг	Кто платит	Типичная цена
Мелкозернистая декомпозиция	владелец	часы на фичу
Реализация по ней	разработчик + агент	часто меньше

Когда постановка стоит дороже производства, очередь выстраивается перед владельцем. Не изредка — структурно. Фичи перестают ждать рук и начинают ждать моей писанины.

И у ловушки жестокий поворот: чем я усерднее — чем мельче декомпозирую, — тем хуже. Каждый лишний час прожёвывания ложится на дорогую сторону баланса и ничего не снимает с дешёвой. Усердие копает яму глубже.

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

Одна фича, две передачи

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

Как контракт: операция переименования существует; дубль имени отклоняется отдельной ошибкой; вызвать может только владелец scope; когда родительский объект умирает, запись умирает с ним; «готово» — это три проходящие проверки.

Пять обещаний о том, что должно стать истинным, — каждое проверяемо, и ни одно не является моей догадкой о чужом файле.

В этом вся замена. Единица передачи — больше не изменение, которое надо сделать, а обещание, которое надо сдержать. Из чего оно состоит:

Секция	На какой вопрос отвечает	Почему переживает встречу с реальностью
Интерфейс	Что существует, когда ты закончил?	Абстрактная схема, именованная конвенциями самого API — ничего выдуманного
Поведение	Что происходит при успехе, при отказе, на границах?	Текстом, не кодом — перевод берёт на себя имплементатор
Доступ	Кто может вызвать, под какой привилегией и в каком scope?	Включая случаи, о которых забывают: обход админа, машинная идентичность
Жизненный цикл	Что происходит при удалении / обновлении / отвязке родителя?	«Мы забыли про каскад» — самый скучный продакшн-инцидент на свете
Приёмка	Что значит «готово»?	Прогоняемо без вопросов автору, что он имел в виду
Радар воздействия	Что нельзя сломать и что от этого зависит?	Порядок становится данными, а не племенным знанием

Что контракт намеренно опускает: пути к файлам, имена методов, SQL, пошаговые инструкции. Это юрисдикция имплементатора, это лучше перегенерируется ближе к коду — и каждая такая строка в спеке — строка, за которую я заплатил дважды.

Страх — и закон, который на него отвечает

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

Гранулярность декомпозиции должна быть обратно пропорциональна силе твоего приёмочного gate.

Если gate исполнителя силён — ревью против контракта, тесты, которые пишет автор как норму, скрипт, проверяющий саму структуру контракта, — крупные единицы безопасны: один контракт упаковывает то, что было бы шестью задачами, а gate ловит, что пошло не так.

Если gate слаб, крупные куски и правда безрассудство. Приходится мельчить — не навсегда, а пока gate не вырастет.

Я гоняю оба режима одновременно, поэтому и знаю, что закон держится:

Трек	Gate сегодня	Размер единицы сегодня
Backend	Силён: сеньор ревьюит против контракта, автор пишет тесты, скрипт проверяет структуру	Крупный — один контракт вместо шести задач
Frontend	Слабее, ещё растёт	Мелкозернистый, послойный

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

Frontend остаётся мелкозернистым не потому, что фронтенд сложнее, а потому, что тот gate моложе. Тот же закон, другой конец шкалы.

Куда делись часы

Выигрыш замыкает петлю, с которой этот текст начался:

	Было	Стало
Мои часы на фичу	прожёвывание плана имплементации	написание обещаний + суждение по приёмке
Разработчик получает	мой прогноз, чтобы вставить его в модель	право владеть «как» — с gate, который ловит провал
Очередь	выстраивается передо мной	выстраивается перед gate — а он масштабируется

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

Честный prior art, с датой: design-by-contract существует сорок лет — предусловия и постусловия принадлежат Мейеру, не мне, — а работы 2026-го оживляют его под задачной декомпозицией, чтобы верифицировать кодогенерацию. Ход здесь другой: контракт заменяет задачу как единицу передачи на границе человек↔агент, и приходящего с ним закона гранулярности я нигде сформулированным не видел. По состоянию на середину июля 2026-го — сверься с датой, прежде чем цитировать.

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

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

Дальше: The Two-Layer Compiler — почему тупой процедурный слой плюс обучающийся слой компаундятся, а ручная сообразительность — нет.

The Oracle Lens: три вида истины

Fri, 03 Jul 2026 00:00:00 GMT

В прошлом тексте я сказал, что спецификация заслуживает компилятора — gate, который падает, когда на входе ошибка. Звучит чисто, пока не начнёшь его строить: тут же упираешься в вопрос, который слово «ошибка» прятало. Ошибка — в каком смысле?

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

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

Truth, Coherence, Intent

Ось	Вопрос	С чем сверяется	Как проверить
Truth	Так ли это на самом деле?	Мир за пределами документа — код, работающая система, данные	Пойти и посмотреть: grep, вызов endpoint'а, запрос к базе
Coherence	Держится ли это вместе?	Сам документ	Читать против себя: противоречия, дыры, термин в двух смыслах
Intent	То ли это самое?	Голова человека	Механической проверки не существует

Truth — заземлённость в реальности. «API возвращает это поле». «В этой таблице есть колонка status». «Консьюмер переживёт лишний параметр».

Каждое утверждение истинно или ложно относительно мира, существующего независимо от документа. У Truth есть внешний референт — именно поэтому из всех трёх осей она механизируется лучше всего.

Coherence — внутренняя согласованность. Не противоречит ли документ сам себе? Нет ли дыр — поведение описано для одних входов и умолчено для других? Не используется ли один термин в двух смыслах?

Coherence не нуждается в мире за пределами документа. Это ось, до которой тулинг спецификаций реально добрался: когда Kiro помечает двусмысленную фразу или два требования, которые не могут выполняться одновременно, или когда чеклист Spec Kit спрашивает, покрыты ли все случаи, — это оракул когерентности. Он действительно полезен, и я не хочу его принижать.

Intent — совпадение с тем, чего на самом деле хотели. Не «согласовано ли» и не «правда ли» — а «то ли это самое».

Спека может быть безупречно когерентной, идеально заземлённой в реальности — и описывать фичу, которая никому не нужна. Или не ту фичу. Или ту, но с чуть неверным дефолтом, который распознает как неверный только тот, кто просил. Intent живёт в голове человека. У него нет внешнего референта, по которому можно сделать grep, и нет внутреннего теста, который документ мог бы пройти.

Называть все три стоит потому, что они расходятся, — в этом вся польза линзы.

Они расходятся — и в этом суть

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

Спека бывает истинной и некогерентной. Каждое отдельное утверждение сходится с кодовой базой, но два требования тихо противоречат друг другу, или половина пространства входов не описана. Grounding проходит утверждение за утверждением; когерентность рвётся на швах.

И спека бывает истинной, когерентной — и не той. Самый тяжёлый случай. Она ни о чём не врёт, ничему не противоречит и описывает нечто иное, чем то, чего хотели. Никакой механический оракул этого не поймает — потому что проверять механически не с чем.

А вот аккуратное доказательство из реального мира, что эти оси действительно разделимы, а не выдуманы философом: посмотри, где остановилась индустрия.

Все, кто поднялся до слоя спецификации — Kiro, Spec Kit, — построили оракул когерентности и воткнули флаг. Они скажут тебе, что твоя спека противоречит сама себе. Ни один не скажет, что твоя спека врёт про API, — это совсем другая ось, и ей нужна другая машинерия: та, что выходит из документа и идёт смотреть.

Gate когерентности и gate истины — это не один gate разной строгости. Это разные gate. Рынок нечаянно поставил эксперимент и подтвердил линзу.

Живой пример: когерентность без истины

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

Я проверял, не опубликовал ли кто-нибудь уже таксономию оракулов в духе Truth/Coherence/Intent.

Что сообщил агент. Статья 2026 года делит оракулы верификации ровно по этим линиям и объявляет проверку намерения принципиально немеханизируемой — с цитатой. По теме, хорошо сформулировано, и в мой тезис легло так гладко, что я почти это использовал.

Что нашёл второй проход. Слово «intent» встречается в статье дважды, в несвязанных предложениях. Процитированной строки не существует. Цитата сфабрикована.

Coherence — зелёный. Саммари было безупречно: гладко, правдоподобно, внутренне согласованно. Оно прошло бы любую проверку, которую читатель мог бы применить к самому саммари.

Truth — красный. Оно провалило единственную проверку, которая имела значение: пойди и прочитай источник.

Будь у меня gate когерентности, который я принимал бы за gate истины, эта фальшивка сейчас стояла бы цитатой в этой статье.

Это и есть весь аргумент за линзу в одном анекдоте. Опасные ошибки — не бессвязные: те выглядят неправильно. Опасные ошибки — когерентные-но-ложные, потому что они выглядят правильно, и остановит их только оракул, направленный на мир, а не на документ.

Градиент силы — и ось, которую не механизировать

Три оси различаются не только по сути, но и по тому, насколько они поддаются механизации, — и это упорядочение должно определять, куда вкладывать усилия.

Truth механизируется лучше всех. У неё есть внешний референт, значит проверку можно автоматизировать: grep, компиляция, исполнение, запрос. Строй самый жёсткий, самый автоматический gate здесь — тут компилятор спецификаций отрабатывает свой хлеб, и тут же, как показывает рынок, построено меньше всего.

Coherence механизируется частично. Проверки согласованности и полноты автоматизируются в заметной степени, и LLM неплохо ловят противоречия. Отдача убывает, но задача решаемая. Рынок до этой оси уже дошёл.

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

Его можно приближать: приёмочные тесты кодируют его срез, примеры фиксируют крайние случаи, накопленные человеческие рулинги (об этом отдельный текст — case law) дают слабый дрейфующий прокси. Но приближение — потолок.

Поэтому честный инженерный ход — не подделывать оракул Intent уверенным LLM-судьёй, а назвать Intent осью, требующей человека, поставить человека ровно туда — и механизировать Truth и Coherence настолько жёстко, чтобы дефицитное внимание человека тратилось только на вопрос, на который не может ответить ни одна машина.

Вот что даёт линза. Не новый gate — а понимание, на какой из трёх вопросов на самом деле отвечает каждый твой gate.

Чтобы проверка когерентности больше не караулила дыру, которую способна закрыть только проверка истины, — и чтобы машина не делала вид, будто закрывает тот единственный вопрос, что всегда оставался за человеком.

Дальше в серии — сам gate истины: как заземлять спецификацию против реальности и почему самые интересные провалы не про ложь, а про слои. Об этом — в одном из следующих текстов.

Спецификация — это цель компиляции

Fri, 03 Jul 2026 00:00:00 GMT

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

Это соотношение перевернулось — а переоценить свою работу под новый расклад не успел почти никто.

Когда агент берёт точное описание изменения и за минуты выдаёт рабочую, протестированную имплементацию, имплементация перестаёт быть узким местом. Перестаёт быть местом, где живёт мастерство.

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

И вот часть, до которой тулинг ещё не дотянулся: если имплементация теперь — шаг компиляции, то спецификация — это цель компиляции.

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

Вот и весь тезис. Остальная серия — о том, как это выглядит, если отнестись к нему буквально.

Чего на самом деле требует «компиляция»

Компилятор беспощаден — и именно этим полезен. Ему всё равно, хороша ли твоя программа как замысел. Он проверяет другое: стоит ли она на реальности — существуют ли эти символы, сходятся ли типы, совпадает ли вызов с настоящей сигнатурой.

И если нет — отказывается работать дальше. Отказ здесь не издержка, а суть: компилятор, который вежливо предупреждал бы и всё равно собирал бинарь, был бы никому не нужен.

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

«API уже возвращает это поле»
«это чисто UI-изменение»
«консьюмер переживёт лишний параметр»

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

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

Вот форма провала, которую я вижу постоянно.

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

Почему проходит ревью. Символ существует. Ленивая проверка — встречается ли имя в коде? — загорается зелёным.

Что находит настоящий gate. Не принимай совпадение имени за доказательство, открой тело — и код с правильным именем делает совсем другое: охраняет другой ресурс, на другом слое, чем предполагает утверждение.

Цена. Правильное имя, не та сущность — и на этом строилось бы целое направление работ.

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

Поэтому первое, что нужно спеке-как-цели-компиляции, — ключевой ход компилятора: блокирующий gate, который отказывается впускать непроверенное утверждение. Не ревьюер, который может заметить. Gate, который требует доказательств:

УТВЕРЖДЕНИЕ   «API уже возвращает это поле»
ДОКАЗАТЕЛЬСТВО  обязательно — файл:строка и фактическая форма в этой строке
ВЕРДИКТ       принято          утверждение входит в спеку
              отклонено        утверждение вычёркивается или уходит в открытые вопросы
              не тот слой      символ есть, но охраняет другое → назад автору

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

Комната, в которой никто не стоит

А теперь утверждение неудобное — но я готов его защищать: я проверил, и почти все строят компилятор этажом ниже, чем нужно.

Движение spec-driven development уже реально. Spec Kit от GitHub, Kiro от AWS, Tessl — существует внятная карта, кто что занимает, и её стоит прочитать.

У некоторых даже есть gate на слое спецификации — больше, чем я ожидал, когда пошёл проверять. Kiro проводит тебя от требований через дизайн к задачам и по ходу проверяет документ требований. Spec Kit поставляет Review & Acceptance Checklist, который ты валидируешь перед генерацией.

Так что комната не пуста. Но посмотри, что именно проверяют эти gate — в этом вся суть:

Где стоит gate	Что проверяет	Заземляет утверждения спеки в коде?
Kiro — требования → дизайн → задачи	Неоднозначность, противоречия, неполноту, уровень детализации	Нет
Spec Kit — чеклист перед генерацией	Полна ли спека и хорошо ли оформлена	Нет
Spec Kit — проверка против реальности	Собранный код против спеки	После имплементации, не до
Исследования grounding (2026: блокирующие gate, типизированные доказательства, проверка цитат)	Утверждения против исходников	Этажом ниже — код и фрагменты, не требования
Тулинг дизайн-систем	Какие компоненты реально использованы	Заземляет имплементацию, не спеку
Render-оракулы	Скриншоты результата	Судят результат, не спеку

Каждая из этих проверок на слое спеки проверяет когерентность. Согласован ли документ сам с собой? Полон ли он? Не противоречит ли себе? Настоящие, полезные вопросы.

Ни одна не задаёт другой: а это правда? Переживёт ли «API уже возвращает это поле» встречу с настоящим API? Ничто в этой таблице не заземляет утверждения спеки о реальности в кодовой базе до генерации.

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

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

Так почему комната пуста? Льстивое объяснение тут же и неверное. Она пуста не потому, что это хитрая ниша, которую разглядел я один. Она пуста, потому что рано.

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

Моя ставка — что это временно, и мой же собственный аргумент это предсказывает: по мере автоматизации имплементации каждого сеньора выталкивает на слой постановки, и придут они туда, нуждаясь ровно в этих инструментах. Эта серия — playbook, написанный изнутри комнаты, до прихода толпы.

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

Серия: карта, а не территория

То, что я построил, — реальный пайплайн, который это делает: компилятор спецификаций, в ежедневной работе на продакшн-кодовой базе.

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

Что дальше:

The Oracle Lens. Прежде чем строить gate, нужно понять, какую истину он вообще способен проверить. Я разделяю оракулы верификации на три оси — Truth (заземлено ли это в реальности), Coherence (согласовано ли внутри себя) и Intent (то ли это, чего на самом деле хотели) — и показываю их ортогональность: вот почему спека может пройти grounding и всё равно оказаться не тем.
Grounding спеки. Тот самый блокирующий gate, целиком: «доказательство или не считается», метрика leak-rate и путаница слоёв как главный враг.
Contracts, Not Tasks. Как ты передаёшь работу агенту, важнее, чем какому агенту, — и принцип под этим: гранулярность декомпозиции должна быть обратно пропорциональна силе твоего приёмочного gate.

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

Но начинается она с рефрейма, потому что он переустраивает всё остальное: имплементация никогда не была сложной частью. Сформулировать истину достаточно точно, чтобы её можно было скомпилировать, — вот теперь работа. Стройте компилятор для этого.

Дальше: The Oracle Lens — три вида истины, которые gate может проверить, и один, который не может.

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

Tue, 09 Jun 2026 00:00:00 GMT

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

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

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

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

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

Prompt engineering — как сформулировать запрос.
Context engineering — что дать в контекст.
Feedback-loop engineering — дать агенту увидеть последствия своей работы: тесты, логи, реальные API.
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.