How to Kill the Code Review

Как убить код-ревью

Код, написанный людьми, умер в 2025 году. Код-ревью умрёт в 2026-м.

Сегодня объявлена вторая волна спикеров AIE Europe и CFP для AIE World's Fair, а также подтверждено участие OpenCode в Майами! Мы также будем в Мельбурне и Сингапуре.

От редакции: Это новый выпуск в рамках нашей программы гостевых публикаций, где мы публикуем эссе об AI-инженерии, заслуживающие внимания, даже если лично мы не со всем согласны. Только что выпустив инструмент для AI-ревью, я признаю, что сам ещё не дошёл до этой точки, но она явно на горизонте, и рад, что Ankit берётся отстаивать эту позицию!

Люди и так не справлялись с код-ревью, когда люди писали код с человеческой скоростью. У каждой инженерной организации, с которой я общался, один и тот же грязный секрет: PR висят днями, одобрения ставятся формально, а ревьюеры бегло просматривают диффы на 500 строк, потому что у них своя работа.

Мы убеждаем себя, что это контроль качества, но команды десятилетиями выпускали код без построчного ревью. Как сказал мне один опытный инженер, код-ревью не было повсеместным примерно до 2012–2014 годов — просто мало кто из нас помнит те времена.

И даже с ревью всё ломается. Мы научились строить системы, которые справляются с отказами, потому что признали: одного ревью недостаточно. Это проявляется в feature flags, поэтапных раскатках и мгновенных откатах.

Нам пора перестать пытаться прочитать весь код

Команды с высоким уровнем AI-adoption выполняют на 21% больше задач и мёрджат на 98% больше pull request'ов, однако время ревью PR увеличивается на 91% — по данным более 10 000 разработчиков из 1 255 команд.

Экспоненциально растут две вещи: количество изменений и размер изменений. Мы не можем потреблять столько кода. Точка. Вдобавок разработчики постоянно говорят, что ревьюить код, сгенерированный ИИ, труднее, чем код коллег. Команды производят больше кода — и тратят больше времени на его проверку.

Ручным код-ревью эту битву не выиграть. Код-ревью — исторический шлюз одобрения, который больше не соответствует характеру работы.

AI-ревью кода — это всё ещё ревью

Инструменты AI-ревью лишь покупают нам время. Если ИИ пишет код и ИИ его ревьюит, зачем нам красивый интерфейс ревью, чтобы это отображать? Как бы ни были полезны AI-ревью, они сместятся левее в цикле разработки. Нет смысла тратить ресурсы CI и управлять версиями между циклами ревью.

Пост-PR ревью имело смысл, когда люди писали код и нуждались в свежем взгляде. Когда код пишут агенты, «свежий взгляд» — это просто другой агент с теми же слепыми зонами. Ценность здесь — в итерационном цикле, а не в шлюзе одобрения.

Мы знаем из опыта, что агенты не всегда надёжны, и вполне по-человечески думать: «Я однажды поймал ИИ на глупости, значит, надо всегда проверять». Этот инстинкт имел смысл, когда ручная проверка была осуществима. При нынешних масштабах это уже не так. И дальше будет только хуже.

От ревью кода — к ревью намерения

Ответ — переместить человеческий контрольный пункт вверх по потоку. Если мысль о том, чтобы не ревьюить код, кажется пугающей, напомню: контрольные точки в разработке уже перемещались. Мы перешли от водопадных приёмок к непрерывной интеграции. Можем сдвинуть их снова.

Разработка на основе спецификаций становится основным способом работы с ИИ. Люди должны ревьюить спецификации, планы, ограничения и критерии приёмки — а не диффы на 500 строк.

В этой новой парадигме спецификации становятся источником истины. Код превращается в артефакт спецификации. Вам не нужно ревьюить код. Вы ревьюите шаги. Вы ревьюите правила верификации. Вы ревьюите контракт, которому код должен соответствовать.

Одобрение с участием человека смещается от «Ты правильно это написал?» к «Мы решаем правильную задачу с правильными ограничениями?». Самое ценное человеческое суждение применяется до того, как будет сгенерирована первая строка кода, а не после.

Выстраивание доверия через слои

Насколько комфортно нам нужно себя чувствовать, прежде чем мы перестанем читать код?

В форме правил:Код не должен писаться людьмиКод не должен ревьюиться людьми

LLM плохо следуют инструкциям. Они отклоняются. Часто. И ненадёжны в самопроверке — уверенно скажут, что код работает, пока он горит. Решение не в том, чтобы просить LLM проверить. А в том, чтобы попросить её написать скрипт, который проверит. Переход от суждения к артефакту.

Доверие строится слоями. Это модель швейцарского сыра: ни один барьер не ловит всё. Вы ставите несовершенные фильтры друг за другом, пока дыры не перестанут совпадать. Так где ещё можно поставить шлюзы одобрения?

Слой 1: Сравнение нескольких вариантов

Вместо того чтобы просить одного агента сделать правильно, попросите трёх агентов попробовать по-разному и выберите лучший результат. Пусть соревнуются. Стоимость вариативности — самая низкая в истории программной инженерии.

Отбор не обязан быть ручным. Можно ранжировать варианты по тому, какой проходит больше верификационных шагов, какой даёт минимальный дифф, какой не добавляет новых зависимостей. Конкуренция создаёт сигнал, который не получить от единственной попытки.

Слой 2: Детерминированные ограждения

Должен быть детерминированный способ верифицировать работу. Тесты, проверка типов, верификация контрактов — вещи, у которых нет мнений, только факты.

Вместо того чтобы спрашивать LLM «Это сработало?», вы определяете шаги верификации, которые выдают серию артефактов «пройдено/не пройдено». Агент не может договориться с падающим тестом. Он либо соответствует спецификации, либо нет.

Эти ограждения можно определять как отдельные слои:

Стандарты кодирования — это могут быть кастомные линтерыИнварианты на уровне организации — безусловные требования, например: никаких захардкоженных учётных данных, API-ключей или токеновДоменные контракты — специфичны для фреймворка, сервиса или части кодовой базы, например: домен платежей — все суммы используют тип MoneyКритерии приёмки — специфичны для конкретной задачи

Шаги верификации должны определяться до написания кода, а не придумываться задним числом для подтверждения того, что уже есть. Если агент пишет и код, и тесты, вы просто переместили проблему — теперь вы доверяете агенту тестировать правильные вещи. Критерии верификации должны исходить из спецификации, а не из реализации.

Слой 3: Люди определяют критерии приёмки

Так где же люди приносят пользу? Выше по потоку — определяя, как выглядит успех.

Именно здесь Behavior-Driven Development обретает новую актуальность. BDD всегда была хорошей идеей — писать спецификации на естественном языке, описывающие ожидаемое поведение, а затем автоматизировать эти спецификации как тесты. Но подход так и не прижился полностью, потому что написание спецификаций казалось лишней работой, когда ты и так собираешься писать код.

С агентами уравнение переворачивается. Спецификация — не дополнительная работа, а главный артефакт. Вы пишете:

Агент реализует. BDD-фреймворк верифицирует. Вам не нужно читать реализацию, пока что-то не сломается.

Это люди, делающие то, в чём люди хороши: определяют, что значит «правильно», кодируют бизнес-логику и крайние случаи, думают о том, что может пойти не так. Агент берёт на себя перевод намерения в код. BDD-спецификации становятся вашим слоем верификации — детерминированным, автоматизированным и определённым до написания первой строки.

Критерии приёмки, написанные людьми и проверенные машинами. Вот шлюз, который действительно имеет значение.

Слой 4: Системы разрешений как архитектура

Что может трогать этот агент? Что требует эскалации? Это становится архитектурным решением, а не запоздалой мыслью.

Большинство агентных фреймворков трактуют разрешения как «всё или ничего». У агента либо есть доступ к шеллу, либо нет. Но гранулярность важна. Агенту, исправляющему баг в утилитной функции, не нужен доступ к конфигам инфраструктуры. Агенту, пишущему тесты, не нужна возможность менять CI-пайплайны.

Область доступа должна быть как можно уже, но достаточной для полезной работы. Если задача — «исправить баг парсинга дат в utils/dates.py», доступ агента к файловой системе должен быть ограничен этим файлом и его тестовым файлом. Не всей кодовой базой. Не «src/ и tests/». Только файлами, относящимися к задаче.

Триггеры эскалации не менее важны. Определённые паттерны — затрагивание логики авторизации, изменение схемы базы данных, добавление новых зависимостей — должны автоматически отправляться на ревью человеку, вне зависимости от уверенности агента.

Слой 5: Состязательная верификация

Разделение обязанностей: один агент выполняет работу, другой верифицирует. Они не доверяют друг другу, и в этом суть.

Это старый паттерн — именно поэтому ваша команда QA не должна подчиняться вашему инженерному менеджеру, а человек, написавший код, не должен быть единственным, кто его ревьюит.

С агентами это можно обеспечить архитектурно. Кодирующий агент не знает, что будет проверять верифицирующий агент. Верифицирующий агент не может изменить код, чтобы облегчить себе работу. Они состязательны по замыслу.

Можно пойти дальше: третий агент пытается сломать то, что построил первый, целенаправленно атакуя краевые случаи и режимы отказа. Red team, blue team — но автоматизированные и запускаемые при каждом изменении.

Выводы: Понятие «хороший код» меняется

Стимул агентной системы прост: дали задачу — могу ли я её выполнить? Могу ли угодить тому, кто её поставил? Успех агента по своей природе никогда не обусловлен долгосрочной точностью или бизнес-требованиями.

Наша задача — закодировать это в ограничениях.

Для кода, сгенерированного агентами и читаемого агентами, понятие «хороший код» станет более стандартизированным. Для новой кодовой базы придётся давать меньше указаний, потому что значения по умолчанию будут более единообразными.

Будущее — быстро поставлять, наблюдать за всем, откатывать ещё быстрее.

А не: медленно ревьюить, всё равно пропускать баги, дебажить в проде.

Мы не сможем перечитать машины. Нам нужно передумать их — выше по потоку, там, где решения действительно имеют значение. В конечном счёте, если агенты справляются с кодом, какая разница, можем мы его прочитать или нет?

Ankit Jain — основатель и CEO Aviator, где он строит инфраструктуру для AI-нативных инженерных команд. Платформа Aviator помогает современным организациям повышать уровень AI-adoption, сохраняя высокие инженерные стандарты.