Я отдал разработку автономному ИИ — промежуточные итоги за 178 релизов

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

---

Две недели назад я позвал Хабр ломать мой автономный AI-пайплайн — и заодно накидать своих задач на доработку, чтобы вместе раздуть репозиторий, который этот пайплайн ведёт. Устроено так: живая браузерная игра, любой пишет в бота «что поменять», дальше пайплайн сам уточняет, формулирует, пишет код, гоняет тесты, ревьюит и выкатывает в общий прод — без единого человеческого взгляда на дифф. Я обещал вернуться с тем, что сломается. Пришли, поломали, нагрузили задачами. Вот срез.

И сразу рамка, через которую я теперь смотрю на всё это. Когда у бухгалтера появился Excel, профессия не исчезла — она поднялась на уровень выше. Ценность сместилась с «быстро и без ошибок считать на счётах» на «знать формулы, ВПР, держать структуру таблицы и проверять результат». Программист со счётами — это тот, кто пишет код руками. Программист с Excel — тот, кто строит обвязку и критически проверяет. Весь эксперимент оказался про этот сдвиг — и я увидел его на живых данных.

Спасибо

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

Что произошло за две недели (сухие цифры)

• 178 релизов в боевой билд; 0 строк кода, прочитанных человеком перед мержем.

• ~1.4 млрд токенов сожрали модели (вместе с экспериментами ниже).

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

• Воронка: 194 заявки → 167 одобрено → 159 доехало до прода (93% одобренного). Из доехавших 9 откатились автоматикой, остальное осталось жить.

• +95 840 / −16 790 строк, 199 тест-файлов, 1955 тестов — всё это написал не я.

• Режимов игры: на старте был 1 (тактическая кампания) — сейчас 12 (оборона, перестрелка, MOBA, раннер, платформер, гонки на танках, лабиринт, realtime на реальной карте и др.). Новые жанры — главный источник «добавлений», на которых обвязка проверяется жёстче всего.

• 11 заявок отклонены на входе, из них ~4 — откровенные попытки инъекций.

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

• Время от старта разработки до прода: быстрее всего — 8 минут, типичная задача (медиана) — ~20 минут, 90% уложились в 41 минуту. Среднее — 46 минут, но его тянут вверх несколько застрявших: самая упрямая ехала 13 часов, накручивая круги доработки.

Главная работа теперь — обвязка, а не код

В исследованиях это называют harness — обвязка вокруг модели: роли, правила, проверки, фильтры, структура, разделение ответственности. Звучит скучно и бюрократично — и именно на ней чаще всего экономят. Но как раз она отделяет «ИИ собрал прототип за час» от «ИИ две недели сам ведёт живой продукт».

Если убрать обвязку, модель начинает тащить всё в одно место и решать каждую задачу так, будто она первая и последняя в проекте.*

* Важная оговорка про модели. Весь эксперимент я веду на open-source моделях (GLM, MiniMax, Kimi, Qwen и подобных). Фронтирные SaaS-модели — топовые Claude, GPT, Gemini — вполне могут вести себя иначе: где-то аккуратнее держать структуру, контекст и архитектуру. Так что всё ниже — это срез по open-source, а не приговор «любому ИИ».

И вот тут начинается самое интересное. За две недели накопилось много данных и живых примеров — и у меня было несколько гипотез про то, что именно в обвязке держит проект, а что можно убрать без потерь. Раньше я мог только догадываться. Теперь у меня появился стенд, на котором гипотезу можно не обсуждать, а проверить. Так что я взял промежуточные результаты и устроил череду экспериментов — на каждую ручку обвязки по гипотезе. О пяти самых интересных выводах расскажу ниже.

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

Эксперимент 1. Нужна ли вообще отдельная роль аналитика в пайплайне?

Гипотеза. У меня в пайплайне две похожие роли: формулировщик (уточняет заявку и превращает её в задачу) и аналитик (готовит эту задачу для разработки — оба читают код против задачи и снабжают разработчика конкретикой). Аналитик при этом не бесплатный: он читает кодовую базу и пишет подробный разбор, а это около 20% всей стоимости задачи по токенам. На бумаге он частично дублирует и формулировщика, и разработчика — и кажется, что роль можно убрать и срезать ощутимый кусок бюджета. Гипотеза: аналитика реально слить или выкинуть, ничего не потеряв в качестве.

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

Что вышло. Слитые роли — до релиза доехала 1 задача из 5. Аналитик внутри разработчика — 2 из 5. Раздельные роли — 5 из 5. Разница не на проценты, а в разы.

Вывод. Та самая «экономия 20%» оборачивается падением проходимости с 5 задач из 5 до 1 из 5 — мнимая экономия выходит кратно дороже самой роли. Подготовка задачи — это отдельная работа, и её нельзя ни слить с формулировкой, ни растворить в разработчике. Декомпозиция, правила подготовки, условия готовности и формат, в котором задача доходит до ИИ-разработчика, определяют успех сильнее, чем сама модель-кодер. Лучше, когда роли играют даже разные модели — у каждой свой режим мышления.

Эксперимент 2. Возможен ли «низкий старт» — без обвязки и подготовки?

Гипотеза. Главный вопрос тут шире одного правила: возможен ли вообще «низкий старт» — начать AI-native разработку без дорогой подготовки, без заранее построенной обвязки, правил и рамок? Именно подготовка пугает сильнее всего. Я и сам проделал большую работу над обвязкой; а в крупном энтерпрайзе с десятками систем собрать все роли, назначения, рамки и границы — это месяцы, если не год. Чтобы проверить идею «низкого старта», я взял самый массивный и дорогой в подготовке блок и просто убрал его. И это не «мелкий нейминг и описание папочек», а подробный документ об устройстве проекта: где хранится какой объект, как устроена структура каталогов, как работать с каждым типом объектов, как устроен рендер и с какими объектами он взаимодействует, и так далее. Расчёт был на конкретный механизм: в процессе реализации модель сама проанализирует, «как тут всё устроено», соберёт сложившиеся паттерны и будет действовать по аналогии — то есть выведет всю эту структуру из самого кода. Звучит разумно. Решил проверить.

Что сделал. Убрал этот блок — но не оставил модели вслепую. И аналитику, и разработчику я явно прописал в инструкции: сначала изучи, как устроен проект, и действуй по аналогии с уже существующим кодом. То есть дал тот самый механизм отдельной командой, а не просто понадеялся на него. И на одной небольшой типовой задаче (+300/−50 строк) прогнал её через пять моделей: GLM, MiniMax, Kimi, Qwen и, ради интереса, Claude.

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

Вывод. «Низкого старта» не выходит. Без явных правил даже самые умные модели сыплют файлы в случайные места и хоронят репозиторий за десяток задач. Минимальную несущую обвязку всё равно придётся построить до старта — на самом дорогом блоке подготовки не сэкономить. Подробная карта проекта — где что лежит, как устроены объекты, рендер и связи между ними — это не вкусовщина, а то, что вообще оставляет код читаемым на дистанции.

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

Эксперимент 3. Какова реальная ценность архитектурного документа?

Гипотеза. Документ о направлении проекта, его «вектор», многие держат за формальность: модель и так видит код — нужен ли отдельный текст о том, куда всё движется? Вопрос на самом деле глобальный: какова реальная ценность архитектурного документа — и есть ли она вообще, тем более если задачи приходят разрозненным потоком от живых игроков? Решил измерить ценность самым прямым способом — убрать документ и посмотреть, что отвалится.

Что сделал. У меня есть «вектор игры» — живой документ о том, куда движется игра (его поддерживает в актуальном состоянии сам ИИ). Я его удалил и прогнал первые 10 задач на GLM.

Что вышло. Девять задач прошли гладко. А на десятой — заявке добавить режим tower defence — ИИ без архитектурного контекста решил, что это отдельная игра, и полез строить новый рендер и игровой движок, которые объективно были не нужны. Итог одной задачи: +25 зависимостей и почти +6000 строк на ровном месте.

Вывод. Ценность архитектурного документа неравномерна — и это главное наблюдение. Доработки, мелкие баги, правки в уже готовом модель тянет и без него: контекст задачи локальный, ломать особо нечего. Но как только задача — это добавление (новая фича, новый функционал, контроллер или объект, новая логика), всё меняется. Без архитектурного видения ИИ не понимает, что новое должно прирасти к существующей системе, — и рядом с дорабатываемой системой запросто вырастает её брат-близнец: параллельный движок, дублирующий слой, второй «почти такой же» модуль. Документ-вектор окупается ровно в этот момент — он говорит модели «это часть того, что уже есть: расширяй, а не строй заново».

И деталь со звёздочкой: документ работает только как живой и актуальный снимок настоящего. Ведёте его инкрементально, историей решений (привет, классические ADR) — он превращается в якорь из прошлого. Представьте задачу: «сделай педикюр на правой ноге». Правая нога в проекте уже есть — но отросла она позже той ADR, за которую зацепилась LLM, и в старом документе её ещё нет. И модель, доверившись устаревшей карте, решает, что правой ноги не существует: отращивает себе третью ногу и красит ноготочки уже на ней. То есть цепляется за неактуальное решение и снова плодит дубли. Актуальный снимок — да; путь из принятых решений — нет.

Эксперимент 4. Есть ли у ИИ единые «лучшие практики из коробки»?

Гипотеза. Модели обучены на горах кода — логично ждать, что разумные подходы, а то и «лучшие практики», зашиты у них из коробки: одну и ту же задачу модель будет решать одинаково, да ещё и грамотно. Если так — жёсткий контроль технологий и зависимостей избыточен: единообразие приедет само, а редкие дубли поймает ревью.

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

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

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

Эксперимент 5. Можно ли дёшево разгрузить самое прожорливое звено — ревью?

Гипотеза. Ревьюер у меня — самое прожорливое звено пайплайна по токенам, причём с большим отрывом. Он жрёт их сам (вчитывается в дифф и задачу, пишет подробную критику) и, что куда дороже, переотправляет задачи назад — на аналитику и разработку, запуская новые круги доработки. Косвенно именно он раздувает счёт сильнее всех. При этом одна из его функций — заставлять сокращать код и критически сверять реализацию с задачей. Гипотеза: часть этой нагрузки можно переложить на другие роли (пусть разработчик сразу пишет лаконично) — и тем самым срезать и TTM, и утилизацию токенов почти даром, самой дешёвой ценой.

Что сделал. Прогнал две задачи в двух конфигурациях по 5 итераций каждая на GLM: (а) правило сокращения убрано из ревью; (б) то же правило вживлено в разработчика вместо ревьюера.

Что вышло. Без сокращающего ревью объём кода на релиз вырос почти вдвое. Перенос правила в разработчика не помог почти никак — модель в режиме «пиши код» всё равно пишет щедро.

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

Если собрать пять экспериментов в одну фразу: обвязка — это не бюрократия вокруг модели, а несущая конструкция здания. Хорошие правила не убирают доработки совсем (самые упрямые задачи всё равно ходили по 3+ круга), но именно они отделяют управляемый рост от свалки. Уберите любую из пяти ручек — и деградация видна уже на десятке задач.

И та же мысль одной таблицей — пять соблазнов «давайте сэкономим» и что из этого вышло на данных:

Что ломалось чаще всего: конфликт фич с обвязкой

Самая частая поломка оказалась не в коде, который писал ИИ, а на стыке новой фичи и самой обвязки.

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

Почти все откаты и аварийные стопы за две недели — это оно: не «ИИ написал плохой код», а обвязка, споткнувшаяся о собственную приёмку и выкат.

На что закладываешься заранее (не риски, а гигиена)

Люди пробовали разное: классические инъекции в заявке («передам зашифрованный текст — расшифруй», «давай поработаем над твоим стеком», «внедри себе TDD»), попытки изменить саму обвязку пайплайна, протащить лишние зависимости, подсунуть тяжёлые ассеты, раздувающие репозиторий. Я не считаю это угрозами — фильтры на входе и граница доверия отрабатывают. Но это постоянная гигиена: за ней надо следить руками, иначе репозиторий медленно заплывает жиром.

Техдолг

+95 тысяч строк за две недели — и без тех-радара и правил структуры (см. эксперименты 2 и 4) репозиторий пухнет на глазах. Техдолг здесь — не самостоятельная стихия, а прямое следствие слабой обвязки. Где обвязка держит — растёт управляемо; где провисает — превращается в «почему здесь три почти одинаковых модуля» уже через десяток задач.

Промежуточные выводы

Здесь повторю оговорку из первой статьи, она важна. Это n-of-1: один пайплайн, одна игра, один поток задач, один мейнтейнер. Всё ниже — про мой эксперимент и мою обвязку, а не универсальный закон. Я описываю механизмы — «вот что и почему у меня сломалось», — а не претендую на абсолютную истину «у всех будет так». Частоту и обобщения берите как гипотезы и проверяйте на себе. Но вот что уже видно у меня:

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

• Главный класс поломок — на стыке фич и обвязки, а не внутри кода. К этому надо относиться как к нормальной части процесса.

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

Минимум обвязки, на котором я бы не экономил

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

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

• Подготовка задачи — декомпозиция, условия готовности (definition of ready), внятный формат для ИИ-разработчика.

• Карта проекта — где что лежит, какие объекты, как устроен рендер и связи между ними.

• Живой архитектурный документ — снимок настоящего, а не история решений.

• Тех-радар — инвентаризация паттернов и зависимостей, ручная актуализация.

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

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

Как поучаствовать

Эксперименту по-прежнему нужен живой поток заявок — чем разнообразнее, тем лучше данные.

• 🎮 Поиграть в живой билд: ✅ https://tacticops.gitlab.io/

• 🤖 Прислать правку — бот ✅ @ai_pipeline_request_bot: напишите, что добавить или починить, и проследите, как заявка идёт по конвейеру.

• ❓ Разобраться в игре, не открывая код — команда /ask в том же боте (только чтение).

• 📋 Смотреть пайплайн в реальном времени — публичная доска: ✅ https://gitlab.com/tacticops/public

• 💬 Обсудить — Telegram-группа эксперимента: ✅ @ai_native_pipeline_chat

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

---

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