Скорость, которая душит
В 2024 году CTO мечтали: AI-агенты возьмут на себя рутину, команды сосредоточатся на архитектуре, а релизы посыплются как из рога изобилия. 2026 год разбил розовые очки. Да, Agent-Driven SDLC — реальность: Cursor AI, Claude Code, GitHub Copilot (уже с GPT-5 под капотом) пишут код быстрее любого джуниора. Но вот парадокс: среднее время прохождения PR выросло с 2 часов до 14. Сеньоры захлебнулись ревью, а техдолг растет быстрее, чем команда успевает его гасить.
Я поговорил с десятком технических директоров из российских IT-компаний (от финтеха до e-commerce). Вывод один: AI-агенты не ускорили SDLC — они просто перенесли бутылочное горлышко с написания кода на его проверку. И это не просто баг, это фича новой парадигмы, к которой мы оказались не готовы.
Почему сеньор-апрув стал главным тормозом?
Исследование State of AI4SDLC 2026 (1200 команд из РФ и СНГ) зафиксировало: 68% респондентов признали, что время на code review выросло на 40% с момента внедрения AI-агентов. Доля кода, требующая переписывания, взлетела с 15% до 38%. Сеньоры тратят до 6 часов в день на проверку AI-сгенерированных PR, вместо того чтобы заниматься архитектурой и менторством.
| Метрика | До AI-агентов | После (июнь 2026) |
|---|---|---|
| Среднее время PR в очереди | 2 часа | 14 часов |
| Доля кода, требующая доработки | 15% | 38% |
| Загрузка senior-инженеров | 60% | 95% |
Цифры — из отчета за май 2026 года. И они совпадают с тем, что я слышу от CTO. Один из них рассказал: «Мы внедрили Cursor AI всей команде. Через месяц джуны перестали писать вручную, но сеньоры взвыли. Агент генерирует код, который выглядит правильно, но ломается на edge-кейсах. Приходится перепроверять каждую строчку. В итоге мы просто ограничили лимит генерации на разработчика — 20 PR в неделю».
Звучит как анекдот, но это новая реальность. Мы перешли от нехватки разработчиков к нехватке ревьюеров. И это не просто проблема процесса — это меняет роли в команде. Подробнее о том, как AI-агенты убивают привычные роли, мы уже разбирали в отдельной статье.
Кейс AWS: когда «автономный SDLC» пошел не по плану
Amazon Web Services в марте 2026 запустила методологию AI-DLC — полностью агентный цикл разработки. Идея: агенты пишут код, тестируют, деплоят. Человек только утверждает релиз. Первые недели все пели дифирамбы: скорость выросла втрое. Но через месяц случился инцидент: агент для модуля авторизации неправильно обработал edge-кейс из-за того, что не видел полный контекст legacy-кода. Пользователи потеряли доступ к данным на два часа.
Разбор показал: AI-агент для code review пропустил ошибку, которую человек заметил бы сразу. Почему? Потому что агент не имел доступа ко всем граничным условиям — он «смотрел» только в текущий PR, а не в историю изменений. Мы уже писали об этом кейсе, но повторю главный вывод: бесконтрольное делегирование без четких границ приводит к потере прозрачности и падению качества.
Не делайте так: внедрите AI-агента на всю команду, отключите лимиты и ждите чуда. Чуда не будет. Будет техдолг и инцидент.
Agent Engineering — новая дисциплина, которая спасет (или нет)
Проблема не в AI-агентах как таковых, а в том, что мы пытаемся вписать их в классический SDLC. Традиционный софт детерминирован: X на входе — Y на выходе. Агенты недетерминированы: «примерно X» может дать «то ли Y, то ли Z, то ли ошибку». Как превратить эту хрупкую конструкцию в надежную систему? Ответ — Agent Engineering.
В статье про Agent Engineering мы разобрали, почему 95% работы — это не прототип, а продакшен. Здесь то же самое: AI-агент, который отлично справляется с изолированной задачей, ломается при интеграции с реальной системой. CTO, с которыми я говорил, сходятся: нужны четкие границы для агентов, обязательный трассируемый лог каждого действия, автоматические тесты на output агента и обязательный human-in-the-loop на критических этапах.
«Мы потратили три месяца на доработку инфраструктуры для агентов: мониторинг, логирование, фоллбеки. Это не про код — это про надежность. Код агента — лишь 10% работы» — CTO одного из топ-20 банков РФ (пожелал остаться анонимным).
Инструменты не спасут, если нет процесса
Есть мнение: возьмите Cursor AI или Claude Code — и все починится. Но сравнение инструментов в IDE показало: даже лучшие агенты (Cursor AI с последней моделью, Claude Code с большим контекстом) требуют грамотного промпт-инжиниринга и четкой спецификации. Без Specification-Driven Development агент сгенерирует то, что вы сказали, а не то, что вы имели в виду.
Один CTO рассказал: «Мы запретили агентам писать код без тест-кейсов. Теперь сначала пишется тест, потом агент его проходит. Скорость упала на 20%, зато переделывать приходится в разы реже». Это и есть новый SDLC: не «быстрее, любой ценой», а «быстрее, но с контролем».
Главный риск — технический долг от AI
AI-агенты не чувствуют контекст кодовой базы. Они видят файл, а не архитектуру. Результат — код, который нарушает принципы SOLID, дублирует логику, игнорирует существующие абстракции. Если не контролировать, через полгода команда получит монстра, которого сложнее рефакторить, чем писать с нуля.
Мы уже писали, как не утонуть в техдолге. Главный рецепт: настройте линтеры под AI-код, добавьте обязательное ревью для любого сгенерированного PR и не давайте агентам менять критическую инфраструктуру без утверждения архитектором.
Что делать? Неочевидный совет
AI-агенты — не серебряная пуля. Они не исправят плохую архитектуру, не напишут документацию за вас (хотя могут помочь) и не заменят опытного инженера. Единственный способ выиграть в этой гонке — сместить фокус с скорости генерации на скорость верификации.
Вот совет, который я услышал от CTO и который звучит контринтуитивно: сначала наведите порядок в тестах и спецификациях, а потом внедряйте агентов. Если у вас нет покрытия модульными тестами, нет четких acceptance criteria — агенты только ускорят создание хаоса. Агент не умеет отличать хороший код от плохого, он умеет следовать инструкции. Дайте ему плохую инструкцию — получите плохой код быстрее.
Возможно, будущее за гибридным подходом: AI-агенты как ассистенты, а не автономные исполнители. Человек ставит задачу, контролирует результат и отвечает за качество. И это не шаг назад — это признак зрелости. Те, кто это понял уже сейчас, через год будут иметь устойчивые пайплайны, а не горящие продакшены.
