Почему ревью кода не отменят: как проверять диффы от ИИ-агентов

Утверждение «жизненный цикл разработки умер» описывает сжатие, а не похороны. Стадии схлопнулись в две петли: агент в песочнице и merge request, набитый доказательствами. Человеческое ревью при этом никуда не уходит. Оно перестаёт быть чтением романа построчно и становится брифингом.

Что на самом деле схлопнулось

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

Церемонии можно сжать. Знание под церемониями — нет. Не знать, что такое SRE, — не флекс. Это дыра, которую обнаружат в три ночи, когда агент уже поблагодарил нас за успешный деплой.

Дайте агенту локальную или одноразовую песочницу

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

Поэтому:

• Сначала локально: worktree, песочница, тесты на машине разработчика, хуки, которые возвращают находки в ту же сессию.
• Одноразовая среда, если надо уйти с ноутбука: выбрасываемый раннер, превью, которое умирает вместе с веткой, клон, который не production и не main.
• Людей в этот цикл не пускать. Ревьюим результат, а не каждый вызов инструмента.

Рандомизированное исследование METR 2025 года на опытных разработчиках open source показало: с ИИ-инструментами они тратили больше времени, оставаясь уверенными, что ускорились. Позже картина усложнялась по мере развития самих инструментов. Полезный вывод уцелел: сидеть в цикле агента кажется скоростью, даже когда часы говорят обратное. Открыть merge request и узнать, что сьют красный, — это проверять духовку по почте.

Тесты в той же сессии — не второе мнение

Агент пишет тесты рядом с кодом. Хорошо. Это не независимость. Сессия, которая придумала поведение, придумала и доказательство. Агент может сделать QA сам — примерно так же, как мы проверяем собственную домашку: быстро и с подозрительно высоким баллом.

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

Спайк — это спайк, а не общая ветка по умолчанию

Внутренний цикл отлично работает на спайке. Один человек, один агент, набросок с нуля, никаких клиентов на хосте. Тут AI-native инженеры выглядят раскованно, и иногда так и есть.

Продукт с десятком инженеров, историей и веткой main, которая деплоит, — другая машина. Сжатие помогает и здесь. Просто оно не даёт права пропустить именованное «выглядит нормально» на ветке, с которой все релизят. Спайк так спайком и остаётся: его продвигают через внешнюю петлю.

Разговоры про «убить пул-реквест» промахиваются мимо цели

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

Бенчмарки LinearB за 2026 год (8,1 млн пул-реквестов) показывают это в данных:

Исследование GitLab про ответственность ИИ: 85% респондентов согласились, что узкое место переехало с написания кода на ревью и валидацию, при этом 78% сказали, что стали коммитить быстрее. Скорость пришла. Доставка за ней не последовала автоматически.

Это не аргумент удалить ревьюера. Это аргумент перестать вручать ему голый дифф на пять сотен строк.

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

Если рабочая модель звучит как «агент делает 500 PR в день, команда вычитывает около десяти», то с ревью у нас всё в порядке. Проблема с производством. Объём — не фича. Мерить кухню по числу разбитых тарелок в час — плохой KPI. Когда изменений больше, чем мы можем проверить, уменьшают батч, доводят внутренний цикл и открывают меньше мелких мержей. Резать шлагбаум потому, что объём смутил, — не решение.

DORA повторяет одну мысль десять лет: маленькие батчи, быстрая обратная связь, качество как путь к скорости. В отчёте DORA за 2025 год ИИ назван усилителем. Он усиливает команду, которая уже интегрирует мелкими кусками. И он же усиливает ту, что путает «больше диффов» с «больше прогресса».

CI должен писать брифинг для merge request

Когда внутренний цикл зелёный, задача пайплайна не просто снова позеленеть. Зелёный — входной билет. Брифинг — это еда. Merge request для такого приспособлен лучше, чем тикет-трекер, которому поручили нянчить агента. CI должен писать человеческий интерфейс. Как минимум:

1. Намерение: зачем это изменение, абзацем, с которым ревьюер может не согласиться.
2. Радиус поражения: файлы, сервисы, размер, можно ли откатить. Опечатка в документации — не однострочное изменение, которое рассылает письма десяткам тысяч людей. Скажите прямо, насколько всё плохо, если мы ошиблись, и почему это не 3500 необъяснённых строк.
3. Независимое доказательство: тесты, прогнанные там, где агента нет. Вывод, а не ощущение.
4. Покрытие именно этого изменения, а не тщеславная цифра по всему репозиторию.
5. Безопасность и секреты: сканы плюс всё, что трогает авторизацию, данные или деньги, названное простым языком.
6. Поведение: превью-URL, скриншот, дифф контрактов или пометка, что поведения здесь нет и почему.
7. «Смотрите сюда»: три места, где человеку реально стоит потратить минуты.

Лог пайплайна — это пользовательский интерфейс, а комментарий в merge request — интерфейс ревьюера. Пайплайн, который мы морим голодом, никого ни о чём не проинформирует.

Человек всё равно решает

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

Такой ревьюер должен вести себя как линтер с --fix. По умолчанию — коммит на ветку: пропущенный тест, нейминг, скопированная грабля, применённые, а не описанные. Человек потом читает чистый дифф. Стена ботовых комментариев — это больше работы, а не ревью. Комментарии остаются для вопросов, которые модель не закрывает: то ли это изменение, вписывается ли оно в архитектуру, значат ли контракты то же, что мы думаем, понимает ли человек, запустивший агента, дифф достаточно, чтобы им владеть.

Агентов не пускают коммитить в main. Коммит на ветку — не мерж. Именованный человек всё ещё жмёт merge. Практики Google по ревью сделали «Looks Good To Me» от квалифицированного инженера правилом не просто так: модель нельзя разбудить ночью. Глубина может быть меньше на правке документации в двенадцать строк. Одобрение не опционально.

Ассистенты вдобавок коррелируют с неприятной парой: менее безопасный код и больше уверенности, что всё в порядке. Боты — помощники, а не козлы отпущения. Если комментарий звучит как «ИИ одобрил», то ревью нет. Есть строка статуса.

Комментарий, который напишешь дважды, — недостающая проверка

Человеческий шлагбаум — это не только вердикт по диффу. Это взгляд на систему, которая его произвела. Фраза, которую мы напишем снова на следующем merge request, — недостающая проверка. Такое замечание ложится в одно из мест, от самого дешёвого:

• Детерминированная проверка: линт, типы или тест, который падает, когда ошибка возвращается. Цена — один прогон пайплайна.
• Стандарт для ревью-агента: суждение, которое линт не поймает. Живёт в файле, что читает этот агент, и не лезет в промпт реализатора.
• Только этот merge request: когда замечание про конкретное изменение и не повторится. Правилом не становится.

Смысл комментария в том, что он больше не понадобится. Ждать, что следующая сессия «просто будет знать лучше», — способ выпустить одну и ту же ошибку дважды. Мы превращаем замечание в проверку, и следующее ревью выходит короче, потому что предыдущее было длиннее.

Merge request — это как N человек делят кодовую базу

Схлопнутая петля в манифесте — один человек и один агент. Большинство так не релизят. Merge request — это способ N инженеров не сталкиваться, показать изменение и помочь следующему понять, почему движок скидок выглядит именно так. Ждать ревью три дня — провал процесса. Удалять merge request потому, что очередь была медленной, — выбрасывать карту из-за пробки.

Ревью в тот же день, маленькие диффы, брифинг вместо археологии — так очередь и умирает. Merge request остаётся.

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

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

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