Цифра 85% в заголовке The New Stack звучит как диагноз: код-ревью bottleneck стало новой проблемой команд, которые уже пустили AI-агентов в повседневную разработку. Для русскоязычных разработчиков, тимлидов и CTO смысл тут неприятно практический: писать код стало быстрее, а вот принимать изменения в main — нет, и именно на этом стыке теперь копится риск.
Как пишет The New Stack, главный сбой в популярном нарративе про «агенты ускорят разработку» в том, что скорость генерации кода и скорость безопасного мерджа — это вообще не одно и то же. Автор текста Арджун Айер формулирует это жестко: merge — это контракт. Как только изменение попадает в основную ветку, на нем начинают строиться другие команды, пайплайны, сервисы и релизы. И если AI научился быстро собирать pull request, это еще не означает, что организация научилась так же быстро и надежно подтверждать его качество.
Это важный разворот в дискуссии вокруг AI coding tools. Последние два года рынок был занят в основном фронт-офисом автоматизации: кто быстрее пишет код, кто сам открывает PR, кто лучше чинит баги, кто убедительнее имитирует «автономного инженера». В такой оптике код-ревью выглядело чем-то вторичным, почти механическим шагом после генерации. Статья The New Stack спорит именно с этим упрощением. Узкое место сместилось не в IDE и не в prompt, а в момент, когда кто-то должен взять на себя ответственность за изменение и сказать: да, это можно класть в main, на это можно опираться дальше.
Для инженерных команд мысль не новая, но сейчас она стала острее. Когда код писал человек, организация хотя бы примерно понимала, где искать контекст: автор знает задачу, ревьюер знает систему, обсуждение в PR помогает восстановить логику решения. С агентами throughput растет быстрее, чем способность команды удерживать этот контекст в голове. PR может приехать быстрее, выглядеть аккуратнее и даже пройти тесты, но вопрос о том, кто понимает последствия изменения на уровне архитектуры, схем данных, контрактов между сервисами и побочных эффектов в проде, никуда не делся. Скорее наоборот: он стал дороже.
Именно поэтому тезис про merge как контракт звучит не как красивая метафора, а как инженерное предупреждение. Любой merge в зрелой компании — это не «код добавили в репозиторий», а фактически обещание, что изменение выдержит чужие зависимости. На нем могут строиться другие команды, в него могут уехать следующие фичи, его могут подтянуть в релизную ветку, а потом оно внезапно проявится в совершенно другом контуре. Если принять AI-generated изменения в main без нормальной верификации, организация масштабирует не только скорость разработки, но и скорость распространения ошибок. Для монолита это неприятно. Для микросервисной среды и плотного CI/CD — уже системный риск.
На этом фоне особенно показателен контекст публикаций самого Арджуна Айера. В июне 2026 года он отдельно писал, что Greptile, Cursor и Devin сходятся в одном: агентам нужно не просто давать писать код, им нужно давать запускать и проверять его на чем-то, что похоже на реальную среду. Еще раньше, 11 июня, он сформулировал ту же линию прямее: агентная разработка упирается в verification, а для cloud-native софта это прежде всего runtime-проблема. Иначе говоря, рынок понемногу уходит от восторга по поводу генерации к более скучной, но куда более важной теме: кто и как доказывает, что изменение безопасно после того, как агент его предложил.
Для бизнеса отсюда следует довольно прозаичный вывод. Если команда покупает AI-инструменты ради роста скорости, но не вкладывается в merge gates, тестовые окружения, политику ревью и автоматическую проверку контрактов, она создает себе новую очередь, только уже на более дорогом участке. В этом месте начинают тормозить релизы, выгорают сильные ревьюеры, а менеджмент получает странную картину: вроде бы PR стало больше, а предсказуемость поставки не улучшилась. Знакомый сценарий для компаний, которые автоматизировали первую половину процесса и почти не тронули вторую.
Для разработчиков и тимлидов практический смысл еще проще. В эпоху AI-агентов ценность ревьюера растет не как человека, который ловит табы, нейминг и пропущенную запятую, а как инженера, который проверяет контракт изменения: совместимость, архитектурные границы, побочные эффекты, наблюдаемость, откат, влияние на соседние команды. То есть хорошее ревью становится менее «косметическим» и более системным. Если этот слой не усилить автоматизацией и четкими правилами допуска в main, то код-ревью bottleneck останется не случайным перекосом, а новой нормой разработки с AI.
Отсюда и главный вопрос для отрасли: смогут ли компании перестроить процесс так, чтобы AI ускорял не только написание кода, но и доверие к нему. Потому что пока агенты научились быстро предлагать изменения, а ответственность за merge по-прежнему лежит на людях, именно эта граница и будет определять реальную скорость разработки, а не рекламные демо очередного «автономного» помощника.