Ключевые выводы

Объём побеждает ёмкость. Когда агент закрывает три задачи за час, а ревьюер — одну за то же время, появляется долг проверки: очередь растёт, стандарты падают, «зелёный CI» подменяет осмысленный взгляд.

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

После разницы изменений агента смотрите не на «красоту кода», а на намерение, границы и доказательства. Совпадает ли изменение с задачей? Не протекли ли данные и секреты? Тесты проверяют нужное поведение или только счастливый путь, который модель сама же и написала?

Процесс важнее героизма ревьюера. Маленькие запросы на слияние, обязательные человеческие шлюзы на опасных путях, ИИ как независимый критик и явные правила «лёгкое / глубокое ревью» масштабируются лучше, чем «пусть старший всё читает».

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

Почему ревью сломалось от объёма агентных изменений

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

Агенты нарушили баланс. Cursor, Copilot, фоновые исполнители и CLI-агенты за один цикл меняют десятки файлов, дописывают тесты «под зелёный статус» и оформляют запрос на слияние с уверенным описанием. Ревьюер получает не «небольшой патч коллеги», а пачку изменений, которую машина собрала быстрее, чем человек успевает восстановить намерение.

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

Важный нюанс: проблема не в том, что модель «плохо пишет». Часто пишет приемлемо. Проблема в том, что пропускная способность генерации выросла быстрее пропускной способности ответственности. Команда оптимизировала ввод, оставив узкое место на выходе.

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

Что ИИ умеет проверять — и что остаётся за человеком

Полезно разделить роли явно. Иначе команда либо запрещает ИИ-ревью (и тонет в очереди), либо доверяет ему всё (и получает уверенные, но слепые слияния).

Сильные стороны модели как первого прохода

Модель эффективна там, где есть локальный сигнал и повторяемый шаблон:

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

Это экономит время человека на шум. Но это не доказательство безопасности изменения.

Зона ответственности человека

Человек обязан владеть классами риска, где ошибка дороже, чем время ревью:

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

Безопасность и модель угроз. Авторизация, права, валидация входа, опасные десериализации, пути обхода контроля доступа. Модель может «добавить проверку», которая выглядит правильно и не закрывает реальный сценарий атаки.

Изоляция арендаторов и данные. Утечка tenant_id, общий кэш без ключа арендатора, запрос без фильтра владельца — классика агентных патчей в многоарендных продуктах. Выглядит как мелкий баг; стоит как инцидент уровня компании.

Необратимые операции. Миграции БД, удаление данных, изменение схем очередей, флаги, которые нельзя откатить без простоя. Здесь недостаточно «тесты зелёные»: нужен план отката и понимание окна риска.

Доменная корректность. Формула налога, статус заказа, правило согласования — то, чего нет в общих весах модели. Агент уверенно реконструирует «как обычно делают»; бизнес может требовать иначе.

Принятие риска. Слияние — решение, а не кнопка. Кто-то уполномочен сказать: «в таком виде в прод нельзя».

Контрольный список после разницы изменений агента

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

1. Совпадение с намерением

Откройте задачу и описание запроса на слияние до кода. Затем спросите: это изменение решает заявленную проблему — или соседнюю, которую модель сочла «похожей»?

Типичный сбой: задача «починить пагинацию», агент «顺便» переписал кэш и переименовал API. Разница изменений большая и «красивая», но намерение размыто. Либо откатите лишнее, либо разбейте на два запроса.

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

2. Утечки границ

Смотрите импорты, новые зависимости, прямые обращения к чужим таблицам и внутренним API. Ищите:

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

Связанный контекст по безопасной разработке — в гайде по безопасной разработке ИИ.

3. Тесты, которые утверждают нужное

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

Ревьюер проверяет:

• есть ли тест на регрессию исходного бага;
• есть ли граничные условия и отказные пути;
• не утверждает ли тест внутреннюю структуру вместо наблюдаемого поведения;
• не отключены ли проверки флажками «временно».

Экономика ложного спокойствия разобрана в статье про экономику тестирования и цену отказа.

4. Секреты, логи и утечка данных

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

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

5. Промпт и данные в системах с LLM

Если изменение касается RAG, агентов или чата: проверьте изоляцию контекста, фильтры на входе, запрет на выполнение инструментам без авторизации. Промпт-инъекция в проде — не экзотика; см. разбор внедрения инструкций в промпт в промышленной среде и ограничители ИИ.

6. «Выглядит зелёным», но хрупко

Признаки хрупкого пакета изменения:

• флаки, перезапуски CI «пока не пройдёт»;
• тесты только на happy path;
• отсутствие проверки миграции «вверх/вниз»;
• изменения в генерации кода без проверки потребителей;
• обновление зависимостей «заодно» без оценки риска по списку изменений зависимости.

Как перестроить процесс ревью под агентов

Контрольный список без процесса не масштабируется. Нужна системная перестройка.

Меньше объём на один запрос на слияние

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

Практика: в правилах агента (AGENTS.md, навыки) явно ограничивать число файлов и запрещать «заодно почисти репозиторий».

Обязательные человеческие шлюзы на опасных путях

Не всё требует одинаковой глубины. Но некоторые пути — всегда человек:

• авторизация, биллинг, платежи, персональные данные;
• миграции схемы и скрипты удаления;
• политики доступа и мультитенантность;
• инфраструктура и секреты;
• публичные API с обратной совместимостью.

Технически это CODEOWNERS, обязательные ревьюеры, отдельная метка высокого риска, блокировка автослияния.

ИИ как скептик, человек как финал

Полезный контур:

1. Автор (человек или агент) готовит пакет изменения с доказательствами.
2. ИИ-ревьюер проходит как независимый критик с другим промптом и, по возможности, другой моделью: ищет риски, дыры в тестах, расхождения с задачей.
3. Человек читает сводку рисков + критические файлы и принимает решение о слиянии.

Ошибка антипаттерна: та же модель, что писала код, «ревьюит» свой патч в том же чате. Общие допущения проходят оба слоя. Независимость важнее «умности».

Очередь и метрики долга проверки

Измеряйте не только время до слияния, а:

• возраст открытых запросов на слияние;
• долю одобрений без комментариев на путях высокого риска;
• число откатов и хотфиксов после агентных изменений;
• среднее число файлов на запрос.

Если генерация ускорилась, а эти метрики ухудшились — вы купили скорость ценой долга.

Отдельно стоит зафиксировать культуру описания запроса на слияние. Шаблон «что сделано / как проверено / что не проверено / как откатить» снижает когнитивную нагрузку ревьюера сильнее, чем любой «умный» бот. Агент может заполнить черновик шаблона; человек обязан подтвердить правду в полях «не проверено» и «откат».

Связь с моделью агентной разработки — в агентной инженерии 2026 и в тексте где генерация кода заканчивается и начинается инженерия.

Правила команды: лёгкое и глубокое ревью

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

Когда достаточно лёгкого ревью

Условия (все сразу):

• изменение локально (1–3 файла, один модуль);
• нет авторизации, данных арендаторов, миграций, секретов, публичных контрактов;
• есть целенаправленный тест на поведение;
• ИИ-скептик не поднял находок высокой тяжести;
• автор — человек, который понимает участок, или агент под жёстким шаблоном задачи.

Лёгкое ревью: прочитать описание и разницу изменений целиком, пробежать контрольный список «намерение / границы / тесты», слить. Цель — не героизм, а не тратить старший ресурс на низкий риск.

Когда обязательно глубокое ревью

Любой из триггеров:

• N файлов или касание нескольких подсистем;

• пути, чувствительные к безопасности;
• изменение контрактов, схем, очередей;
• агент работал без жёстких границ каталогов;
• тесты сгенерированы тем же агентом без негативных сценариев;
• срочность («надо вчера») — наоборот повод углубить, а не ускорить слияние.

Глубокое ревью: критические пути строка за строкой, угрозная модель на изменение, проверка утверждений тестов, план отката, второй человек на высоком риске при необходимости.

Роли

Автор отвечает за пакет: намерение, границы, доказательства, список известных пробелов. «Агент сделал» — не снятие ответственности.

ИИ-критик отвечает за полноту первого прохода и явную эскалацию.

Ревьюер-человек отвечает за вердикт и за то, что опасные классы не пропущены.

Тимлид / владелец зоны отвечает за правила маршрутизации лёгкого/глубокого и за CODEOWNERS.

Связь с тестированием, агентной инженерией и безопасностью

Ревью в эпоху ИИ нельзя изолировать от соседних контуров.

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

Агентная инженерия. Качество ревью начинается до разницы изменений: постановка задачи, границы каталогов, критерии готовности, минимальные права. Плохая задача рождает патч, который невозможно честно проверить. См. агентную инженерию.

Генерация vs инженерия. Скорость набора текста не равна готовности к проду. Ревью — момент, где это различие становится явным. См. где заканчивается генерация.

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

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

Типичные ошибки команд

Считать «зелёный CI» ревью. CI отвечает на вопрос «сломали ли мы известные проверки». Ревью отвечает на «нужно ли это сливать».

Просить ту же модель одобрить свой патч. Нет независимости — нет второго мнения.

Ревьюить только стиль. После агента стиль часто уже выровнен правилами. Истинный риск — в границах и данных.

Запретить агентов из-за инцидента. Теневое использование останется без правил. Лучше шлюзы и маршрутизация риска.

Одинаковый норматив времени ревью на всё. Либо очередь убьёт скорость, либо высокий риск проскочит. Разделяйте лёгкое и глубокое.

Не требовать от автора списка рисков. Агент не оставляет записку «что не проверено». Человек-автор обязан.

Сливать гигантский рефакторинг «потому что агент справился». Справился с генерацией, не с ответственностью за систему.

Путать скорость принятия патча со скоростью поставки ценности. Слитый код, который через день откатывают, — отрицательная скорость. Ревью, которое предотвратило инцидент, ускоряет продукт, даже если «задержало» один запрос на слияние.

Что сделать сегодня

Практический минимум на одну-две недели:

1. Ввести два маршрута ревью в команде: лёгкий и глубокий — с письменными триггерами.
2. Добавить CODEOWNERS / обязательных ревьюеров на авторизацию, биллинг, миграции, изоляцию арендаторов.
3. Ограничить агента в правилах: максимум файлов, запрет «заодно», обязательный список доказательств в описании запроса на слияние.
4. Подключить ИИ-критика отдельным шагом (другая модель или другой промпт), не в том же чате генерации.
5. Вставить контрольный список из этой статьи в шаблон описания запроса на слияние (чеклист автора + чеклист ревьюера).
6. Измерить долг проверки: возраст запросов на слияние, доля без комментариев на высоком риске, откаты после агентных слияний.
7. Провести одно разборное ревью большой разницы изменений агента всей командой — как калибровку стандарта.

Не нужно ждать идеального процесса. Нужно закрыть самый дорогой класс ошибок на следующей неделе.

Частые вопросы

Дальнейшее чтение

• Как Cursor и другие IDE работают с кодом
• Агентная инженерия в 2026 году
• Где заканчивается генерация кода и начинается инженерия
• Экономика тестирования и цена отказа
• Ограничители ИИ в 2026
• Внедрение инструкций в промпт в промышленной среде
• Безопасная разработка корпоративного ИИ
• «Чистый код»: ключевые идеи

Заключение

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

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

Коротко о подходе лаборатории: проверяемый результат важнее уверенного патча — см. Химия кода.