Почему код от ИИ-агентов медленнее доходит до main

Несколько крупных исследований, опубликованных осенью 2026 года, подтверждают парадокс: AI-инструменты и агенты ускоряют написание кода, но изменения доезжают до main не быстрее, а иногда и медленнее, чем год назад. Разработчик с агентом за вечер собирает фичу, на которую раньше ушла бы неделя, но затем MR на полторы тысячи строк лежит три дня из-за перегруженности ревьюеров, а после approve задача застревает в QA. В итоге выигрыш в скорости генерации кода не превращается в ускорение поставки.

Faros AI в исследовании «The AI Productivity Paradox» (июль 2025 года) на данных более 10 тысяч разработчиков из 1255 команд показал: активные пользователи AI-ассистентов закрывали на 21% больше задач и вливали на 98% больше pull request. Однако время ревью выросло на 91%, средний размер PR — на 154%, число багов на разработчика — на 9%. При этом на уровне компании значимой связи с результатом исследователи не нашли.

Свежий материал Faros «The Speed Trap» (18 сентября 2026 года) по телеметрии за 12 месяцев от 22 тысяч разработчиков из 4 тысяч команд фиксирует дальнейшее смещение узкого места. Время в QA выросло на 300,6% — самое сильное ухудшение среди метрик потока. Средний размер PR всё ещё на 71,8% выше базового уровня, число инцидентов в месяц выросло на 125,4%. Доля PR, влитых без ревью, за полгода выросла с 31,3% до 76,3%.

CircleCI в отчёте о поставке ПО за 2026 год проанализировал 28,7 миллиона прогонов CI за сентябрь 2025 года. Среднее число ежедневных прогонов выросло на 59% год к году, но у медианной команды активность в feature-ветках выросла на 15%, а в main снизилась на 7%. Доля успешных сборок main опустилась до 70,8% — минимума за пять лет, а медианное время восстановления до зелёной сборки составило 72 минуты. Меньше 5% команд смогли одновременно нарастить и разработку, и прохождение изменений через main.

DORA в отчёте 2024 года нашла, что рост использования AI на 25% сопровождался снижением скорости поставки на 1,5% и стабильности на 7,2%. В 2025 году связь AI со скоростью поставки и результатами продукта стала положительной, а со стабильностью осталась отрицательной. Авторы называют AI «зеркалом и мультипликатором»: он ускоряет разработку, но без сильной автоматизации тестов и быстрой обратной связи рост объёма изменений превращается в нестабильность.

Причина парадокса — в теории очередей: AI увеличивает скорость поступления изменений, но пропускная способность ревью, QA и интеграции не растёт автоматически. Узкое место переезжает дальше по конвейеру — у одной команды это ревью кода, у другой — QA, у третьей — интеграция и выкладка. Рост размера PR усугубляет ситуацию: агент не оптимизирует границы изменения, если это не задано явно. В результате approve может превращаться в способ убрать зависшее изменение из очереди, а не в результат проверки.

Эксперты предлагают задавать границу изменения до начала работы агента: один MR — одна логически связная задача, которую можно независимо понять, проверить и откатить. При этом число строк — лишь индикатор стоимости ревью, а не мера риска: MR на 600 строк из DTO и тестов может быть безопаснее, чем MR на 120 строк, трогающий авторизацию платежа. Как отмечается в открытом документе Google, оптимизировать нужно скорость, с которой команда вместе выпускает продукт, а не скорость отдельного разработчика.