Обвязки мало: почему ИИ-ассистент не превращается в фабрику софта и что делать самодельному пайплайну

Есть красивая мечта: берём кучу ИИ-агентов, обвешиваем их идеальной обвязкой, гасим свет в офисе - и оно само собирает софт. Дешёво, быстро, никто не читает код. Я сам в это почти поверил, пока строил свой пайплайн. А потом наткнулся на эссе WSFF (Why Software Factories Fail) от Dex из HumanLayer и понял, где у меня захардкожена та же иллюзия. Разберём, почему фабрика не заводится, и что это значит для тех, кто пилит свой конвейер на ИИ-ассистенте.

Почему "фабрика софта" на ИИ-агентах не взлетает?

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

Дальше цитата, которая меня добила: "models have a shortcoming. They can't maintain and improve codebase quality over time". То есть у модели нет стимула беречь поддерживаемость. Во время RL её поощряют за то, что тесты прошли прямо сейчас. За то, что она обмазала всё try-catch'ами, налепила ленивых кастов типов и срезала углы - штрафа нет. "There is no penalty for eroding codebase maintainability". Оно ж логично: benchmark проверяет одно - "тесты зелёные?".

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

Что важнее при разработке с ИИ - промпт или обвязка?

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

Dex формулирует жёстко: "Claude Code won because it was better, and that it was better because Anthropic RL'd the model inside the harness". Вот это ключевое. Клод выиграл не потому, что у кого-то обвязка кривее, а потому что Anthropic дообучала модель прямо внутри своего харнесса. Владеешь весами и тренируешь их под свой тулинг - бьёшь любой промпт-инжиниринг соседней команды. А если ты просто оборачиваешь нейросеть для кода в свои скрипты, у тебя на руках только та половина, которую видно.

Что говорят цифры про качество, когда кода становится больше?

Больше кода - больше багов, и это уже не ощущение, а замеры. WSFF ссылается на отчёт Faros AI: при высоком внедрении ИИ инциденты на PR выросли на 242,7%, баги на разработчика - на 54%, а доля PR, влитых вообще без ревью, - на 31,3%. Ускорение реально. Только оно приезжает в комплекте с прод-авариями.

Отдельно свежий Faros AI Engineering Report 2026 - выборка серьёзная, 22 000 разработчиков в 4 000 команд. Там соотношение инцидентов к PR при высоком внедрении ИИ выросло больше чем втрое. Не на проценты, в разы. Причём чем глубже внедрение, тем хуже связка "скорость против качества", а не наоборот.

И самая честная часть эссе - про себя. HumanLayer сами ушли в lights-off в июле 2025, поймали серию прод-аварий, а к ноябрю сели переписывать куски с нуля. Два инженера, две полные недели, руками. Живые люди чинили то, что "фабрика" налепила без присмотра. Знакомо до боли.

Что ИИ-программист всё ещё не потянет без человека?

Всё, где принимаются решения о дизайне до написания кода. WSFF раскладывает это на четыре этапа, которые пока держит человек: продуктовые требования (что вообще нужно людям), системная архитектура (формы эндпоинтов, модели данных), дизайн программы (сигнатуры типов, стек вызовов, раскладка файлов) и вертикальные срезы (проверка изменения живьём в браузере или API, а не только по горизонтали компонентов).

Смысл в том, чтобы ловить непонимание, пока оно дешёвое. "30 minutes of planning saves hours of review" - полчаса на план экономят часы ревью. Поймать кривое допущение на этапе плана стоит копейки. Поймать его после того, как агент выкатил 2000 строк, которые уже страшно трогать, стоит недели. Разница как раз в цену того самого рерайта.

А почему нельзя просто научить модель самой отличать хороший код от плохого? Потому что у поддерживаемости нет быстрого оракула. Dex говорит прямо: "if a model could reliably tell good code from bad, it might have written the good version to begin with, but maintainability has no fast oracle". Если бы модель надёжно видела разницу, она бы сразу писала хороший вариант. Тесты - это быстрый оракул для "работает/не работает". Для "поддерживаемо/нет" такого нет, и новые бенчмарки вроде Frontier Code пока только пытаются подсунуть модель-судью.

Что это значит для самодельного пайплайна?

Если у тебя свой конвейер на ИИ-агентах, вывод простой: не убирай человека из цикла, убирай его из рутины. Я это понял на своём пайплайне для блога. Он собирает темы, пишет черновик, гоняет проверку по скоркарте, вносит правки по комментам - но не публикует сам. Черновик уходит в статус review и ждёт, пока я не гляну в админке. Прямо сейчас, когда пишу это: drafts-list показывает 3 черновика в review из 47 - три штуки висят и ждут человека, и это нормально.

Разбивка на стадии - это как раз те самые "фазы с человеком", только для контента. В git-логе так и осталось: "перепроверка после правки в админке", отдельный "стоп-чек утечек" в проверяющей стадии. Ни одна стадия не имеет права опубликовать текст мимо меня. И самое важное - генерация намеренно троттлится: в README живёт gen_review_limit, анти-завал, при котором "при N черновиках площадки в review новые для неё не генерятся". То есть система сама тормозит, пока я не разгребу очередь. Это ровно та мысль WSFF, только своими руками: не давать конвейеру убегать вперёд человека.

Забавно, что до эссе я считал это костылём - мол, "ну да, руками апрувлю, потом допилю автоматику". А оказалось, это не костыль, а единственная часть, которая держит качество. Автоматика вокруг - обвязка. А оракул качества - всё ещё я.

Как это применить у себя?

Двигаться в 2-3 раза быстрее безопасно можно, а вот "в 10-100 раз, качественно, и никто не читает код" - нельзя. Из трёх обещаний одновременно сбывается только одно. Поэтому:

• Держи человека на дизайне, а не на печати. Пусть агент пишет, но требования, архитектуру и сигнатуры утверждай сам, до кода.
• Не полагайся на "тесты зелёные" как на признак здоровья. Это оракул для работоспособности, не для поддерживаемости.
• Встрой в свой пайплайн явный тормоз. Очередь на review, лимит незакрытых черновиков, стоп-чек - что угодно, лишь бы конвейер не убегал вперёд человека.
• Считай цену рерайта. Полчаса плана против двух недель ручного переписывания - это не абстракция, это реальный счёт HumanLayer.

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

Обвязки мало. Обвязка - это половина, которую видно. Вторая половина - обучение модели, которую ты не контролируешь, и человек в цикле, которого пока никем не заменить. Так что свет в офисе пока не гасим. А я пойду разгребать те три черновика в review.