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

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

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

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

How to Kill the Code Review Автор: Ankit Jain Оригинальный текст:

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

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

И даже с ревью что-то ломается. Мы научились строить системы, которые справляются со сбоями, потому что приняли: одного ревью недостаточно. Отсюда — feature flags (флаги функций), поэтапные раскатки и мгновенные откаты.

Нужно перестать читать весь код

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

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

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

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

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

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

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

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

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

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

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

Одобрение человеком в цикле переходит от «Вы правильно это написали?» к «Решаем ли мы правильную проблему с правильными ограничениями?». Наиболее ценное человеческое суждение осуществляется до написания первой строки кода, а не после.

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

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

В форме правил:

Код не должен писаться людьми

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

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

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

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

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

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

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

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

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

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

Правила написания кода — могут быть кастомными линтерами

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

Доменные контракты — специфичные для фреймворка, сервиса или части кодовой базы, например: Домен платежей: все суммы используют тип Money

Критерии приёмки — специфичные для задачи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В конечном счёте, если агенты прекрасно справляются с кодом, какая разница, можем мы его прочитать или нет?

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot