Агенты кодинга пишут больше кода, но ревью людей съедает весь выигрыш

Исследование, о котором пишет Ars Technica, фиксирует неудобный для рынка факт: ИИ-агенты для программирования действительно ускоряют написание кода, но готового софта от этого не становится больше. Время, сэкономленное на генерации, уходит на проверку человеком. Ревью превратилось в узкое место всего процесса. В доступной аннотации нет ни методологии, ни точных цифр, поэтому ниже приведён сам вывод и контекст из более ранних замеров, которые указывают в ту же сторону.

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

Производственная цепочка в разработке состоит из постановки задачи, написания кода, ревью, тестов и выкатки. Агент ускоряет только второе звено. Остальные остаются прежними, а у ревью к тому же растёт нагрузка: pull request становятся больше и многочисленнее, а читать их по-прежнему должен человек, который отвечает за результат.

Код от агента обычно выглядит убедительно: он аккуратно оформлен и проходит базовые проверки. Именно поэтому его нельзя просматривать по диагонали. Ревьюеру приходится восстанавливать намерение, проверять граничные случаи и искать места, где модель уверенно ошиблась. Это классическая теория ограничений: если ускорить не самое узкое звено, пропускная способность системы не изменится. Вырастет только очередь перед этим звеном.

Что показывали прежние замеры

У этой картины есть предыстория. Вот данные, которые публиковались раньше и на которые обычно ссылаются в таких спорах:

• METR, 2025: 16 опытных разработчиков выполняли 246 задач в зрелых open-source репозиториях. С ИИ-инструментами они работали на 19% дольше, хотя сами ожидали ускорения примерно на 24%.
• Faros AI, 2025: в командах с высоким уровнем использования ИИ закрывалось на 21% больше задач и вливалось на 98% больше pull request. Время ревью при этом выросло на 91%.
• DORA, 2024: рост использования ИИ на 25% коррелировал со снижением стабильности поставок на 7,2%.

Эти исследования отличаются выборкой и методикой, поэтому напрямую их складывать нельзя. Но общий мотив повторяется: объём вывода растёт, а итоговая скорость доставки и качество не растут вместе с ним.

Почему это вопрос денег

Многие компании оценивают отдачу от ИИ-инструментов по косвенным признакам: долю принятых подсказок, число строк, количество PR. Если узкое место в ревью, эти показатели растут, а бизнес-результат стоит на месте. Лишний код превращается в незавершённую работу, то есть в очередь, которая устаревает и конфликтует с соседними изменениями. Хуже того, перегруженные ревьюеры начинают пропускать изменения не глядя, и тогда экономия оборачивается техническим долгом и инцидентами.

Как перестроить процесс

Если агенты уже работают в вашей команде, имеет смысл поменять сам процесс, а не только набор инструментов:

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

ИИ-ревьюеры могут стать первым фильтром, но решение о слиянии пока остаётся за человеком, и именно эта часть цепочки определяет реальную скорость выпуска софта.