А потом я задал им вопрос, на который они не ответили: во что это обошлось?

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

Это разные результаты. Работающая система — только один из них.

Лимит, который ограничивает не то

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

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

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

Почему это стоит больше, чем выглядит

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

Агенту, пишущему код, дали одну лишнюю вещь: карту того, какие тесты покрывают какой код, обычным текстовым файлом, который он мог прочитать. Регрессии — тесты, которые раньше проходили и перестали, — упали с 6,08% до 1,82%. Минус 70% от одного файла.

В том же исследовании была вторая ветка. Вместо карты агенту дали процедурные инструкции: работай от тестов, держись этой дисциплины. Регрессии выросли до 9,94%. Хуже, чем не делать ничего.

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

Я пошёл за цифрами.

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

Прочитайте только это, и вывод напишется сам: harness почти не важен, купите модель получше, идите домой.

Вот только боимся мы совсем не этого

Эти бенчмарки меряют одну задачу в одном контейнере, которая либо проходит, либо нет. Никто в продакшене не теряет сон из-за одной задачи в одном контейнере.

Сон отнимает другое. Система, которая падает раз в несколько дней. Результат, который во вторник уже не повторить. Вердикт, который потом никто не проверит. Прогон, который рапортует об успехе, а файл, где он якобы что-то поправил, попросту выдумал.

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

Там, где цифры всё-таки есть, они немаленькие. Одно исследование срезало регрессии на 70%, подсунув агенту один файл с контекстом. Другое намерило падение доли проваленных задач на 9,5% после того, как к пайплайну добавили критика, проверяющего план до исполнения. И то и другое — изменения в harness. Ни то ни другое в рейтинге не появится.

Значит, пока что груз на вас. Мерьте то, что вас правда волнует: как часто падает система, сколько работы уходит в переделку, как часто вердикт выдерживает ревью. За вас этого никто не опубликует.

Мой собственный сайт три недели отдавал версию на два коммита назад, а я об этом не знал.

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

Ноль миллисекунд значит, что сборка даже не стартовала, то есть дело было не в моём коде. Легло что-то выше.

А сайт? Сайт чувствовал себя прекрасно. HTTP 200, валидный сертификат, всё грузится. Потому что отдавалась последняя удачная сборка, ровно так же, как накануне. У аварии не было никакой видимой поверхности. Снаружи, из моего браузера, из чьего угодно — здоровый сайт.

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

Неприятная параллель

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

Агент рапортует об успехе. Тесты зелёные. Диф выглядит чисто. Всё на поверхности говорит, что работа сделана, и убедиться в обратном можно единственным способом: проверить то, чем не управляет тот, кто рапортует. Запустить настоящее приложение, спросить настоящее состояние, сравнить с тем, до чего оптимизирующая сторона не дотянется.

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

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