Почему «фабрики ПО» терпят неудачу: как вернуть контроль над разработкой

Это часть вторая Почему программные фабрики терпят неудачу

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

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

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

Пока что судья — это вы, так что мы возвращаем код-ревью на место.

Мы принимаем то же самое, что делали и до появления ИИ: выполняем немного планирования заранее, чтобы снизить вероятность долгого и сложного ревью.

Мы будем искать точки опоры и использовать ИИ, чтобы помочь с этим, в четыре этапа:

• Требования к продукту
• Системная архитектура
• Проектирование программы
• Вертикальные срезы

Ревью продукта

Всё начинается с ревью продукта: короткого документа, который фиксирует что мы строим и почему. Цель — взять два предложения или длинную голосовую заметку и превратить их в нечто полуструктурированное.

Сначала мы согласуем проблему, которую нужно решить — реальную боль пользователя, его же словами. Затем — как выглядит успех — что мы сможем прочитать после релиза, чтобы понять, стоило ли это строить. В идеале это результат для пользователя вроде «может выполнить рабочий процесс XYZ быстрее» или «достигает этапа онбординга ABC раньше». Иногда это более низкоуровневые метрики, например, частота ошибок или задержка, а иногда просто «обращения в поддержку по теме X прекратились».

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

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

Вот реальный пример в работе — документ фиксирует функциональность с помощью JSON-схемы, а затем два грубых HTML-макета реальных экранов:

https://x.com/dexhorthy/status/2078592010852982977

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

Для этого и всех последующих документов мы используем ревью с согласия автора. Если хотите сэкономить время на ревью, вы выбираете человека, который будет проверять PR, и проходите с ним продуктовые и технические спецификации — асинхронно через комментарии к документу (мы сами используем для этого HumanLayer, но вы с тем же успехом можете делать это в GitHub/Notion/Plannotator и т.п.).

Системная архитектура

Как только продуктовое ревью согласовано, мы переходим к системной архитектуре. Это не особенно ново, и даже виб-кодеры начинают это практиковать.

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

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

Формы контрактов и эндпоинтов:

Модели данных и преобразования:

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

Проектирование программы

После архитектуры мы делаем то, что, на мой взгляд, преступно недооценено в агентном кодинге: проектирование программы.

Большинство людей считают, что если архитектура правильная, то модель может просто «сварить». Можете попробовать, но результат может вам не понравиться.

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

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

Деревья стеков вызовов — для любых изменений в оркестрации или потоке управления. Используйте синтаксис diff, когда интересно именно то, что меняется:

Dillon Mulroy говорит об использовании графов вызовов как части процесса планирования, и я считаю, что это абсолютно верно.

Диффы файловых деревьев — чтобы оставаться в курсе структуры вашей кодовой базы и расположения файлов:

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

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

Вертикальные срезы

Затем мы любим делать то, что я называю «вертикальными срезами» — мы с Мэттом Пококом обсуждали вертикальные срезы или «трассирующие пули» на стриме в январе 2026 года — это также называют трассирующими пулями.

Модели любят то, что я называю «горизонтальными планами» — выполнение задач в порядке стека:

1. Миграции базы данных
2. Сервисный слой
3. API
4. Фронтенд

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

До появления ИИ было редкостью, чтобы кто-то написал 2000+ строк кода или даже 500 строк, не проверив что-то по пути.

Мне потребовалось время, чтобы заметить разницу с тем, к чему я привык: когда я писал код до ИИ, я всегда начинал с середины и двигался наружу. Примерно так:

1. Создать контракт API и отдавать мок-данные, протестировать через curl
2. Создать фронтенд для потребления мок-данных, итерировать и полировать в браузере
3. Привязать API к сервисному слою (сервисы отдают мок-данные/поведение)
4. Добавить миграции БД, привязать сервисы к базе данных
5. Добавить кучу бизнес-логики
6. Добавить кучу обработки ошибок

И я тестировал, итерировал и полировал на каждом шаге.

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

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

30 минут планирования экономят часы ревью

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

1. Дизайн продукта
2. Системная архитектура
3. Проектирование программы
4. Вертикальные срезы

Очевидно, мы не проходим весь процесс для каждого релиза (см. сайдквест ниже). Я бы предположил, что распределение примерно такое:

• ~40% задач делаются одним выстрелом или с 1–2 раундами лёгкой обратной связи
• для средних задач мы делаем продуктовый и системный дизайн в одном документе плана и не разбиваем работу на фазы
• для крупных задач мы проходим все шаги. Продуктовую часть пропускаем для того, где она не имеет смысла, например, для больших рефакторингов.

И в большинстве случаев я отправляю модель выполнять 1–3 среза за раз и проверяю код по ходу. Намного проще скорректировать направление на раннем этапе, будь то внутренности или реальная функциональность, чем оказаться по ту сторону 2000+ строк кода, не имея понятия, что сломано.

Вам, вероятно, кажется, что у вас слишком много пул-реквестов

У вас не слишком много PR. У вас слишком много плохих PR.

Мы все проверяли много PR, которые требовали доработки, ещё задолго до ИИ.

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

С другой стороны, если пул-реквест требует даже 20% доработки (и это щедро, я бы сказал, что большинство PR от ИИ одним выстрелом тянут к 50%), это создаёт интеллектуальную нагрузку и эмоциональную нагрузку как на отправителя, так и на ревьюера. (Даже если отправитель — ИИ, кто-то, вероятно, инициировал эту работу, или виб-полировал результат ИИ, или, по крайней мере, заботится о результате.)

Чтобы сэкономить ваше время (мы почти в конце), я поболтал об этом в сайдквесте:

«Куда уходит время»

Теория ограничений (редакция 2026)

Легко немного расстроиться из-за основной мысли: «пока мы вынуждены читать код».

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

Но я постарался изложить здесь лишь ограничения. Модели хороши в одних вещах, не очень — в других. Как оптимизировать свой процесс с учётом этих ограничений?

Возможно, вы слишком заняты попытками двигаться в 10–100 раз быстрее и убеждаете себя, что качество кода больше не имеет значения, тогда как могли бы принять ограничения и двигаться в 2–3 раза быстрее, безопасно.

Мой своего рода заключительный совет таков:

1. Хорошо изучите ограничения, развивайте интуицию, много работая с моделями
2. Оптимизируйте системы в рамках этих ограничений
3. Ищите рычаги
4. Читайте, чёрт возьми, код

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

Спасибо за чтение

-декс

PS Мы одержимы этим

Мы строим humanlayer.com — агентную IDE и платформу для совместной работы, которая поможет вам двигаться в 2–3 раза быстрее, сохраняя качество кода на человеческом (или очень близком к человеческому) уровне.

Мы стремимся к двум идеям: «строительные блоки для вашей программной фабрики» и «лучшие верификаторы поддерживаемости программного обеспечения» (возможно, даже лучшие модели).

HumanLayer бесплатен для небольших команд до 3 человек. Если вам нужна помощь в начале работы, заходите в наш Discord или напишите нам на founders@humanlayer.dev

Быстрая благодарность @calvinfo за вдохновение, моему сооснователю @0xBlacklight, @swyx и команде @aiDotEngineer за то, что дали мне арену для исследования этих идей, а также всем нашим невероятным клиентам, инвесторам, друзьям и семье, которые поддерживают нас.

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

PPS Другие ресурсы

Подкасты и статьи:

• Декс и Гергей обсуждают контекстную инженерию и программные фабрики на The Pragmatic Engineer — июль 2026
• Декс и Мэтт Покок обсуждают вечные советы по ИИ-кодингу (и циклы Ральфа) — январь 2026

Эпизоды AI That Works:

• Бенчмарки ничего не доказывают
• Продуктовые спецификации для ИИ-кодинга
• Обучающие тесты для лучшего обратного давления
• Применение принципов 12-факторных агентов к ИИ-кодингу

Ссылки из этого поста:

• Почему программные фабрики терпят неудачу — ключевой доклад на AI Engineer World's Fair 2026
• Программная фабрика StrongDM с выключенным светом
• OpenAI: Инженерия обвязки (февраль 2026)
• Райан Лопополо о Symphony (доклад, апрель 2026)
• Марио на AI Engineer Europe: «Построение π в мире слопи»
• FT: Сбои Amazon из-за ошибок кодирующих агентов
• Мэтт Покок: кодовые базы разваливаются
• Faros AI: отчёт об ускорении ИИ с эффектом хлыста
• Продвинутая контекстная инженерия для кодирующих агентов (доклад 8/25)
• Виб запрещён (доклад 11/25)
• Всё, что мы сделали неправильно с RPI (доклад 3/26)
• Awesome-RLVR — ресурсы по обучению с подкреплением
• Продвинутая контекстная инженерия для кодирующих агентов (статья)
• 12-факторные агенты
• Адди Османи о виб-кодинге vs. поддержке
• Конференция НАТО по программной инженерии, 1968
• Эталонный проект DevSecOps Министерства обороны США (PDF)
• Платформа кодирующих агентов Ramp
• Stripe: Minions — сквозные кодирующие агенты одним выстрелом
• WorkOS: Project Horizon
• Brex (Latent Space)
• Дэн Шапиро: пять уровней программной фабрики
• Саймон Уиллисон о программной фабрике StrongDM
• «Вычерпать океан»
• Дробовик (refactoring.guru)
• Джон Аутерхаут — Философия дизайна программного обеспечения
• Роберт К. Мартин — Чистый код
• Мартин Фаулер — Рефакторинг
• aider
• cline
• codebuff
• Статья SWE-Agent (2024)
• Доклад OpenAI Codex (ноябрь)
• Кэлвин Френч-Оуэн — Доклад на AI Council
• SWE-bench Multilingual (датасет)
• AIE Worlds Fair 2026 — Великие дебаты о циклах («хайп обгоняет дисциплину»)
• SWE-Marathon (Abundant AI)
• DeepSWE (Datacurve)
• Frontier Code (Cognition)
• Мутационное тестирование (Википедия)
• Диллон Малрой о графах вызовов в планировании
• Декс × Мэтт Покок: вертикальные срезы / трассирующие пули (стрим, январь 2026)
• «Тяжёлая работа мышления не может быть передана на аутсорс» (Джейк Нейшнс)