AI-ревью кода перестало быть аккуратной надстройкой над pull request: оно уже меняет саму механику проверки изменений. 8 сентября 2026 года The New Stack описал спор двух инженеров о том, что делать с потоком AI-сгенерированного кода в очередях на ревью, и для русскоязычных команд это не абстрактная дискуссия, а вопрос пропускной способности разработки.
Как пишет The New Stack, поводом стала предстоящая дискуссия с участием Джона Бристоу, Principal Developer Advocate в Octopus Deploy, и Виктора Фарсича, известного по DevOps Toolkit. Тема звучит просто: если AI ускорил написание кода, кто и как теперь должен доказывать, что этот код можно безопасно катить в продакшен?
Проблема не в том, что разработчики внезапно разучились читать diff. Проблема в объеме. Кодогенераторы и агентные IDE помогают быстрее собирать фичи, правки и рефакторинги, но итоговая нагрузка часто переезжает к ревьюерам. Senior-инженер получает не один аккуратный pull request после дня работы коллеги, а пачку изменений, часть которых написал человек, часть подсказала модель, а часть собрал агент, уверенный в себе примерно как джун после третьего успешного деплоя.
Старый процесс code review держался на негласном контракте: автор понимает контекст, ревьюер проверяет логику, команда ловит архитектурные и продуктовые ошибки до merge. AI этот контракт размывает. Автор может не помнить каждую строку, потому что часть решения была сгенерирована. Ревьюер не всегда понимает, проверяет ли он намерение разработчика или догадки модели. А менеджмент видит ускорение на этапе написания кода и не всегда замечает, что бутылочное горлышко переехало в проверку.
Отсюда и два лагеря. Первый хочет чинить ревью новыми AI-инструментами: пусть модели смотрят pull request, ищут баги, гоняют тесты, комментируют подозрительные места и снимают с людей рутину. Это звучит логично, особенно для команд с монорепозиториями, микросервисами и большим числом однотипных изменений. Но есть неприятный нюанс: если один AI написал сомнительный код, второй AI не становится автоматически независимым арбитром. Он может уверенно пропустить ошибку, галлюцинировать проблему или утопить команду в шуме.
Второй подход, который продвигают сторонники delivery pipeline как контрольного слоя, переносит акцент с обсуждений в pull request на проверяемые правила поставки. Идея грубая, но здоровая: меньше верить красивым комментариям в ревью, больше требовать воспроизводимых проверок. Тесты, статический анализ, security scanning, policy checks, окружения для прогонки, approvals по риску изменения, журналирование решений. Не человек героически вчитывается в каждую строку, а конвейер не дает пройти изменениям, которые не соответствуют условиям выпуска.
Для DevOps и platform engineering это знакомая музыка. Индустрия уже проходила похожий сдвиг, когда ручные релизы уступали место CI/CD. Сначала команды спорили, можно ли доверить сборку и деплой автоматике. Потом выяснилось, что ручной процесс не масштабируется, особенно когда релизы идут не раз в месяц, а несколько раз в день. Сейчас похожий момент наступает для ревью: если генерация кода ускоряется, проверка должна стать не героизмом отдельных экспертов, а частью инженерной системы.
Для разработчиков это означает менее романтичную, но более практичную роль. Навык читать код никуда не исчезает, зато растет ценность умения формализовать ожидания: писать тесты, описывать инварианты, задавать политики, проектировать наблюдаемость, отделять критичные изменения от косметических. В хорошем сценарии AI-ревью кода заберет часть механической проверки, а человек сосредоточится на намерении, архитектуре, пользовательском эффекте и рисках. В плохом сценарии команда просто добавит еще одного болтливого бота в pull request и назовет это процессом.
Для бизнеса вопрос еще жестче. AI-инструменты обещают ускорить delivery, но без проверки они ускоряют и попадание дефектов в продакшен. Особенно в компаниях, где compliance, безопасность или SLA важнее красивой статистики по закрытым задачам. Если руководитель разработки меряет только количество merge request, он оптимизирует вход в систему. Выходом остаются стабильные релизы, понятный риск и код, который можно сопровождать через полгода, когда модель, написавшая половину модуля, уже обновилась три раза.
Главный вывод из спора Бристоу и Фарсича не в том, что людей пора убрать из ревью или, наоборот, запретить AI-комментарии. Скорее, старый pull request перестает быть единственным местом доверия. Следующий этап AI-ревью кода будет решаться не количеством замечаний под diff, а тем, сумеет ли команда превратить проверку в исполняемый, повторяемый и достаточно жесткий pipeline.