Автономный ИИ пишет код в прод без ручного ревью: эксперимент на живой игре

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

Площадкой для эксперимента служит top-down тактическая игра в духе Door Kickers: небольшой отряд штурмует здание. Игра открыта для всех по ссылке, любой желающий может через бот попросить добавить оружие, изменить поведение противников, починить баг или нарисовать новую карту. Запрос подхватывает пайплайн из десяти стадий — модерация заявки, уточнение у автора, финальная формулировка задачи, аналитика, написание кода по TDD, ревью, прогон CI и деплой. Задачи выполняются строго по одной, что исключает конфликты слияния и позволяет честно атрибутировать каждое изменение.

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

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

Эксперимент рассчитан на 60 дней и с самого старта фиксирует baseline по нескольким осям. Первая — куда смещается нагрузка на человека: на каких стадиях пайплайна мейнтейнер нужен в начале и на каких через месяц. Вторая — здоровье кодовой базы: churn, дублирование, цикломатическая сложность, покрытие тестами, количество дефектов и инцидентов. Третья — пропускная способность: задач в день, success rate, стоимость одной задачи, на каких стадиях пайплайн чаще спотыкается. Каждое изменение модели или промпта версионируется в журнале решений с обоснованием и временной меткой.

Автор намеренно ограничивает претензии на выводы: это n-of-1 кейс-стади, один пайплайн и один поток задач. Универсальных законов вида «ИИ-разработка деградирует через N задач» из одного прогона не вывести. Обещанный итог — каталог проблемных мест ИИ-native SDLC: где и как этот способ разработки ломается, с привязкой к залогированным метрикам, а не к впечатлениям. Код игры закрыт ради чистоты эксперимента — чтобы поток шёл через естественный язык, а не через готовые диффы. Но у бота есть команда /ask: ИИ-ассистент в режиме только чтения объясняет устройство любого куска логики.

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