У гарвардского исследования большая выборка: 718 компаний и около 300 млн рабочих событий из данных платформы инженерной аналитики Jellyfish. Кроме строк кода и PR, агенты добавили 20% коммитов, а число закрытых задач в Jira значимо не выросло: если рост и был, то не больше 12%.

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

• Время от отправки PR до слияния выросло на 49% (исходно около 7 дней).
• Доля PR с запросом правок выросла почти вдвое, с 13% до 25%.
• Комментариев на один PR стало больше на 35%.
• Доля таких сотрудников, которые ревьювят код, увеличилась с 29% примерно до 33%, то есть на 14%.

Один из джуниоров, с которыми авторы говорили, рассказывает: коммиты можно было делать быстро, но ревью оставалось узким местом. На проекте менять код разрешалось одному сеньору, и тот успевал смотреть чужой код раз в неделю. Но после сбоев из-за коммитов от AI для такого кода ввели ещё и обязательное одобрение сеньора.

Теория ограничений говорит: если ускорить этап, который не является узким местом, вся система быстрее не станет. Авторы той же работы считают, что инженеры пишут код только 30–42% рабочего времени: 42% получилось по данным Jellyfish, 30% по опросу ста инженеров. Ускорили кодинг и забили следующий этап конвейера.

Сабри Фарраг из Университета Восточного Лондона в обзоре называет противоречие данных парадоксом продуктивности и надёжности (Productivity-Reliability Paradox): на понятных задачах агенты ускоряют работу, а в поставке выигрыш не виден. Причина, по его выводам, в слабых спецификациях, а не в возможностях моделей.

В подкасте создатель AI-агента Pi Марио Цехнер сказал, что не считает код бесплатным: последствия рано или поздно догонят, а лишний код только откладывает расплату.

Руководитель R&D-отдела описал это на Reddit изнутри. Команда опытных инженеров три месяца пробовала Claude Code, а компания собиралась раскатать инструмент примерно на 6000 сотрудников. Код генерируется на удивление хорошо, но сгенерированное нужно ревьюить, и ревьюеры тонут.

How do you manage a delivery bottleneck that has shifted to the code review stage?
by u/code_beer_repeat in ExperiencedDevs

Объём кода для честной оценки агента не годится. Мерить стоит Cycle Time: сквозное время от появления задачи в бэклоге до момента, когда задача работает на проде.

И тут пригодятся ещё несколько показателей:

• Pickup Time. Сколько PR лежит в очереди, пока не откроет ревьюер.
• Review Time. Сколько занимает проверка до аппрува.
• Rework Rate и Code Churn. Доля кода, который переписывают или удаляют в первые недели после мёрджа.
• Cost per Successful Task. Стоимость задачи с учётом токенов и повторных попыток исправить ошибки.

Лиз Фонг-Джонс, Technical Fellow компании Honeycomb, предлагает в слайдах доклада повесить на стену долю переделок за полгода вместо числа PR в день: скорость должна пережить нагрузку на сопровождение.

Исследователи из Анкары (Анкарский университет, Университет Билкент, Microsoft) описали концепцию Agentic Code Review — ревью с участием агентов. В ней два приёма, третий из работы о парадоксе:

• Карта изменений (Semantic Diff-Map). Агент группирует правки по функциям, классам и модулям и привязывает к ним отчёты анализа, результаты запусков и проверку соответствия задаче.
• Меньше придирок. Отдельный агент замечает поверхностные комментарии вроде споров об именах переменных и не даёт ревью скатиться в мелочи (bikeshedding).
• Сначала спецификация (Spec-First). Спецификацию и тестовые сценарии утверждают до генерации кода. Фарраг считает дисциплину спецификаций главным ограничением надёжности кода от AI.

Практики добавляют ещё две вещи. В руководстве по agentic engineering Саймон Уиллисон, соавтор Django и создатель Datasette, пишет о PR на сотни и тысячи строк от агента, которые автор сам не открывал: так работа перекладывается на коллег. «Первый проход ревью — это ваша ответственность, а не то, что стоит спихивать на других».

В докладе на конференции LDX3 в Лондоне в 2026 году Фонг-Джонс описывает Honeycomb: пиковое число слияний за будний день выросло примерно с 30 до 74. Оговорка из доклада: это пик будних дней, совпавший с организационными изменениями. По слайдам, у ревью две работы: ловить баги и создавать общее понимание кода. Первую можно автоматизировать, а вторая требует отдельного места и не должна зависеть от одобрения PR. Внимание сеньора при этом приходится распределять сознательно.

Что ещё работает, руководители команд обсуждают на Reddit: от оценки риска каждого PR до спецификаций, которые собирают ещё до кода.

How are you keeping PR review from becoming the bottleneck now that AI writes more of the code?
by u/nateritter in EngineeringManagers

В работе о парадоксе приняты три уровня AI-помощи: подсказки в редакторе (Passive Suggestion), генерация по описанию (Active Generation) и автономные агенты (Autonomous Agency). Судя по гарвардским данным, ревью упирается именно в затор на третьем уровне: у ассистентов значимого эффекта нет.

Фонг-Джонс называет такой порядок: сначала непрерывная поставка вместе с наблюдаемостью и SLO, затем владение кодом и файлы с правилами для агентов (CLAUDE.md), затем быстрые сборки и фиче-флаги. Если нет владельцев и общих правил, AI только усиливает путаницу.

• Книга «The Goal» создателя теории ограничений Элияху Голдратта и Джеффа Кокса (1984) — теория ограничений, изложенная в романе о директоре завода, у которого три месяца, чтобы спасти производство.

• Книга «Accelerate» Николь Фордсгрен, Джеза Хамбла и Джина Кима —  исследование, на котором держатся метрики DORA (время от коммита до продакшна, частота релизов).

• Курс DeepLearning.AI «Generative AI for Software Development» на Coursera. Командной работе посвящён второй курс серии, «Team Software Engineering with AI»: тесты, отладка, документация. По описанию программы, ревью-заторы и метрики потока в ней не разбираются.

Сухой остаток из сказанного, как короткий план для вашей команды:

• Автор PR  делает первый проход ревью сам.
• Проверки, для которых не нужно понимать код, берёт на себя машина. Ревьюерам остаётся общее понимание кода.
• Результат оценивают по Cycle Time и доле переделок за полгода.

Если после подключения AI Cycle Time не снизился, причину стоит искать в устройстве процесса.