Использование код-ревью для устойчивой разработки с ИИ

Новостная статья Эми Баттелл (Amy Buttell) в Communications of the ACM, опубликованная 4 сентября 2026 года. Её тезис: по мере того как объём созданного ИИ кода превосходит возможности разработчиков по его проверке, peer review превращается из совместной практики контроля качества в этап управления рисками и верификации - инструмент, сохраняющий код от ИИ жизнеспособным, работоспособным и безопасным. Материал построен на интервью с фаундерами, консультантами и инженерами и не содержит собственных данных. В нём упоминаются три источника (отчёт Faros по ИИ-инжинирингу "Acceleration Whiplash", препринт на arXiv о поэтапном человеческом контроле над агентной генерацией кода в регулируемых сферах и статья Мартена Монперрю "The End of Code Review: Coding Agents Supersede Human Inspection"), но ни один из них не цитируется и не пересказывается подробно. Последняя работа по сути утверждает прямо противоположное заголовку статьи.

Как источники описывают изменения

Михаэла Грейлер (Michaela Greiler), исследователь и тренер по программной инженерии, отмечает: агенты создают масштабные изменения за минуты или секунды, что затрудняет осмысленную обратную связь от человека, а ревью смещается из командной практики в индивидуальную практику конкретного разработчика. Толга Тархан (Tolga Tarhan) из Atomic Gravity говорит, что раньше ревью было финальным фильтром, где ведущий инженер вычитывал готовый pull request, а теперь оно идёт непрерывно прямо во время разработки. Ник Чапсас (Nick Chapsas) из Dometrain перечисляет вопросы, которые теперь должен задавать ревьюер: решает ли код нужную задачу, существуют ли используемые им API и конфигурации, соответствуют ли тесты требованиям и не несёт ли изменение скрытых расходов - лишних сетевых вызовов, повторных попыток (retries), логирования, зависимостей или нагрузки на инфраструктуру.

Что именно предлагают делать

Джош Парсонс (Josh Parsons) из Honeycomb ставит на первое место договорённости: командам нужно открыто обсудить, зачем они вообще проводят ревью и что считается "хорошим" кодом, потому что это подводит к более сложному вопросу - какие условия необходимы, чтобы определённые категории кода сливались в репозиторий без единого прочтения человеком.

Ник Балнейвс (Nick Balnaves), основатель Threada, предлагает самый конкретный рабочий процесс. ИИ помогает создавать кодовую базу, тогда как разработчики отвечают за архитектуру, критерии приёмки и решения о релизах. Повторное чтение сотен правдоподобно выглядящих строк даёт ревьюерам мало пользы, поэтому они проверяют допущения, границы доверия и доказательства работоспособности. Конвейер состоит из трёх уровней: автоматические проверки, выбираемые в зависимости от затронутых файлов; свежее состязательное ревью (adversarial review), чья задача - искать баги, регрессии безопасности и ложные допущения; а также сквозная (end-to-end) валидация реального пользовательского сценария.

Снигда Алатур (Snigdha Alathur) из Spring Point Technologies описывает команды, которые требуют, чтобы тесты писал человек - либо сам, либо с помощью ИИ, но формулируя их вручную, поскольку написание теста заставляет разобраться в коде. Джейсон Коэн (Jason Cohen), основатель SmartBear, видит в ревью способ зафиксировать общие паттерны, которые упустил ИИ; это инвестиция, сравнимая с обучением джуниора, предотвращающая повторение одной и той же ошибки. Сергей Матикайнен (Sergey Matikaynen) из GoGloby называет отказ от ревью лишь его откладыванием: время проверки и процент сбоев растут, а издержки возвращаются в виде инцидентов, откатов и работы ведущих инженеров по выходным.

Место в контексте

Это позиция лагеря "ревью стало важнее". Противоположную точку зрения представляет laycock-review-by-exception, где утверждается, что большинство задач ревью нужно переносить на более ранние этапы, а проверка человеком должна стать исключением. Вопрос Парсонса о слиянии кода без участия человека указывает как раз в сторону позиции Лейкока (Laycock). Аргумент Балнейвса против перечитывания правдоподобных строк - это проблема пропускной способности, описанная в code-review-throughput-limits и reviewing-ai-code, а его "свежее состязательное ревью" - практика, рассматриваемая в cross-model-code-review и в контексте состязательных субагентов в llm-critics-are-right-use-anyway. Тесты, написанные человеком, у Алатур перекликаются с testing-heavy-no-review-workflow, но с тем нюансом, что ценность теста заключается в вынужденном понимании кода, а не только в отлове дефектов.

Связанные страницы

• agent-principal-agent-problem - почему привычный сигнал затраченных усилий при ревью перестал работать, когда код начали писать агенты
• skill-atrophy-supervision-paradox - риск в советах Коэна и Алатур: контроль за агентами разрушает именно те навыки, которые нужны для контроля
• google-code-review-looking-for - базовый чеклист ревьюера до появления агентов