Почему «фабрики программного обеспечения» терпят неудачу

или: одной упряжи недостаточно

Обновление — видеоверсия этого поста доступна на YouTube: https://www.youtube.com/watch?v=Ib5GBkD555M

похоже, мы теперь делаем циклы

Мы все спешим запустить AI-кодинг в продакшн. О лупах (loop engineering) сказано много, и общепринятая мудрость гласит: надо писать больше циклов.

StrongDM написали о своей «фабрике в темноте», где код не читает ни один человек и не пишет ни один человек.

Нарратив примерно такой:

1. Ты — узкое место.
2. Модели достаточно хороши.
3. Код бесплатен.
4. Просто выпускай больше.

Райан Лопополо из OpenAI написал об этом в феврале и выступил в апреле о софтверной фабрике OpenAI, Symphony.

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

ну, это... как бы работает

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

Как Мэтт Покок выразился, кодовые базы разваливаются быстрее, чем когда-либо.

Мне не удалось найти никаких окончательных данных/результатов от StrongDM о том, как прошла та «тёмная фабрика». Отчёт о погоде содержит несколько редких обновлений с февраля по июнь этого года. правка — есть обсуждение с командой на Hacker News от 23 июля — похоже, скоро появится более формальное обновление!

Ребята из Faros AI опубликовали отчёт: с тех пор как мы2 все подхватили эти AI-инструменты для кодинга ещё в январе-феврале, качество ревью пул-реквестов сильно упало.

• Больше комментариев, длиннее комментарии, и куча PR'ов мерджится вообще без ревью.
• Инцидентов стало намного больше.
• Багов на разработчика стало намного больше.

Этот отчёт — скорее сигнал корреляции, чем неопровержимая улика (да, я намеренно выбрал это слово, не начинайте про прозу Клода), и весь смысл этого поста — остерегаться мусорных данных, но ощущение верное, судя по тому, что я видел.

«Ты держишь это неправильно» (нет)

Многие скажут вам, что это проблема навыков — если у вас не получается, виноваты вы сами.

Но как бы вы ни выбрали... эм... держать это, я гарантирую, вам говорят: если токен-максинг (token-maxxing) не работает, это проблема навыков. Просто надо тратить больше токенов. Перестать читать код. А если вы только начинаете, обещаю, это часть процесса. Я тоже так думал прошлым летом.

К сожалению для моего эго, некоторые глупости, которые я решил сказать о том, «как держать это лучше», были записаны и теперь набрали около миллиона просмотров на YouTube. Я не хвастаюсь, я делюсь этим только чтобы показать, что я глубоко изучал лучшие способы использования кодинг-агентов очень давно и обнаружил некоторые вещи, которые многие сочли действительно полезными.

• Advanced Context Engineering for Coding Agents
• No Vibes Allowed -- Solving Hard Problems in Complex Codebases
• Everything We Got Wrong About RPI

В любом случае, обещание всей этой болтовни в интернете «просто дави токенами сильнее», которую мы вынуждены терпеть, кратко: с помощью достаточной инженерии упряжи мы можем получить лучшее из двух миров:

• в 10–100 раз быстрее,
• высокое качество,
• и никому больше не придётся делать то, что мы все ненавидим — код-ревью.

Всё, что нужно — настроить больше линтеров и добавить магические слова вроде «состязательное ревью» на достаточное количество ботов для PR, и наше ПО будет счастливо строить себя само, без инцидентов.

Это не проблема навыков

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

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

В этом посте я пройдусь по:

1. Софтверные фабрики существуют с 1968 года, как они развивались и как AI их изменил.
2. Почему модели могут генерировать горы мусора, несмотря на отличные результаты в бенчмарках (даже в новейших «передовых»).
3. Несмотря на это, можно двигаться довольно быстро, не поджигая свою кодовую базу.

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

Видеоверсия: этот пост основан на (и расширяет) мой ключевой доклад на AI Engineer World's Fair 2026.

Спасибо @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins и @jeffreyhuber за отзывы к этому посту.

Отступление: это не имеет отношения к вайб-кодингу

Адди Османи распутал эту штуку, которую стоит выделить:

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

Если вы любите вайб-кодинг, пожалуйста, продолжайте вайбить. Я сам всё ещё вайб-кожу много вещей, но я также поддерживаю много продакшн-ПО (и через HumanLayer помогаю тысячам других инженеров делать то же самое), так что остальное предназначено для людей, решающих сложные задачи в комплексных кодовых базах.

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

Краткая история софтверной фабрики

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

Единственное, что я нахожу очень интересным с тех пор — это 31-страничный PDF Министерства обороны США о том, как DoD нужно лучше использовать Jenkins или что-то в этом роде.

Софтверная фабрика 2022 года

Давайте определим нашу «софтверную фабрику» примерно 2022 годом, прямо перед AI. В типичной софтверной фабрике:

• Люди решают, что строить — инженеры, продакт-менеджеры, руководство, задающее видение.
• Это попадает в трекер — Linear, Jira, что угодно: конечный автомат того, что нужно сделать.
• Кто-то берёт задачу и делает её — вероятно, попутно проводит ручное/автоматизированное тестирование.
• Пулл-реквест — автоматические проверки, человек ревьюит код, возможно, кто-то скачивает и тестирует.
• Что-то не так? Возвращаемся к «кто-то делает задачу».
• Выкатываем в прод — и оно встречается с пользователями.
• Добавляем мониторинг — целая индустрия создана для того, чтобы разбудить инженера в 3 часа ночи, когда что-то ломается.
• Пользователи жалуются — просят что-то, находят баги, подают запросы на функции → обратно команде, чтобы добавить в трекер.

И так далее, и так далее. Мы ещё даже не дошли до AI, а на картинке уже несколько циклов.

Выравнивание на раннем этапе

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

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

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

Мы вернёмся к этому позже — давайте посмотрим, что происходит, когда в игру вступает агентный кодинг.

Агентная софтверная фабрика

Теперь каждая компания и её мать —

• Ramp
• Stripe
• WorkOS
• Brex

— потратила большую часть этого года на объяснения, как они построили агентную фабрику, которая выкатывает порядка 75% их кода.

Агентная фабрика в основном выглядит как замена «кто-то делает задачу» → «агент делает задачу» — здесь есть кое-что вроде оркестрации, упряжи, песочницы, модели, computer use и т.д. Я не буду углубляться в эти детали, потому что, честно говоря, меня тошнит от чтения об этом, и я уверен, вас тоже.

Когда агент делает задачу:

• Разработка падает с часов или дней до минут или часов.
• Ревью всё ещё занимает часы или дни. Человек всё ещё должен читать код и тестировать изменение. Так что ревью теперь становится узким местом.

Поэтому вы ускоряете и ревью:

• Агентное ревью кода — для выявления стиля, багов, безопасности.
• Агентное регрессионное тестирование — чтобы прощупать его снаружи с помощью браузеров и computer use, и, возможно, прислать вам милое маленькое видео, когда всё готово.

Теперь ревью быстрее, но, вероятно, всё ещё остаётся узким местом. Но мы можем делать больше циклов.

Далее можно направить инциденты в фабрику. Вместо того чтобы будить кого-то в 3 ночи, они просыпаются и видят PR, который, возможно, уже всё чинит.

Мы также можем направлять отзывы пользователей в фабрику. Люди просят что-то — это строят.

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

Что подводит нас к софтверной фабрике в темноте.

Софтверная фабрика в темноте

Дэн Шапиро ввёл этот термин, а Саймон Уиллисон написал о реализации StrongDM — где мы больше не читаем код.

Вы смотрите на свою прекрасную софтверную фабрику. Её портит этот надоедливый маленький шаг код-ревью, и вы говорите: знаете что, а давайте без этого, когда человек читает каждое изменение? Нет, спасибо.

Поэтому вы отбрасываете его и переносите усилия в другое место:

• Инвестируете в тестирование и позволяете агенту тестировать свою собственную работу.
• Инвестируете в песочницы и оркестрацию.
• Инвестируете в автоматизированное ревью.
• Инвестируете в мониторинг.
• Инвестируете в развёртывание.
• Инвестируете в сбор сигналов обратной связи от пользователей.

И теперь задача действительно сводится к одному вопросу: сколько всего мы можем попросить агента построить? Какую часть океана мы хотим выпарить?

Это будет отлично (нет)

Я выдвину потенциально спорное утверждение: фабрика в темноте не работает.

Давайте разберёмся, почему софтверные фабрики терпят неудачу.

Мы пробовали это

В июле 2025 года мы ушли в полную темноту. Просто читали спецификации и тикеты, фоновые агенты для всего мелкого/среднего, всё как полагается.

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

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

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

А тем временем:

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

В первый раз, когда это случилось с нами, я отмахнулся. Хотя я только что провёл почти две недели, копаясь в спагетти от Клода, «риск провала был оправдан скоростью». К ~третьему разу в ноябре мы решили, что проще переписать всё с нуля, и мой сооснователь потратил целых две недели в VS Code (даже не в Cursor), выкладывая все паттерны вручную.

модели со временем ухудшают качество кодовой базы

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

Когда я говорю о поддерживаемости, я имею в виду конкретную вещь, когда становится очень, очень трудно изменить одну часть кодовой базы, не сломав другую. Это «дробовик» (shotgun surgery) Мартина Фаулера.

Я не буду много говорить о поддерживаемости. Есть куча книг, которые вы можете прочитать:

• Джон Оустерхаут, Философия дизайна ПО
• Роберт Мартин, Чистый код
• Мартин Фаулер, Рефакторинг

Итак, почему модели не могут заниматься поддерживаемостью ПО?

«Но с тех пор модели же стали намного лучше»

На этом моменте вам, возможно, не терпится сказать: но Декс, с июля модели же стали намного лучше

Они стали — в некоторых аспектах. В других — примерно такие же.

• Решать одноразовые задачи или вайб-кодить новый маркетинговый сайт? Да. Намного лучше.
• Улучшать качество кодовой базы со временем? Не намного лучше, насколько я могу судить.

Я не могу это доказать. Вы тоже не можете. Не существует хороших бенчмарков для способности модели поддерживать качество кодовой базы. (Подробнее о том, куда это движется, позже.)

НЕ СУЩЕСТВУЕТ ХОРОШИХ БЕНЧМАРКОВ для способности модели поддерживать качество кодовой базы

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

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

Claude Code победил благодаря обучению с подкреплением внутри упряжи

Claude Code прошёл путь от нуля до ~$4B — теперь уже около ~$9B — выручки менее чем за год.

Что немного дико, потому что уже были отличные CLI-агенты. aider, cline, codebuff — все они появились раньше Claude Code, все со встроенной действительно хорошей инженерией контекста, все с тем же набором инструментов, который можно приписать Claude Code: read, write, edit, grep, bash. Я пользовался ими. Они были хороши. Но также использование инструментов иногда... просто не удавалось — вы наблюдали, как он бьётся над одним и тем же правкой три раза, и снова открывали свой редактор, чтобы сделать это самому.

Статья SWE-Agent от 2024 года описывает, как небольшие изменения в форме инструментов приводят к заметным различиям, например, включение номеров строк в результаты ReadFile или изменение инструмента Edit с поиска/замены на правки по диапазону строк.

Затем появился Claude Code и довольно быстро взлетел по вертикали. Можно отмахнуться, что это дистрибуция, но общепринятое объяснение таково: Claude Code победил, потому что был лучше, и был лучше, потому что Anthropic применили RL к модели внутри упряжи — впервые лаборатория обучила модель на тех самых инструментах, с которыми собиралась её выпустить. И она стала действительно, очень хорошо вызывать эти инструменты в агентном цикле.

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

Команда OpenAI выступила в ноябре и довольно хорошо это сформулировала: если вы строите упряжь, но не владеете весами и не можете применить RL к модели внутри неё, вы всегда будете в проигрыше по сравнению с командой, которая владеет и тем, и другим.

RL для кодинг-агента за 60 секунд

Я провёл много исследований на эту тему и приготовил кучу визуализаций, чтобы попытаться объяснить важные части, но обнаружил, что Калвин Френч-Оуэн (MTS в команде codex, основатель Segment) сделал доклад на AI Council, который справился с задачей намного лучше и чище, так что я просто вставлю эту анимацию, вдохновлённую его слайдами:

Чтобы сделать модель лучше в кодинге, вы:

1. Генерируете несколько трасс кодинг-агента для решения задачи (например, исправить мои тесты).
2. Оцениваете трассы по определённым критериям (верификатор).
3. Обновляете веса модели, чтобы сделать хорошие трассы более вероятными, а плохие — менее вероятными.

И вы делаете это миллионы раз в течение недель или месяцев.

Однако «оценка» в таких вещах может быть склонна к одномерности.

Нет штрафа за плохой дизайн

Возьмём SWE-bench Multilingual. Задачи небольшие — примерно пятнадцать минут работы каждая — извлечены из open-source репозиториев, таких как Redis, jq и Django. Награда — единица или ноль, основанная на:

• FAIL_TO_PASS — исправил ли ты то, что просили исправить?
• PASS_TO_PASS — сделал ли ты это, не сломав ничего другого?

Вот реальная задача, fastlane__fastlane-19304, из fastlane — Ruby-проект. Его zip-действие берёт два опциональных параметра и сразу вызывает на них .empty?, так что если опустить include и exclude, оно падает:

Человеческое исправление, закрывшее этот конкретный issue, — две строки (установить nil в пустые массивы по умолчанию):

Во время оценки модель:

1. Начинает с базового коммита — репозиторий на момент прямо перед тем, как было внесено исправление.
2. Отчёт о баге — в данном случае 'zip_command': undefined method 'empty?' for nil:NilClass.

Агент идёт и пишет код на основе issue. Он не видит золотого патча или тестового патча, который служит оценщиком:

Затем:

1. Мы сохраняем любой патч, который он создал.
2. Выбрасываем любые правки, которые он сделал в тестовых файлах (мы застали модель, тихо комментирующую проваливающийся тест или вставляющую mock, который делает тест бесполезным).
3. Применяем поверх тестовый патч бенчмарка.
4. Запускаем весь набор: существующие тесты zip (PASS_TO_PASS) плюс новый (FAIL_TO_PASS), чтобы увидеть, проходят ли оба.

Отступление — Бенчмарки — это не верификаторы; на самом деле их нужно держать изолированными друг от друга (не тренироваться на тестовых данных, и всё такое) — я в основном имею в виду передать форму «оценки качества трассы кодинг-агента» и её ограничения.

Как модель пришла к правильному ответу, неважно. Если тесты проходят, мы победили, но нет штрафа за ухудшение поддерживаемости кодовой базы.

нет штрафа за ухудшение поддерживаемости кодовой базы

Вот почему у вас получаются try-catch вокруг всего:

Проверка качества на порядки сложнее, чем «прошли ли тесты»

Запуск тестов даёт чёткий проход/провал за ~секунды. Вот почему RL может выполнять миллионы циклов для оптимизации каждого поколения модели.

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

Тесты дают обратную связь за секунды, но функция стоимости плохой архитектуры измеряется неделями, месяцами, а может, и годами

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

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

Передний край медленно становится лучше

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

Несколько усилий, которые, на мой взгляд, движутся в правильном направлении:

• SWE-Marathon (Abundant AI): задачи на ~400 часов, например «склонировать весь Excel, каждую функцию» — с составным каналом вознаграждения вместо одного бита проход/провал.
• DeepSWE (Datacurve): большие задачи на OSS-репозиториях, которые никогда не были построены в реальном мире, поэтому по построению они не могут уже находиться в обучающем наборе (решает проблему контаминации, но не качества).
• Frontier Code (Cognition): задачи с несколькими PR, и умный ход, который оценивает качество детерминированно — он штрафует модель за написание тестов, которые не проваливаются на коде до патча (если вы никогда не слышали о мутационном тестировании, вас ждёт увлекательное чтение5). Он также запускает модель-судью над diff'ом, проверяя правила качества кода.

Но модель, оценивающая качество, может зайти лишь так далеко.

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

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

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

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

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

Отступление Возможно, будущая модель просто поймет это, и мы сможем остановиться. Если хотите импульсивно отправлять промпты до выхода GPT-7 и узнать это — пожалуйста, но к черту горький урок, у нас есть проблемы, которые нужно решать сейчас, и я расскажу, как мы это делаем.

Снова включаем свет

Сегодня я узнал, что у статей в Twitter есть «ограничение на медиа», поэтому остальная часть пойдет в пост второй части — следите за обновлениями.