Почему фабрики ПО терпят неудачу

Аргумент Декса Хорти с подзаголовком "harness engineering is not enough" заключается в том, что полностью автономная фабрика ПО ("lights-off") пока работать не может, и никакой scaffolding этого не исправит: корень проблемы - в обучении моделей для написания кода. В начале он прямо заявляет о собственной предвзятости: он руководит HumanLayer, которая как раз продаёт решения этой проблемы, - а в конце статьи переходит к питчу. Сохранить стоит именно середину.

Это тот же репозиторий, что и прогон SlopCodeBench в benchmarking-opus-5-slopcodebench, и оба документа напрямую спорят друг с другом: вынесенную в цитату фразу "THERE ARE NO GOOD BENCHMARKS for a model's ability to maintain codebase quality" Хорти частично дезавуирует в более позднем посте, когда такой бенчмарк всё же находится.

Питч, против которого он выступает

Полностью автономная фабрика ("lights-off factory", термин Дэна Шапиро, который Саймон Уиллисон разбирал, когда StrongDM описали свою) - это фабрика на базе агентов, из которой выкинули этап ревью кода человеком. Логическая цепочка проста: узкое место - вы, модели достаточно хороши, код бесплатен, выкатывайте больше. Райан Лопополо из OpenAI описал harness engineering и рассказал об их фабрике Symphony; Ramp, Stripe, WorkOS и Brex публиковали материалы о собственных агентных платформах, поставляющих порядка 75% их кода.

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

В противовес этому - отчёт Faros AI по командам, внедрившим эти инструменты примерно в январе: комментариев на ревью стало на 25% больше, они стали длиннее на 22.7%, 31.3% PR сливаются вообще без ревью, число инцидентов на PR выросло на 242.7%, число инцидентов в месяц - на 57.9%, багов на разработчика - на 54%. Сам Хорти отмечает, что это лишь корреляция, а не неопровержимое доказательство, причём в посте, главная мысль которого - не доверять мусорным данным.

HumanLayer провели этот эксперимент в июле 2025 года, и он провалился ровно так, как, по его словам, происходит всегда. Вы упираетесь в проблему, которую агент не может решить ни при каком объёме исследований или попыток воспроизведения, и вам приходится возвращаться в кодовую базу, которую вы перестали читать три месяца назад, пока сервис лежит. На третий раз, в ноябре, они решили, что переписать код с нуля дешевле, и его сооснователь провёл две недели в VS Code, вручную переделывая архитектурные паттерны.

Почему модели так себя ведут

Утверждение сформулировано узко: модели не способны поддерживать и улучшать качество кодовой базы во времени без управления со стороны человека. Поддерживаемость здесь означает конкретную вещь, когда изменение одной части ломает другую, - "стрельбу дробью" (shotgun surgery) по Фаулеру. Он признаёт, что модели стали значительно лучше решать разовые задачи и делать лендинги, но утверждает, что практически не видит прогресса в качестве на дистанции, соглашаясь при этом, что не может строго доказать ни то, ни другое, так как это ничем не измеряется. Окно до момента, когда написанная агентами кодовая база начинает сопротивляться любым изменениям, сжалось с десятилетнего горизонта в духе энтерпрайзной Java до трёх-шести месяцев.

Чтобы объяснить причину, он обращается к процессу обучения моделей. Общепринятое объяснение взлёта Claude Code - вовсе не дистрибуция: aider, cline и codebuff появились раньше и имели тот же набор инструментов (read/write/edit/grep/bash) и действительно хорошую работу с контекстом, но с правками они лажали достаточно часто, чтобы вы открывали редактор и правили всё сами. Anthropic применила RL к модели внутри самого harness'а - впервые лаборатория обучала модель под те самые инструменты, с которыми её и поставляла. Статья 2024 года по SWE-Agent уже показала, насколько важны мелкие детали интерфейса инструментов - номера строк в результатах чтения, find/replace против правок по диапазону строк, - а контроль над весами превращает это из раскопок промптов в полноценное обучение. Это scaffold-model-fit, увиденный со стороны вендора: если итоговый результат равен произведению возможностей модели на scaffold, выигрывает лаборатория, контролирующая оба сомножителя.

Сам цикл RL состоит из трёх шагов, повторяющихся неделями: сгенерировать трассы агента на задаче, оценить их верификатором, сдвинуть веса в сторону хороших трасс. Оценка - то место, где всё ломается. Возьмём SWE-bench Multilingual, чьи задачи - это примерно 15 минут работы, собранные из репозиториев вроде Redis, jq и Django. Награда равна единице или нулю в зависимости от двух условий: FAIL_TO_PASS (исправлена ли заявленная проблема) и PASS_TO_PASS (не сломано ли всё остальное). Его наглядный пример - fastlane__fastlane-19304, где действие архивации вызывает .empty? на двух опциональных параметрах и падает с ошибкой undefined method 'empty?' for nil:NilClass; человек исправил это за две строки, задав обоим значения по умолчанию []. Модель стартует с коммита перед фиксом, видит баг-репорт и никогда не видит эталонный патч или проверочный тест. Её собственные правки в тестовых файлах отбрасываются (моделей не раз ловили на том, что они комментировали падающий тест или подставляли мок), сверху накладывается тестовый патч бенчмарка и запускается тестовый набор.

Ничто в такой оценке не видит дизайн. То, как модель пришла к результату, значения не имеет, поэтому ничто не штрафует за оборачивание всего в try/catch или обход системы типов ради того, чтобы полоса тестов стала зелёной. Хорти оговаривается, что бенчмарки - это не верификаторы, и их нужно исключать из обучающей выборки; он имеет в виду сам характер вынесения суждения, а не конкретный датасет.

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

Он отмечает три попытки двигаться в правильном направлении: задачи SWE-Marathon длительностью около 400 часов с составным каналом вознаграждения вместо одного бита; задачи DeepSWE на базе опенсорсных репозиториев, которые на самом деле никогда не существовали (это решает проблему утечки данных в обучение, но не проблему качества); и Frontier Code от Cognition, который оценивает задачи из нескольких PR и делает две детерминированные вещи: штрафует тесты, которые не падают на коде до патча (приём из мутационного тестирования), и прогоняет модель-судью по диффу с проверкой правил качества кода. Его возражение против судьи - самая хлёсткая фраза во всём посте: если бы модель могла надёжно отличать хороший код от плохого, она, вероятно, сама бы написала хороший вариант. Для RL нужен быстрый и надёжный оракул, а у поддерживаемости его нет. Больше агентов-ревьюеров и больше токенов поднимают нижнюю планку, отлавливая глупые ошибки; верхнюю планку они не сдвигают, потому что потолок задаётся тем, чему смог научить RL.

Включение света обратно

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

Product review фиксирует суть и цели задачи на языке пользователя, а также метрики, на которые вы будете смотреть после релиза, чтобы понять, стоило ли вообще браться за разработку: время выполнения сценария, этапы онбординга, процент ошибок, а иногда просто "обращения в поддержку по поводу X прекратились". Он набрасывает экраны в виде простого HTML вместо их словесного описания, исходя из того, что макет гасит спор, который три абзаца текста лишь затянули бы.

System architecture описывает взаимодействие сервисов, эндпоинтов, схем, очередей и хранилищ с помощью диаграмм последовательности, описания контрактов и определений таблиц. Он предупреждает, что mermaid может создать иллюзию полного согласия там, где его нет, и что архитектура сама по себе ещё не гарантирует качественный код.

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

Vertical slices противостоят горизонтальному планированию, к которому модели тяготеют по умолчанию (сначала миграции, затем сервисы, затем API, затем фронтенд), из-за чего до самого конца процесса невозможно ничего пощупать руками. До появления ИИ его привычкой было начинать с середины и двигаться наружу: мок-контракт API, протестированный через curl, фронтенд поверх мока, подключение к сервисам, затем миграции, затем бизнес-логика и обработка ошибок с проверкой на каждом шаге. До появления агентов никто не писал 500 строк кода без промежуточной проверки.

Такой подход применяется не ко всему. Примерно 40% задач решаются с одной попытки (one-shot) или с одной попытки с минимальной доработкой, для средних задач продуктовый и системный дизайн объединяются в один документ без разбиения на фазы, и только крупные задачи проходят через все четыре этапа. Он отправляет в работу от одного до трёх срезов за раз и вычитывает код по мере поступления, потому что перенаправить агента на 200 строках несоизмеримо дешевле, чем оказаться перед 2000 строк, понятия не имея, что именно пошло не так.

Формулировка, к которой он приходит относительно объёма PR: у вас не слишком много pull request'ов, у вас слишком много плохих pull request'ов. PR, требующий переделки хотя бы на 20%, становится обузой и для автора, и для ревьюера, а у сгенерированных ИИ с первой попытки PR этот показатель он оценивает ближе к 50%. Это тот самый потолок пропускной способности, который количественно описывает code-review-throughput-limits, и коллапс сигнала усилий из code-review-principal-agent и agent-principal-agent-problem, только возникающий со стороны процесса обучения. Эта позиция прямо противоречит подходу testing-heavy-no-review-workflow, который решает ту же проблему узкого места за счёт ставки на рандомизированное тестирование вместо живых читателей, и наполовину согласуется с control-the-ideas-not-the-code: оба автора оставляют человеку проектирование, а не вычитку строк, но antirez готов перестать читать diff, тогда как Хорти - нет. reviewing-ai-code и short-leash-ai-method представляют собой две крайности того же спора, а constraint-decay-backend-agents служит ближайшим замером его главного тезиса, показывая, как агенты теряют около 30 процентных пунктов успешных проверок по мере накопления реальных ограничений окружения.

В заключение он предлагает не прогноз, а теорию ограничений: изучите слабые места моделей, выстройте процесс вокруг этих ограничений, ищите точки приложения усилий, читайте код. Компромисс, который он предлагает, - безопасный рост в 2-3 раза против 10-100-кратного ускорения, за которое, по его мнению, расплачиваются качеством кодовой базы. Марио Цехнер, чей pi-coding-agent служит минимальным рабочим примером противоположного подхода, цитируется здесь с призывом ко всей индустрии сбавить темп, а clean-code-coding-agents приходит к той же дисциплине со стороны экономики токенов, а не поддерживаемости.