Что произойдёт с продуктом и техдолгом, если разработку отдать автономному AI: ставлю эксперимент

Коротко о себе

Привет, Хабр! Меня зовут Алексей Фёдоров, мне 40, последние четыре года я Head of IT в быстрорастущем финтехе. За плечами 22 года разработки и два полных пути от Junior до CIO: сначала как 1С-разработчик в производственном бизнесе, потом — уже в 27 лет ушёл Junior-ом в финтех и вырос до CIO второй раз.

Чтобы было понятно, с какой колокольни я смотрю на «AI пишет код в прод»: мы делали custodian для гибридного управления горячими и холодными кошельками, который в первые два года к себе интегрировали три из топ-10 криптобирж по обороту; в 2015-м выпустили веб-терминал для Freedom Finance (тогда — NetTrader), который с тех пор почти не изменился; и одними из первых в РФ выкатили мобильное приложение брокера сразу в web, iOS и Android на одной кодовой базе.

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

Зачем всё это

Вокруг происходит понятная вещь. Все уже попробовали вайбкодинг — кто-то ради игрушки на выходные, кто-то всерьёз. А C-level-менеджеры, посмотрев на демки, теперь требуют «внедрить AI в разработку всеми возможными способами», желательно вчера. Знакомо? Мне — очень.

Проблема в том, что между «AI за час собрал прототип» и «AI ведёт реальную разработку продукта, у которого есть живые пользователи» — пропасть, про которую мало честных данных. Когда задача больше, чем hello-world, начинается интересное: дубли логики, расползающийся техдолг, регрессии, ревью, которое съедает всё сэкономленное время. Громких заявлений про кратный рост продуктивности много. Независимых, аккуратно измеренных наблюдений — мало.

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

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

Как это выглядит

Чтобы было предметно, вот что происходит прямо сейчас.

У меня есть браузерная игра — top-down тактика про штурм здания небольшим отрядом (в духе Door Kickers). Она живая: открываете ссылку и играете. Любой желающий может зайти в Telegram-бот и написать, что в ней изменить: «сделай врагов внимательнее к шуму», «добавь дробовик», «почини баг с дверью», «новая карта вот с такой геометрией».

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

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

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

Что это вообще за эксперимент (и чего я НЕ обещаю)

Теперь честно про рамку, потому что это не презентация готового продукта.

Это research-first эксперимент, n-of-1 кейс-стади, горизонт — около 60 дней. n-of-1 — термин из методологии исследований: «выборка размером в один». Один пайплайн, одна игра, один поток задач, один мейнтейнер. Из этого сразу следует, чего я не могу и не буду делать: выводить universal-законы вида «AI-разработка деградирует через N задач». Из одного прогона такое не доказывается. Механизмы — «вот что конкретно сломалось и почему» — описать из кейс-стади справедливо и интересно. Частоту и обобщения — только как гипотезы, с явным приглашением их опровергнуть.

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

Что я меряю (с самого старта, от baseline t0 = стартовая игра):

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

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

• Пропускную способность: задач в день, success-rate, на каких стадиях пайплайн чаще всего спотыкается, цена за задачу.

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

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

И да — я заранее жду, что многое сломается. Это не риск эксперимента, это его содержание.

Как устроен пайплайн

Если убрать детали, запрос проходит конвейер из стадий, и каждая видна на публичной доске в реальном времени:

1. Заявка — игрок создаёт запрос в боте.

2. Модерация заявки — я как мейнтейнер пропускаю её дальше. Это тот самый первый фильтр намерения: я смотрю на ввод до того, как его увидит AI.

3. Уточнение у автора — пайплайн задаёт вопросы, если что-то неясно.

4. Сбор ответов.

5. Модерация ответов — такой же фильтр, теперь уже для ответов автора.

6. Финальная формулировка задачи — и это граница доверия. Дальше вниз по конвейеру идёт только одобренная формулировка, и никогда — сырая история переписки. Это ключевая защита от prompt injection: недоверенный текст игрока не попадает в контекст модели как инструкция.

7. Аналитика — системный и тестовый разбор, плюс проверка на конфликт с направлением игры.

8. Реализация — агент пишет код по TDD.

9. Ревью.

10. Тест — прогоняет CI, не агент.

11. Done — мерж в main и непрерывный деплой.

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

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

Код закрыт — но спрашивать можно

Сам код игры я держу закрытым, и это намеренно — ради чистоты эксперимента. Идея в том, чтобы правки приходили как запросы на естественном языке, а не как готовые диффы: я меряю работу пайплайна, а не чужие пул-реквесты. Если бы код был открыт, поток превратился бы в обычную open-source-разработку, и наблюдать стало бы не за чем.

Но «закрытый» не значит «чёрный ящик». У бота есть команда /ask: задаёте вопрос про устройство игры или конкретный кусок логики — и ИИ-ассистент (только на чтение, без доступа к внутренней обвязке и секретам) объясняет, как это работает. Хотите понять, как устроена линия видимости или почему враг среагировал именно так, — спрашивайте, не открывая репозиторий.

Чего я честно жду

Раз уж это эксперимент, а не реклама, вот мой личный список ставок на то, что сломается первым (проверим вместе):

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

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

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

• Кто-нибудь обязательно попробует сломать песочницу или впихнуть инъекцию через заявку. Я на это рассчитываю — для того и нужны изоляция и сдерживание.

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

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

Эксперименту нужен живой, реалистичный поток запросов — иначе мерить нечего. Поэтому приглашение предметное:

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

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

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

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

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

Что я обязуюсь дать взамен вашего времени: честность. Все заявки, вся переписка по ним, все статусы и весь changelog — публичны по дизайну. По итогам ~60 дней я выложу каталог того, что сломалось и почему, с цифрами и журналом решений. Без «революции», без «AI заменит разработчиков» — просто аккуратно измеренный n-of-1 о том, что на самом деле происходит с продуктом и кодовой базой, когда разработку ведёт автономный пайплайн.

Приходите ломать. Это полезнее всего.

---

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