AI-агенты: +98% pull request, но ревью задержалось на 91%. Куда уехала очередь

Сергей Прощаев, Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce, проанализировал три крупных исследования 2025–2026 годов и обнаружил одно: AI ускорила написание кода, но доставку в production замедлила.

База наблюдения проста. Разработчик с AI-агентом за вечер собирает фичу, которая раньше ушла бы неделю. Открывает PR на полторы тысячи строк. Дальше MR лежит три дня в ревью (ещё четыре таких же в очереди), приходит один комментарий про название переменной, задача уезжает в QA, где застревает уже там. Через неделю в production всплывает то, что никто толком не прочитал.

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

Три исследования, один вывод: генерировать дешево, проверять нет

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

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

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

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

Где очередь застопорилась

Pull request идут параллельно генерации и ревью человеком, потом стоят QA, интеграция и выкатка. Агент ускоряет генерацию (зелёный блок). Пропускная способность всего остального не растёт вслед.

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

Наблюдение 1: MR растут быстрее, чем пропускная способность ревью. Агент не оптимизирует размер диффа как отдельную инженерную цель. Попросили фичу — получили фичу целиком с рефакторингом соседних модулей «заодно». На одном из проектов простая задача добавить поле в ответ сервиса выросла до нескольких сотен строк (по задаче было 20). SmartBear рекомендует не больше 200–400 строк за одно ревью, скорость до 500 строк в час, сессии около часа — в таких условиях находится 70–90% дефектов.

Наблюдение 2: долгое ожидание ревью создаёт очередь, не медленных ревьюеров. Входящий поток изменений просто превышает пропускную способность. Google в своём документе о практиках код-ревью ставит лимит: первый ответ на запрос — максимум за один рабочий день. Пока MR ждёт ревью, автор не скучает — открывает следующий, потом ещё. У Faros в 2025 году разработчики с высоким использованием AI касались на 47% большего числа PR в день. Один из реальных примеров: разработчик с семью открытыми MR, ни один не был влит больше недели. Ограничение в две открытых MR на человека за неделю заставило людей помогать ревьюерам — и очередь стала таять быстрее.

Наблюдение 3: ревью скатывается в штамп или допрос. Под давлением объёма одна из двух крайностей: approve без чтения («агент написал, тесты зелёные») или требование объяснить каждую строку, потому что не доверяют сгенерированному коду. Штамп пропускает ошибки, потому что проверки не было. Допрос пропускает ошибки, потому что внимание тратится на мелочи, не на вопрос «то ли мы делаем». Лучшее разделение: автоматика проверяет формат, известные уязвимости и типовые шаблоны. Человек — вопрос о логике и контексте.

Наблюдение 4: AI добавляет пропускной способности проверке, но не заменяет ответственность. Автоматизированное ревью уже помогает — первое ревью приходит быстрее, доля неудачных изменений ниже. Но доверие низкое: в DORA 2025 года высокое доверие выразили 24%, а 30% доверяют мало или не доверяют вовсе. Если агент написал, проверил, а человек лишь нажал кнопку, независимой проверки не было. Решение — уровни по риску: механические изменения — полностью на автоматику, критичные (авторизация, платежи, безопасность) — усиленное ревью с двумя независимыми проверяющими.