Faros AI: AI-агенты дали +98% pull request, но ревью стало дольше на 91%

Команды с AI-агентами пишут код быстрее, но до main он добирается не быстрее, а местами и медленнее. Habr разобрал этот парадокс на данных Faros AI, CircleCI и DORA. Самая цитируемая цифра из отчёта Faros AI, построенного на телеметрии более 10 тысяч разработчиков: у тех, кто активно пользуется AI, на 21% больше закрытых задач и на 98% больше слитых pull request. Время ревью при этом выросло на 91%.

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

Где застревает код

Проблема не в количестве PR, а в их размере. По данным Faros AI, средний pull request у команд с высоким уровнем AI-adoption вырос примерно на 154%. Агент охотно делает большой рефакторинг, добавляет тесты, трогает соседние модули. Ревьюеру приходится держать в голове больше контекста, а вдумчивый просмотр диффа на 800 строк занимает совсем не столько же времени, сколько на 300.

Вторая точка потерь находится в QA. Faros AI зафиксировал рост числа багов на разработчика примерно на 9%. Каждый дополнительный дефект возвращает задачу в цикл: комментарии, правки, повторный прогон CI, повторное ревью. Метрика «задач закрыто» растёт, а lead time до production стоит на месте или увеличивается.

Данные DORA рисуют ту же картину с другого ракурса. В отчёте 2024 года рост AI-adoption на 25% коррелировал со снижением пропускной способности поставки на 1,5% и падением стабильности на 7,2%. Позже DORA описывала AI как усилитель: хорошие процессы он ускоряет, слабые обнажает. CircleCI смотрит на проблему через CI-пайплайны. Там видно, где копятся неуспешные сборки и долгие прогоны, то есть где скорость написания упирается в скорость проверки.

Метрики, которые стоит смотреть

Чтобы найти узкое место, одной статистики по коммитам мало. Нужна сквозная картина от первого коммита до деплоя:

• Время до первого ревью: сколько PR ждёт, пока на него вообще посмотрят.
• Время ревью целиком: от открытия до approve.
• Размер PR в строках и файлах, а также медиана и 90-й перцентиль.
• Доля PR, вернувшихся на доработку после ревью или QA.
• Change failure rate и время восстановления после инцидента.
• Lead time for changes: от коммита до production.

Если первые два показателя растут вместе с количеством PR, проблема в ревью. Если растёт доля возвратов и change failure rate, упирается качество самого сгенерированного кода и тестов.

Что делать командам

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

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

Третье: пересмотреть метрики продуктивности. Количество PR и закрытых задач на человека в эпоху агентов почти ничего не говорит. Показательнее lead time и стабильность релизов, то есть те метрики, которые DORA использует много лет.

Четвёртое: усилить автоматические проверки до ревью. Чем надёжнее CI и покрытие тестами, тем меньше работы остаётся людям. Практическая проверка для любого тимлида: возьмите последние 100 слитых PR и посмотрите, сколько времени каждый провёл в ожидании ревью, а не в разработке. Скорее всего, именно там лежит выигрыш, который вам обещали агенты.