За полгода дискуссия о том, нужно ли ревью кода в эпоху ИИ, сделала разворот на 180 градусов: отменять проверку не надо, надо убрать ритуал построчного просмотра ради галочки. Для русскоязычных команд, которые уже впускают Copilot-подобные инструменты и агентные IDE в продакшен-пайплайн, это неприятный, но полезный сигнал: проблема не в том, что ИИ пишет код, а в том, кто теперь отвечает за смысл изменений.
Инженер и автор Ankit Jain в колонке от 30 сентября пишет для The New Stack, что его прежний тезис о необходимости убить code review был ошибочным. Ошибочным не потому, что классическое построчное чтение диффа внезапно снова стало эффективным. А потому, что вместе с «театром ревью» легко выбросить самую ценную часть процесса: человеческое суждение, передачу контекста и договорённость о том, какие инварианты в системе нельзя ломать.
Jain напоминает: ревью давно не сводится к охоте на баги, хотя именно так его часто продают менеджерам и самим себе разработчики. В исследовании Alberto Bacchelli и Christian Bird, опубликованном на ICSE в 2013 году, авторы разобрали 570 комментариев в код-ревью Microsoft. Результат был отрезвляющим: 44% опрошенных разработчиков называли поиск дефектов главной целью ревью, но только 14% реальных комментариев относились к дефектам. Остальное — улучшение читаемости, обсуждение решений, обмен знаниями, уточнение архитектурных ограничений и та самая инженерная социализация, которую трудно запихнуть в метрику.
ИИ меняет баланс. Модель не устаёт, не пропускает строки из-за пятничного созвона и может одинаково внимательно смотреть сотый pull request за день. Поэтому идея «пусть один агент пишет, второй агент ревьюит, первый исправляет, а человек нажимает merge» выглядит соблазнительно. На бумаге. На практике человек в такой схеме превращается в нотариуса при чужом диффе: он не участвовал в рассуждении, не видел отвергнутые варианты и вынужден за минуты восстановить контекст, который агенты накопили в ходе работы.
Главная претензия Jain не к самим моделям, а к месту, куда их ставят. Если ИИ-ревьюер смотрит только на готовый diff, он видит артефакт слишком поздно. Он может указать на подозрительный код, но не знает, почему была выбрана именно эта граница модуля, какие требования конфликтовали и какой риск команда сознательно приняла. Поэтому автор предлагает сместить ревью ближе к моменту принятия решений: пусть разные агенты спорят до появления pull request, фиксируют, какие варианты предлагались и почему были отклонены, а человек смотрит не каждую строку подряд, а журнал расхождений, намерения и нерешённые вопросы.
В этой модели ревью кода становится не инспекцией текста, а проверкой системы ограничений. Линтеры, типы, тесты, контракты API и политики безопасности должны забирать на себя всё детерминированное: форматирование, очевидные ошибки, нарушения стиля, простые регрессии. Человеку остаётся то, что всё ещё плохо автоматизируется: понять, правильную ли задачу решали, не заложили ли архитектурный долг, не нарушили ли границы владения и кто будет отвечать, если изменение выстрелит в продакшене.
Для бизнеса это звучит менее эффектно, чем обещание «ИИ ускорит разработку в 10 раз», зато ближе к реальности. Агентная разработка увеличивает объём кода и число параллельных изменений. Если процесс ревью остаётся прежним, узкое место просто переезжает в голову сеньора, который теперь разбирает не один понятный pull request, а пачку изменений, созданных без его участия. Экономия на написании кода быстро превращается в долг на проверке, сопровождении и инцидентах.
Для разработчиков вывод ещё прямее: ревью кода не исчезает, но меняется предмет проверки. Хороший ревьюер всё меньше похож на корректора синтаксиса и всё больше — на владельца инвариантов: он знает, какие свойства системы должны сохраняться при любых изменениях, какие решения требуют человеческого согласования и где автоматике можно доверять без отдельного ритуала. Это повышает планку для инженерной культуры. Нельзя просто подключить агента к репозиторию и надеяться, что второй агент его проконтролирует. У модели нет репутации, зоны ответственности и неприятного разговора после ночного инцидента.
Следующий спор в командах будет не о том, нужен ли ИИ на ревью, а о том, какой артефакт вообще должен смотреть человек: дифф, список предупреждений, протокол решений, набор инвариантов или историю спора между агентами. Победит, вероятно, не самый умный бот и не самый строгий чек-лист, а процесс, где автоматизация забирает скучную проверку, а люди перестают изображать внимательное чтение тысячи строк и наконец занимаются тем, ради чего ревью кода было полезно с самого начала.