85% участников GitLab AI Accountability Report 2026 считают, что AI уже перенес узкое место разработки из написания кода в код-ревью. Но в колонке для The New Stack Стив Фентон спорит с самой постановкой вопроса: если после ревью изменения продолжают лежать в очереди перед релизом, значит узкое место разработки находится не там, где на него принято показывать. Для русскоязычных команд это неприятная, но полезная мысль: ускорять генерацию кода и разгонять ревью недостаточно, если продакшен по-прежнему живет по расписанию релизных поездов.
Фентон, сотрудник Octopus Deploy и шестикратный Microsoft MVP, разбирает довольно популярный тезис последних месяцев: AI-ассистенты вроде GitHub Copilot, Cursor и Claude Code ускорили написание кода, поэтому главным тормозом теперь стало ревью pull request’ов. По данным The New Stack, автор предлагает простой тест: сколько изменений в вашем сервисе уже прошли код-ревью, но еще не выкатились пользователям? Если ответ больше одного, то бутылочное горлышко, скорее всего, находится дальше по цепочке. И это уже не спор о терминологии, а вопрос о том, где компания реально теряет время, деньги и предсказуемость поставки.
В подтверждение он приводит данные собственного исследования Octopus Deploy. У половины команд в одном релизном батче накапливается от 2 до 10 изменений. Еще у четверти команд — от 11 до 50. В сумме более 90% команд выкатывают не по одному изменению, а пакетами. Отсюда вывод автора: индустрия слишком привыкла к батчам и перестала считать их проблемой. Очередь на код-ревью видна всем, потому что она живет в интерфейсе GitHub или GitLab. Очередь перед тестированием, согласованием, окном релиза или ручным деплоем часто размазана по процессу, поэтому кажется нормой.
Контекст здесь важен. AI действительно меняет входной поток: кода становится больше, pull request’ов тоже. Фентон ссылается на исследование Faros AI по 10 тыс. разработчиков: в командах с высокой степенью использования AI число смерженных pull request’ов выросло на 98%, время на ревью — на 91%, а средний размер PR — на 154%. Отдельно он упоминает исследование Cursor, проведенное вместе с экономистом из Чикагского университета: после того как кодовый агент Cursor становится инструментом по умолчанию, компании начинают мерджить на 39% больше pull request’ов. Иными словами, давление на ревью правда растет. Но это еще не делает ревью главным ограничением всего процесса.
Логика тут почти производственная. Если ускорить этап, который не является реальным ограничением, система в целом быстрее не станет. Она просто быстрее наполняет следующую очередь. В случае разработки такой очередью оказывается все, что происходит после merge: ручная проверка, change approval, релизный поезд, узкие окна выкладки, сложный деплой, зависимость от других команд, feature flag без нормальной операционной практики. Автор формулирует это жестко: ускорение ревью при батчевой поставке лишь быстрее подвозит изменения к настоящему затору. Для бизнеса это означает рост незавершенной работы, для разработчиков — больше контекста в голове, для эксплуатации — более рискованные и тяжелые релизы.
Из этого следует еще один неприятный вывод для рынка AI-инструментов. Многие исследования о влиянии генеративного AI на разработку заканчиваются в точке merge. Они измеряют количество открытых и закрытых PR, скорость ревью, часы, потраченные инженерами, иногда удовлетворенность команд. Но не спрашивают, сколько времени изменение ждет после одобрения и сколько соседних изменений упаковывают вместе до того момента, когда пользователь вообще получает ценность. Пока метрики обрываются на merge, у руководителей складывается удобная, но ложная картина: кажется, что нужно еще немного автоматизировать ревью, и конвейер полетит. На практике он нередко упирается в старый добрый релизный процесс, который существовал задолго до прихода LLM.
Для российских и русскоязычных команд здесь мало абстрактной философии и много прикладного смысла. Если компания уже вложилась в AI-помощников, а заметного ускорения time-to-production не произошло, проблема может быть не в качестве подсказок модели и не в дисциплине ревьюеров. Сначала стоит посмотреть на размер релизного батча, долю изменений, которые ждут выкладки после одобрения, и среднее время от merge до продакшена. Именно здесь часто спрятано узкое место разработки, которое не видно на дашбордах для engineering management. И если ретроспективы месяцами не дают ощутимого улучшения, причина может быть в том, что команда оптимизирует самый заметный этап, а не самый ограничивающий.
Главный вопрос теперь не в том, заменит ли AI часть рутины в кодинге или ревью. Вопрос в другом: готовы ли компании пересматривать релизную механику, которая десятилетиями считалась нормальной. Если AI и правда увеличивает поток изменений, то старые батчевые процессы становятся не просто неудобством, а прямым ограничителем отдачи от всех инвестиций в AI-разработку.