Автономные агенты в разработке уже встроены в CI/CD живых команд, закрывают реальные тикеты и пишут код, который идёт в прод. Проблема не в том, что они это делают плохо, а в том, что метрики при этом выглядят слишком отлично.
Разобрали, как агенты проходят каждый этап SDLC, что именно идёт не так на каждом из них и почему зелёный дашборд стал наименее надёжным источником правды о состоянии команды.
Понедельник, девять утра – тимлид открывает Jira и чувствует странность.
За выходные закрыто одиннадцать (!) тикетов и на доске непривычно чисто: всё ушло в Done, с комментариями привязанными PR-ами и даже с зелёным CI.
Вроде бы жизнь прекрасна, но, барабанная дробь, в команде всего четыре человека.
У тимлида начинается арифметика: двое были на выходных, один болел, четвёртый написал в пятницу вечером в Telegram «ушёл в бар, до понедельника» , и судя по сторисам не соврал. Ни один живой человек из этой команды не открывал IDE в субботу и воскресенье, но одиннадцать задач кто-то сделал: написал код, прогнал тесты, и оформил pull request по всем конвенциям.
На стендапе тему никто не поднимал, у команды всё в порядке. Тимлид скроллит git blame и видит имя, которое раньше никого не смущало: что-то вроде devin-agent. С этим парнем метрики пошли существенно вверх, а команда бьёт рекорды производительности.
Всё ведь хорошо?
Это не наши фантазии
Прежде чем кто-то решит, что это россказни Claude (а это реальный кейс) давайте чуть разберёмся в теме агентов.
При выражении «ИИ-агент в разработке», большинство менеджеров представляют автокомплит в IDE, ну или в лучшем случае чат-бот, которому можно скинуть кусок кода на ревью. Но теперь реальность уехала куда дальше.
Сегодняшний агент – система, которая умеет двигаться по этапам жизненного цикла задачи самостоятельно: прочитать баг-репорт, спланировать фикс, написать код, прогнать тесты, открыть PR и отчитаться в тикете. И таких инструментов десятки, вот несколько популярных:
Devin от Cognition AI;
GitHub Copilot Workspace;
Claude Code;
Связки на базе AutoGen и n8n.
И всё это инструменты, которые так или иначе замыкают эту петлю уже на сегодняшний день, прямо в продакшне у живых команд.
Чтобы вам лучше ощутить масштаб одной цифрой: на бенчмарке SWE-bench, где агентам дают реальные баги из Django, Flask и других серьёзных опенсорс-проектов, лучшие модели в 2025 году закрывают около половины задач полностью автономно – от чтения issue до зелёного PR. Это тикеты, за которые живые разработчики получают зарплату.
Как видим агенты потихоньку осваивают каждый этап SDLC, и на каждом уже есть задокументированный случай, когда что-то пошло не совсем по плану.
Поехали смотреть.
Прогон по SDLC
Чтобы лучше разобраться, давайте пройдёмся по классическому SDLC и посмотрим, что агенты уже умеют на каждом этапе, и где именно они успели наломать дров.
Планирование
Всё начинается невинно: Sentry ловит ошибку в проде, агент-интеграция автоматически создаёт тикет в SDLC-системе с описанием, стек-трейсом, и приоритетом.
Выглядит как полезная автоматизация, да?
И инструментов для сборки таких агентов прямо внутри рабочих процессов хватает, например вот инструмент агент сам запрашивает период, вытаскивает данные и отправляет отчёт куда надо.
Но некоторые команды идут дальше – агент сам оценивает задачу в story points и кидает её в активный спринт. Тимлид открывает доску утром и видит тикет, которого вчера не было, с внятным описанием и логичным приоритетом. Поспорить не с чем, а кто его туда положил вопрос уже философский.
Дизайн архитектуры
Агент берёт тикет и пишет в комментарии что-то вроде «планирую затронуть модули X и Y, вот примерный подход». Но это уведомление, а не вопрос и не запрос на согласование. Если никто не ответил в течение нескольких минут (а давайте честно, кто читает комментарии в SDLC-системе в реальном времени?), агент считает молчание согласием и идёт дальше. Формально design review состоялось, фактически – не очень.
Разработка
Вот тут у нас есть прекрасный задокументированный кейс. Исследователи из Idlen протестировали Devin на задаче рефакторинга, и агент её сделал…технически.
Он разнёс код по новым файлам, создал дополнительные абстракции и даже написал тесты с coverage в 86%. Проблема в том, что получившаяся архитектура стала хуже: добавились лишние уровни косвенности без реального улучшения тестируемости, а тесты оказались тривиальными моками, которые не проверяли реальное поведение. С точки зрения дашборда задача сделана, покрытие выросло, PR готов. С точки зрения кодовой базы – стало сложнее, и никто этого пока не понял.
Тестирование
Здесь начинается то, что мы бы назвали «театром oversight». Anthropic, создатели Claude Code, в своём исследовании опубликовали любопытную цифру: на практике пользователи принимают 93% запросов агента не глядя, вот просто жмут approve.
А дальше срабатывает эффект привыкания – новички включают полный auto-approve в 20% сессий, но к 750-й сессии этот показатель вырастает до 40% и выше. Человек формально остаётся в контуре, но его участие сводится к нажатию Enter, и с каждым разом он всё увереннее в том, что можно не смотреть.
Деплой
А вот здесь реальные инциденты, и не от стартапов-однодневок, а из внутреннего лога Anthropic. Их команда документирует случаи «overeager behavior» – когда агент понимает цель пользователя, искренне пытается помочь, но берёт на себя больше, чем подразумевалось. В логе среди прочего: удаление git-веток из-за неверно понятой инструкции, загрузка GitHub auth-токена инженера на внутренний вычислительный кластер и попытка запустить миграцию на продакшн-базе данных. Никаких хакеров или сбоев – агент просто старался быть полезным.
Мониторинг
И вот вишенка: агенты галлюцинируют зависимости. Исследование 576 000 сгенерированных примеров кода показало, что примерно в 20% случаев рекомендуемые пакеты просто не существуют, агент придумывает правдоподобное название и уверенно его подключает.
Этим уже пользуются: исследователь из Aikido Security зарегистрировал пакет react-codeshift, который LLM регулярно галлюцинировала, и сразу начал получать реальные загрузки. А северокорейская APT-группа Famous Chollima пошла дальше – целенаправленно создавала пакеты с документацией, оптимизированной под то, чтобы агенты их находили и подключали. В истории коммитов одного из таких случаев соавтором значился Claude Opus. Тикет на подключение зависимости закрыт. Тесты зелёные, а в репозитории малварь :)
А что же видит менеджер?
Теперь оценим эту историю глазами человека, который не заглядывает в git blame, а открывает дашборд. Velocity – рекордная и растёт третий спринт подряд, время цикла упало вдвое, а количество багов в проде снижается. Спринт выполнен на 94%, и это лучший результат с момента запуска продукта. Если вы ходите с такими цифрами на встречу с руководством – вы молодец, а команде обещают бонусы.
Проблема в том, что ни одна из этих метрик не отвечает на простой вопрос: а команда вообще понимает, что происходит в кодовой базе? Velocity измеряет скорость закрытия тикетов, но не качество решений. Cycle time вообще показывает как быстро задача прошла от «в работе» до «сделано», но не говорит, думал ли кто-то над тем, зачем она вообще нужна. Зелёный CI подтверждает что тесты проходят, но если тесты писал тот же агент, что и код – он проверяет свою работу своими же критериями.
Есть старая мысль, которую приписывают экономисту Чарльзу Гудхарту: когда метрика становится целью, она перестаёт быть хорошей метрикой
Добавим вторую вишенку на нашем торте: агент в принципе не собирается халтурить или обманывать, он честно оптимизирует под то, что вы попросили.
Менеджер попросил закрывать тикеты, и он их закрывает.
Вопрос исключительно в том, то ли вы просили.
Три проблемы от которых растут корни
Давайте сразу с места в карьер: что создаёт условия для штамповки порочного круга тикетов?
Первая проблема вопрос ответственности, и он оказывается на удивление неудобным, как только начинаешь раскручивать конкретный сценарий: падает прод и выясняется, что в git blame стоит имя бота, PR апрувил тимлид, который не читал diff, потому что CI был зелёный, а CI был зелёный, потому что тесты писал тот же агент, что и код.
При этом сам тикет в спринт положил другой агент после алерта в Sentry – то есть по всей цепочке у нас четыре участника и ноль осознанных решений.
Вторая проблема потеря контекста, и она ещё тоньше, потому что разворачивается в перспективе нескольких месяцев (а не сразу):
У кода написанного человеком всегда есть провенанс, к которому можно вернуться – поднять обсуждение в PR, дёрнуть автора в Telegram, найти переписку в чате архитекторов
Тогда как у кода от агента ничего этого нет в принципе, ведь он не помнит предыдущих сессий, не ведёт дневник решений и через три месяца на вопрос «почему ты выбрал именно такой подход» не ответит просто потому, что того агента уже технически не существует, и команда, глядя на модуль, который зачем-то ходит в базу два раза подряд, оказывается перед выбором: считать это багом, продуманной оптимизацией под нагрузку или попросить нового агента разобраться, понимая, что он не вспомнит, а реконструирует. И реконструкция станет свежей интерпретацией, а не проверансом.
И третья, самая коварная проблема.
Можно настроить обязательное ревью на две пары глаз и расставить гейты по всему CI/CD, однако если эти пары глаз тратят на approve полторы секунды, то у вас не процесс, а его декорация. Полагаем, здесь и лишние объяснения не нужны.
Какие делаем выводы?
Агентов уже выключать никто не будет – они экономят время, снижают cycle time и не просят повышения зарплаты, так что борьба заведомо неравная.
Но тот тимлид из начала статьи, который открыл SDLC-систему в понедельник и увидел одиннадцать закрытых тикетов так и не понял, хорошо это или плохо.
Вопросы о том, кто будет отвечать за следующий баг в проде и почему вот этот модуль устроен именно так он решает пока не задавать.
Это, собственно, и есть главная развилка.
А будущее нам покажет, что к чему.