Коротко о себе
Привет, Хабр! Меня зовут Алексей Фёдоров, мне 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: где именно и как этот способ разработки ломается, заякоренный на залогированные метрики и журнал, а не на впечатления.
И да — я заранее жду, что многое сломается. Это не риск эксперимента, это его содержание.
Как устроен пайплайн
Если убрать детали, запрос проходит конвейер из стадий, и каждая видна на публичной доске в реальном времени:
Заявка — игрок создаёт запрос в боте.
Модерация заявки — я как мейнтейнер пропускаю её дальше. Это тот самый первый фильтр намерения: я смотрю на ввод до того, как его увидит AI.
Уточнение у автора — пайплайн задаёт вопросы, если что-то неясно.
Сбор ответов.
Модерация ответов — такой же фильтр, теперь уже для ответов автора.
Финальная формулировка задачи — и это граница доверия. Дальше вниз по конвейеру идёт только одобренная формулировка, и никогда — сырая история переписки. Это ключевая защита от prompt injection: недоверенный текст игрока не попадает в контекст модели как инструкция.
Аналитика — системный и тестовый разбор, плюс проверка на конфликт с направлением игры.
Реализация — агент пишет код по TDD.
Ревью.
Тест — прогоняет CI, не агент.
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», а измеримый стенд, на котором видно, где автономная разработка ломается. Если по ходу выяснится, что ломается она везде и сразу — это тоже результат, и я про него честно напишу.