Проблема у AI в разработке оказалась не там, где ее ждали. По оценке Principal Engineer в CircleCI Майкла Вебстера, человек в среднем способен качественно просмотреть около 500 строк кода за час, тогда как AI-пулреквесты легко приносят 1500 строк за 10-30 минут. Для русскоязычных команд это плохая новость: узкое место смещается с написания кода на проверку, а значит, привычный процесс code review начинает ломаться раньше, чем многие успели перестроить SDLC.
Об этом Вебстер рассказал в выступлении на QCon AI, сообщает InfoQ. Его тезис звучит довольно жестко: AI уже умеет приносить пользу в инженерной работе, а вот pull request в нынешнем виде перестает справляться с ролью основного механизма контроля качества. Особенно это заметно там, где компании переходят от работы с помощниками в IDE к headless-агентам, которые запускаются по расписанию, через вебхуки или встраиваются в автоматические цепочки доставки кода. Если раньше инженер копировал контекст между ChatGPT, редактором и репозиторием вручную, затем пришли Cursor, copilots для VS Code и более длинные агентные сценарии, то сейчас на сцену выходят системы, которые могут работать почти без человека. И именно они упираются не в генерацию, а в проверку.
На стороне пользы у CircleCI уже есть вполне приземленные кейсы. По словам Вебстера, лучше всего AI показывает себя в механических преобразованиях, когда в репозитории есть понятные правила, устойчивые паттерны и внятные acceptance-тесты. В таком режиме модель способна повторять существующую структуру на уровне, который устраивает даже сильных инженеров. Еще один показательный пример изнутри компании: внедрение темной темы в интерфейсе. Задача годами висела в бэклоге, потому что требовала пройтись почти по каждому UI-компоненту, а приоритет у нее был вечно ниже, чем у продуктовых задач. В итоге инициативу повела дизайн-команда: она задала поведенческие и визуальные правила, а агенты взяли на себя значительную часть рутинной переделки. Для бизнеса это важный сигнал: AI может расширять круг людей, которые реально вносят вклад в кодовую базу, если у них есть доменная экспертиза и рядом стоит инженерная страховка.
Но там же начинается и обратная сторона истории. Вебстер прямо говорит, что результаты остаются очень неравномерными даже внутри одной компании. Если команда годами выстраивала репозиторий, следила за архитектурными паттернами и не превращала кодовую базу в склад случайных решений, агентам проще двигаться по уже проложенным рельсам. Если таких рельсов нет, они начинают генерировать формально рабочие, но тяжело проверяемые изменения. Отсюда главный конфликт: код может быть не откровенно плохим, но его становится слишком много. Асимметрия между скоростью генерации и скоростью ревью быстро превращается в новую форму технического долга. Команда вроде бы ускорилась, однако в реальности просто перенесла затраты вперед: сегодня сэкономили время на написании, завтра заплатили за поверхностное согласование, пропущенные дефекты и затянувшееся обсуждение.
Вебстер добавляет к этому неприятную статистику по самому процессу pull request. По его словам, медианное время ревью в индустрии колеблется от 3 до 14 часов, а медианное время до merge составляет около 14 часов. Даже без AI это далеко не самый быстрый и не самый изящный этап разработки. Pull request асинхронны, обязательны почти для любых изменений и плохо масштабируются с ростом объема. В докладе прозвучала знакомая многим командами формула: пять строк получают пятьдесят комментариев, десять строк получают пять комментариев, а огромный дифф на сотни строк иногда отделывается формальным LGTM. Это не шутка про усталость ревьюеров, а диагноз процессу. Когда AI-пулреквесты становятся нормой, эта логика только усиливается: большие изменения психологически сложнее проверять, и ревью превращается либо в бутылочное горлышко, либо в ритуал для галочки.
Отсюда и практический вывод, который особенно важен для техдиректоров, engineering-менеджеров и лидов платформенных команд. Если агентный код уже приходит быстрее, чем его может прочитать человек, опираться только на ручной review опасно. Вебстер предлагает смещать акцент в сторону автоматической валидации: анализ влияния изменений на тесты, запуск релевантного подмножества проверок, более жесткие пайплайны подтверждения корректности и инструменты, которые проверяют результат до того, как он попадет на стол ревьюеру. Идея не в том, чтобы отменить code review, а в том, чтобы человек тратил время не на пролистывание трех экранов однотипного диффа, а на действительно рискованные места: архитектурные решения, бизнес-логику, границы системы, безопасность, обратную совместимость.
Для российских и русскоязычных команд здесь есть еще один неудобный, но полезный вывод. Главный актив в эпоху агентной разработки — уже не только скорость коммита и не количество сгенерированных строк, а состояние самой кодовой базы и качество инженерных правил. Хорошо структурированный репозиторий, зрелые тесты, понятные шаблоны и нормальная CI/CD-цепочка становятся не просто практиками аккуратной разработки, а обязательной инфраструктурой для работы с агентами. Без этого AI будет не ускорителем, а фабрикой больших диффов, которые некому и некогда разбирать. Если интерес к headless-агентам продолжит расти, следующим предметом гонки станет не то, какой инструмент пишет код быстрее, а то, какая команда первой научится доказывать его корректность без ручного ревью каждой тысячи строк. Подробности выступления можно посмотреть в материале .