Фабрика кода с выключенным светом: почему Хорти зовет обратно читать код, и что у меня с этим сходится

Разбор эссе Dex Horthy (HumanLayer) “Why Software Factories Fail (or: harness engineering is not enough)”: GitHub.

Обсуждение на Hacker News.

О чем спор

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

Тезис эссе в два абзаца. Первый: “фабрика с выключенным светом” (lights-off software factory, где код пишет агент, ревьюит агент, тестирует агент, а человек только подкидывает тикеты) сейчас не работает, и обвязкой, по мнению Хорти, это не чинится: нынешним моделям и средствам проверки не хватает надежного сигнала о поддерживаемости, чтобы автономно жить в сложной кодовой базе. Причину он ищет в том, как модели учат и оценивают: на задачах “почини тест” с наградой в один бит. За то, что код при этом стал хуже, штрафа в такой схеме нет. Модели отлично решают разовые задачи и понемногу превращают кодовую базу в спагетти, потому что за спагетти их некому было наказать.

Второй: ревью надо вернуть и сделать дешевым, договорившись до кода. Хорти считает реалистичным безопасное ускорение в 2-3 раза вместо обещанных фабриками 10-100x. Это заодно и обещание продукта HumanLayer, о чем он сам предупреждает в первом абзаце.

На Hacker News эссе набрало 394 очка и 272 комментария, и это сам по себе диагноз: тема болит. Одни соглашаются, другие отвечают “у меня фабрика работает, ты просто застрял в июле 2025-го”. Опыт руководителя проектов мешает принять красивый тезис на веру, поэтому по ходу буду задавать контрольные вопросы.

Где ломается темная фабрика

Фабрика образца 2022 года: тикет, код, ревью, прод, жалоба, снова тикет. Агент ускорил “код” до минут, ревью осталось на часы и стало бутылочным горлышком, и в какой-то момент кто-то спросил: а зачем нам ступенька, где человек читает каждую строчку? Вычеркнуть, сэкономленное вложить в тесты и мониторинг, и дальше один вопрос: сколько тикетов мы успеем засунуть в очередь.

Хорти признается, что сам так и сделал в июле 2025-го: читаем только спеки и тикеты, остальное фоновым агентам. Кончилось тем, что пришлось лезть в код, который три месяца никто не читал, пока лежал сайт; к третьему разу в ноябре они переписали все заново, и кофаундер провел две недели в VS Code, раскладывая паттерны руками.

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

Самая сильная часть эссе - почему модели не умеют в поддерживаемость. Хорти разбирает оценку на SWE-bench Multilingual, оговаривая, что бенчмарк и обучающий verifier это разные вещи и пример показывает форму оценки, устройство обучения он не раскрывает. Задача на пятнадцать минут, награда один или ноль: починил нужный тест (FAIL_TO_PASS) и не сломал остальные (PASS_TO_PASS). Реальный пример из fastlane: два параметра могли быть nil, человек починил двумя строчками с || []. Модель пишет патч, ее правки в тестах выбрасывают (ловили, как модель молча комментирует падающий тест), накладывают эталонный тест, гоняют набор. Как модель пришла к ответу, никого не волнует. Цитирую в переводе: “штрафа за ухудшение поддерживаемости кодовой базы нет”. Отсюда try-catch вокруг каждого вызова и ленивые приведения типов.

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

Оговорки он делает сам, и они мне нравятся больше лозунгов. Доказать тезис он не может: хороших бенчмарков на поддерживаемость пока нет, хотя первые попытки (SWE-Marathon, DeepSWE, Frontier Code с моделью-судьей) он перечисляет. Ревью-боты и лишние токены поднимают пол и ловят глупости. Потолок задан тем, чему модель научили в RL.

Что он предлагает вместо

Свет включаем обратно, и четыре фазы с человеком в цикле. Продуктовое ревью: какую боль решаем и как поймем, что сработало; грубый HTML-мокап закрывает спор, который три абзаца текста только растягивают. Системная архитектура: сервисы, схемы, очереди. Дизайн программы, по словам Хорти, самая недооцененная фаза: деревья вызовов в diff-синтаксисе, диффы файлового дерева, сигнатуры; модель набрасывает, человек спорит, и каждый набросок - решение, которое иначе принималось бы на ревью, в самый дорогой момент. И вертикальные срезы вместо любимого моделями “горизонтального” плана (миграции, сервисы, API, фронт, и до фронта потрогать нечего): Хорти отдает модели один-три среза и читает по ходу, потому что подрулить на 100-200 строках дешевле, чем разбираться в двух тысячах.

Мелочь по-прежнему уходит агенту в один заход, это около 40% задач. В боковой заметке “Where does the time go” он напоминает, что даже до AI написание кода занимало четверть-половину времени фичи, и на условном примере показывает, что около 80% ожидаемой боли снимают первые минуты планирования, а шесть часов планировать задачу, где хватило бы десяти минут, тоже ошибка. Совет на прощание: изучить ограничения моделей, искать рычаг и читать чертов код.

Как это выглядит у меня

Я руковожу проектами и строю разработку с Claude Code и Codex. Конвейер у нас оформлен правилом и называется SDD, spec-driven development. Читая Хорти, я кивал две трети и начал спорить в последней.

Где сходится. Спеку фичи пишет человек с агентом: “что не так сейчас”, “как должно быть” прозой, принятые размены, “не входит”, критерии приемки. Развилки, меняющие продукт, решает человек до первой строчки кода. Это его “front-loading alignment”, и ровно потому же: подрулить на спеке стоит минуты, на диффе часы.

Где расходится. Хорти делает ревью дешевле и оставляет за человеком. У нас оно распилено. Тесты пишет отдельный агент вслепую: видит спеку и публичный контракт, реализацию не видит. Иначе тест проходит, потому что его писал тот же, кто писал код, и оба поняли спеку одинаково криво. Реализацию делает другой агент, субагент Claude или Codex, по спеке и красным тестам. Сверку реализации против спеки делает другая модель: кто писал, тот не сверяет. Правки по сверке идут тому же исполнителю. Мерж при зеленом CI и закрытых замечаниях.

И вот что показала обкатка. Дефекты, которые находит сверка, имеющиеся тесты пропускали: тесты фиксируют критерии приемки, а нарушенными оказываются инварианты, которые никто не догадался проверить. За два дня так нашли 22 нарушения спеки при зеленом наборе из 2650 тестов. CI светился зеленым, сверка принесла 22 замечания.

Тут я обязан задать контрольный вопрос себе, потому что очень хочется объявить победу. Что нашла сверка? Расхождения между спекой и кодом, то есть проверку соответствия требованиям. Хорти говорит о другом свойстве: можно ли через полгода поменять одно место, не разломав три соседних. О долгосрочной поддерживаемости мои 22 находки ничего не доказывают, оракула для RL я тоже не нашел. Нашел я дыру между тестами и замыслом, которую закрыть дешево: прозой и второй парой глаз, пусть и модельных. Спор с Хорти получается о том, куда смотреть человеку, пока оракула нет.

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

Про цену. Сверка второй моделью стоит гейтом на мерж: ожидание идет параллельно работе. Валидируется записка с решением на 10-15 строк, дифф в нее не входит. Это минуты; разбор диффа занимал бы десятки. Хорти про ревью-агентов говорит осторожно: ловят простые ошибки, поддерживаемость не оценивают. Записка хотя бы отвечает на вопрос “что задумано”, с которого любая оценка начинается.

Работает ли это на живом продукте? Антиспам-бот для Telegram (spamogon) прошел от ТЗ до боевого деплоя за два дня по этому конвейеру. Но два дня ничего не говорят о тезисе Хорти: по его приблизительному наблюдению, агентная кодовая база начинает буксовать через три-шесть месяцев. На этой дистанции мне возразить пока нечем, у меня ее нет.

Где я согласен полностью: “читать код” в смысле “смотреть, что реально происходит” остается за человеком. Прошлая моя история была ровно об этом: крон три дня подряд писал “код 0”. Свет надо включать, вопрос только, куда светить. Хорти светит на дифф. Я свечу на спеку, на записку и на отчет сверки.

Что говорят на Hacker News

Самое сильное возражение (fishtoaster): опыт HumanLayer относится к июлю 2025-го, а модели с тех пор сделали скачок, и Хорти этот прогресс недооценивает. В эссе оговорка есть: в разовых задачах модели стали намного лучше, а заметного улучшения поддерживаемости Хорти пока не видит, “насколько могу судить”. Пока хорошей проверки нет, обе стороны опираются на свой опыт.

Самое живое свидетельство с другой стороны (iamwil): восемь месяцев своей фабрики, кодовая база старше года, четыре месяца без чтения кода на ревью; автоматического получения задач и отправки PR, по его словам, пока нет. Но читаем, что у него вместо ревью: долгое интервью с моделью до старта, ревью планов, браузерное QA, состязательное ревью, линтеры, тайпчек, формальные модели состояний в Quint с трассами, которые гоняются как тесты, и прописанные принципы вроде “functional core, imperative shell”. Он признает, что “чувствует” грязь там, где агент повторяет одни и те же ошибки. Это тоже свет, просто направленный на спеку и формальную модель, и это ближе к моему конвейеру, чем к фабрике без человека.

Историю StrongDM тред тоже перебирает: компанию продали, бывший CTO, предположительно, продолжает идею консалтингом, а хороший это знак или плохой, комментаторы так и не договорились. И реплика на стену от janalsncm: “Claude может написать код за тебя, но не может понять его за тебя. Эта часть происходит на человеческой скорости” (перевод мой).

Спор идет и на Хабре, с обеих сторон. Александр Кальницкий из Mindbox в статье “Как довериться AI-агентам, чтобы не ревьюить код” предлагает spec-review вместо code-review: дизайн-документ, разделение на функциональное ядро и оболочку, мутационное тестирование, приемочные тесты на Gherkin, и два сервиса, месяц живущие в проде без инцидентов. Автор статьи “ИИ-фабрика: переход к автономной разработке” строит фабрику, где агенты работают сами, а человека зовут тегом в трекере, только когда уперлись в вопрос или доступы. Первая по духу ближе к четырем фазам Хорти, вторая ставит эксперимент, исход которого он предсказывает. Сам Хорти на Хабре тоже мелькал: в обзоре AI Engineer он упомянут как участник дебатов о том, кто должен читать код.

Что делать в понедельник

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

Практический шаг один. Возьмите ближайшую фичу и напишите ее спеку прозой: что сломано, как должно быть, что не входит, какие размены приняты. Отдайте спеку вместе с готовым диффом модели, которая код не писала, и попросите найти, где реализация нарушает текст. Замечания проверьте сами: модель тоже ошибается. Найденное расхождение при зеленых тестах покажет пробел в ваших проверках; нулевой ответ значит только, что эта модель в этот раз ничего не увидела. Да, это тоже автоматическое ревью, и Хорти прав, что потолок оно не двигает. Но пол оно поднимает, а свет над спекой стоит дешевле, чем свет над каждым диффом.

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