Как ревьюить pull request, который написал ваш ИИ-агент

ИИ-агенты для кодинга больше не просто предлагают код — они открывают pull request'ы. Во многих командах один инженер теперь курирует десятки PR'ов, написанных агентами, за день, и узкое место незаметно сместилось с написания кода на его ревью. Навык, который защищает вашу кодовую базу, — это больше не «умеете ли вы запромптить агента», а «умеете ли вы отревьюить то, что агент возвращает».

Загвоздка в том, что PR'ы от агентов ломаются иначе, чем человеческие. Исследование от января 2026 показало, что изменения, сгенерированные агентами, несут больше избыточности и больше технического долга на каждое изменение, чем код, написанный человеком. Поэтому ревьюить их «на автопилоте» нельзя. Вот практичный распорядок, во многом основанный на собственном руководстве GitHub по ревью pull request'ов от агентов.

Сначала проверьте изменения в CI

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

• удалённые, переименованные или пропущенные тесты
• сниженные пороги покрытия
• шаг линтинга или проверки типов, тихо спрятанный за новым условием
• || true, дописанный к команде теста или сборки, чтобы она всегда «проходила»
• workflow'ы, отключённые для pull request'ов или форков

Любое изменение, ослабляющее CI, — это блокер, пока оно не получит явного обоснования. Считайте зелёные галочки осмысленными только в том случае, если сами проверки не были смягчены в том же PR.

Охотьтесь на дублированный код

У агентов есть слепота к переиспользованию: они с радостью напишут совершенно новый хелпер formatCurrency, не заметив того, что уже живёт тремя папками дальше. Следите за новыми вспомогательными функциями, повторяющими существующие, за логикой валидации, переписанной в двух местах, или за «почти таким же» middleware под другим именем. Заметив кандидата, поищите в репозитории эквивалент и потребуйте консолидации перед мержем. Если не контролировать это, именно так и накапливается тот самый лишний технический долг.

Пройдите критический путь вручную

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

• граничные условия: ноль, пусто, максимум, null
• проверки прав доступа на каждой ветке, а не только на счастливом пути
• состояния гонки при разделяемом состоянии

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

Конкретный пример. Агент «исправляет» эндпоинт скидок, и все тесты проходят. Вы проходите путь и замечаете, что новый код читает cart.items до проверки if (!cart) return. У вышедшего из аккаунта пользователя cart равен null, и маршрут выбрасывает 500 — случай, который агент так и не протестировал, потому что прогнал только счастливый путь. Две минуты ручной трассировки поймали то, что скрыла зелёная галочка.

Отклоняйте сразу, если PR слишком большой

Не каждый PR от агента заслуживает глубокого ревью. Отправьте его обратно за версией поменьше, если он:

• затрагивает пять или более несвязанных файлов
• не укладывается в одно предложение
• приходит без плана реализации
• меняет только тестовые файлы, пока CI всё ещё падает

Большие, бесплановые PR'ы всё равно обычно заходят в тупик. Запросить рамки заранее быстрее, чем потом распутывать разросшийся дифф.

Доверьте механическую часть автоматике

Используйте автоматического ревьюера — review от Copilot, Bugbot от Cursor, Greptile или подобный — как обязательное условие, а не как замену. Пусть он ловит придирки к стилю, очевидные ошибки и отсутствующую обработку ошибок, чтобы ваше внимание оставалось свободным для решений, которые модель принять не может: архитектурного соответствия, бизнес-корректности и безопасности. Эти инструменты также вознаграждают настройку: пользовательские правила, построенные вокруг ваших собственных стандартов кодирования и политик репозитория, дают куда более полезную обратную связь, чем настройки по умолчанию.

Чек-лист на 10 минут

Для PR'а с правильно очерченными рамками весь этот распорядок укладывается примерно в десять минут:

1. Просмотр и классификация (1–2 мин) — узкое исправление или разросшееся изменение?
2. Дифф CI (2–3 мин) — отметьте всё, что ослабляет тестирование.
3. Новые утилиты (3–5 мин) — поищите дубликаты.
4. Критический путь (5–8 мин) — пройдите логику самостоятельно.
5. Безопасность (8–9 мин) — проверьте секреты, токены и любые шаги с LLM в цепочке.
6. Доказательства (9–10 мин) — потребуйте падающий-затем-проходящий тест для изменений логики.

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