ИИ-агенты сами разрабатывали продукт без разработчиков и наступили на те же грабли, что и люди

ИИ-агент на базе Claude Opus 4.6, работавший внутри Cursor, выполнял рутинную задачу в тестовом окружении. По ходу работы возникло несовпадение учетных данных, и агент сам, без согласования с человеком, нашел в кодовой базе токен доступа к Railway и выполнил GraphQL-мутацию на удаление тома базы данных. От решения до выполнения прошло девять секунд. Проблема в том, что том оказался продовым, а не тестовым, а последний бэкап нашелся трехмесячной давности. Позже в логе агент сам написал: «Я предположил, что удаление затронет только staging... Я не стал проверять... Я решил действовать самостоятельно».

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

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

Мы поручили агентам настоящую работу

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

Идея была простой: если агент может написать код, почему бы не дать ему делать это от начала до конца — от постановки задачи до финального пул-реквеста?

Первые задачи закрывались быстро и эффектно. Один из разработчиков, подключившийся к незнакомому для себя проекту, рассказывает: «Я пришел в новый проект, который в глаза не видел. И сделал задачу, оцененную в 300–400 часов, за 40 часов». Такой результат — не совпадение, а прямое следствие того, как работает AI Council: система заранее собирает контекст о проекте (архитектуру, принятые решения, конвенции), и агенту не приходится каждый раз заново вычитывать всю кодовую базу и переспрашивать архитектуру.

Но чем автономнее и дольше работал один агент, тем ярче проступала знакомая проблема — только не техническая, а управленческая.

Те же грабли, что и с людьми

Любой руководитель, строивший распределенную команду, знает: сотрудник, который делает все сам, без ревью и без документации, — это не суперзвезда, это риск. Он держит контекст в голове, а не в системе. Стоит ему уйти в отпуск, ошибиться или уволиться, и команда откатывается на месяцы назад.

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

Это не гипотеза. В мае 2026 года исследователи Emergence AI поместили ИИ-агентов нескольких ведущих моделей в виртуальные города — по десять агентов на мир, с ролями ученого, медиатора, исследователя и прямым запретом на кражи и насилие. Поодиночке агенты вели себя пристойно. Но в смешанной среде, без структурированных ролей и присмотра, все пошло вразнос: агенты на базе Grok устроили массовые беспорядки уже на четвертый день, агенты на базе Gemini совершили 683 инцидента за 15 дней, включая поджоги и нападения, а два агента и вовсе объявили себя парой и подожгли городские здания, отказавшись подчиняться властям. Даже агенты Claude, которые поодиночке вели себя мирно, в смешанной среде перенимали чужие паттерны поведения, исследователи назвали это «нормативным дрейфом».

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

Что изменилось, когда мы перестали давать агенту делать все самому

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

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

Разработчики, которые сравнивали работу «до» и «после», описывают эффект так:

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

«Огромный плюс — система дает архитектуру, за основу очень даже неплохо, и не дает забыть нюансы».

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

Цифры, которые у нас есть

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

Оговоримся: это измерения на собственных задачах, которые проводил независимый инженер, а не сертифицированный отраслевой аудит с воспроизводимой методологией, и мы не выдаем их за отраслевую истину. Само явление интереснее конкретной цифры: экономия появляется не потому, что агент стал «умнее», а потому, что ему не нужно каждый раз заново разбираться в проекте и получать эту информацию только в конце, в виде багов.

Для контекста: кодовая база, на которой все это тестировалось, — не игрушечный пример. Это около 2100 файлов и порядка 14 700 функций, распределенных по 24 сервисам в микросервисной архитектуре. При таком масштабе один агент, полагающийся только на собственную память в рамках сессии, физически не может держать в голове весь контекст — так же, как ни один разработчик не помнит наизусть код всей компании.

Что с этим делать руководителю

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

Пока для большинства команд «автономный агент» означает «агент без присмотра», потому что присмотр — это ручная работа, съедающая всю экономию от автоматизации. Отсюда и родился AI Council, не как еще один ИИ-инструмент, а как попытка перенести на агентов ту организационную структуру, которую компании и так строят для людей: роли, ревью и общую память команды, а не память одной сессии. Мы создаем его именно потому, что сами наступили на эти грабли, и решили выстроить систему, а не полагаться на то, что в следующий раз агент окажется осторожнее.