TL;DR
Exploration-nudging prompt (промпт, подталкивающий к исследованию) — это инструкция ревьюеру, которая велит не ограничиваться чтением диффа. Агент должен ходить по репозиторию, искать места использования изменённого кода, проверять гипотезы запуском. В статье это дало до +5,8% найденных багов при росте цены всего на 10%. Мультиагентная схема (несколько ревьюеров параллельно) даёт +4,7%, но стоит в 5,5 раза дороже.
Главная находка: агенты-ревьюеры стали хорошими, но не заменяют человека. Лучший из них ловит около 70% известных багов в топ-5 замечаний, остальные 20–30% пропускает. Хуже всего он справляется с большими и разнородными PR. Ещё хуже — с багами, которые не видны из диффа и требуют знать проект. На закрытых промышленных репозиториях качество падает до четверти. Кроме того, агенты почти не запускают код (меньше 10% шагов), верят описанию PR и комментариям в коде, даже когда те вводят в заблуждение. Уверенный ответ «багов нет» поэтому ничего не гарантирует.
Практический вывод — пять правил. Подгоняй глубину ревью под сложность PR. Задавай агенту приоритеты проекта. Клади знания о репозитории в файл инструкций. Разные PR отдавай разным моделям. Периодически перепроверяй качество ревьюера на своих старых багах.
Схема метода
ШАГ 1: Дай агенту контекст → PR (заголовок, описание, дифф) + репозиторий + файл с правилами проекта
ШАГ 2: Запрети верить на слово → описание PR и комментарии считать гипотезой, не фактом
ШАГ 3: Подтолкни к исследованию → искать вызовы, смежные модули, запускать код/тесты
ШАГ 4: Требуй структурный вывод → список замечаний, ранжированный по серьёзности (review.md)
ШАГ 5: Читай топ-5 → человек проверяет верхушку списка
(всё в одном системном промпте / файле инструкций агента)
ЭСКАЛАЦИЯ: большой PR / критичный модуль / нелокальная логика → больше усилий + человек обязательно
Пример применения
Задача: Вы тимлид в сервисе доставки еды. Claude Code пишет код быстрее, чем команда успевает читать. Сегодня в проде PR «Частичный возврат по заказу»: деньги, округление копеек, заказы с промокодом и баллами. Баг из этой зоны обойдётся в живые рубли, а прочитать дифф в 600 строк некому.
Промпт:
Ты — ревьюер кода в сервисе доставки еды. Твоя задача — найти баги в PR,
а не оценить стиль.
<Контекст_проекта>
- Деньги хранятся в копейках (int), никаких float.
- Заказ может быть оплачен частично баллами «Лояльность» и частично картой.
- Возврат всегда идёт в обратном порядке: сначала на карту, потом баллами.
- Критичный приоритет: корректность денежных операций и идемпотентность
(повторный вызов webhook от платёжного провайдера не должен делать
второй возврат).
Заголовок: Частичный возврат по заказу
Описание: Добавлен метод refund_partial(order_id, amount). Учитывает промокоды.
<Правила_ревью>
1. Описание PR и комментарии в коде — это гипотезы автора, а не факты.
Проверяй по самому коду.
2. Не ограничивайся диффом. Найди все места, где вызываются изменённые
функции, и смежные модули (платёжный webhook, расчёт скидок, баллы).
3. Если есть сомнение в поведении — запусти тесты или напиши короткую
проверку и запусти её.
4. Мне не сообщают, есть ли в PR баг. Не подстраивайся под ожидание
«что-то найдётся»: если уверенных находок нет, так и скажи.
5. Результат запиши в review.md: список замечаний, отсортированный
по серьёзности (critical / high / medium / low). У каждого:
файл и строка, в чём баг, при каких входных данных он проявится,
как проверить.
Результат: Агент прочитает не только дифф, но и смежные файлы: webhook, расчёт промокодов, начисление баллов. Часть гипотез он проверит запуском тестов. На выходе — файл review.md со списком замечаний, где наверху самое опасное: например, повторный возврат или потеря копеек при делении скидки. Для каждого замечания будет указано, как воспроизвести. Верхние 5 пунктов вы читаете сами. Кто решает, мержить ли PR, — человек.
Почему это работает
Слабость. Ревьюер «в лоб» читает дифф и верит тому, что написал автор. Если в описании сказано «учитывает промокоды», он принимает это как факт. Многие баги живут не в изменённых строках, а в том, как изменение ведёт себя в остальном проекте. Агент при этом редко сам проверяет догадки запуском.
Сильная сторона. Модель хорошо ищет по коду, читает чужие файлы и строит гипотезы. Если явно разрешить и потребовать это делать, она тратит ходы на поиск, а не на быстрый вывод. Поэтому цена растёт всего на 10%, а полнота — на несколько процентов.
Рычаги управления:
- Приоритеты проекта (блок <Контекст_проекта>) → направляют внимание на то, что для вас критично: деньги, безопасность, совместимость API. Меняй под модуль.
- Знания о репозитории → чем больше правил и архитектурных оговорок, тем лучше на крупных закрытых кодовых базах, где «одного диффа» мало.
- Требование запускать → убери, если среда без запуска кода. Ждать прироста не стоит.
- Топ-5 по серьёзности → число можно менять под внимание команды: чем меньше у людей времени, тем важнее порядок.
- Выбор модели → дешёвая малая модель для простых PR, дорогая большая для сложных.
Шаблон промпта
Точный текст промпта из статьи в доступной части не приведён. Шаблон ниже собран по описанным в ней элементам: контекст PR, запись в review.md, ранжирование по серьёзности, нельзя говорить агенту, что баг есть, запрет читерства, подталкивание к исследованию.
Ты — ревьюер кода. Задача: найти баги в PR {название_PR}. Не оценивай стиль,
нейминг и мелкие придирки.
<Контекст_проекта>
{приоритеты_проекта: что критично — деньги, безопасность, совместимость, производительность}
{архитектурные_правила_и_ловушки}
Заголовок: {заголовок}
Описание: {описание}
<Правила_ревью>
1. Описание PR и комментарии в коде — гипотезы автора, не факты. Проверяй по коду.
2. Не ограничивайся диффом. Найди вызовы изменённых функций, смежные модули,
поведение внешних библиотек.
3. Сомневаешься — запусти {тесты_или_команда} или напиши короткую проверку.
4. Тебе не сообщают, есть ли баг. Если уверенных находок нет — так и скажи.
5. Не используй интернет и не ищи готовые решения вне репозитория.
6. Запиши результат в review.md: список замечаний, от самого серьёзного
к менее серьёзному (critical / high / medium / low).
У каждого: файл и строка, суть бага, при каких данных проявляется,
как проверить.
Что подставлять: {приоритеты_проекта} — что для вас дороже всего сломать. {тесты_или_команда} — реальная команда запуска тестов. {архитектурные_правила_и_ловушки} — то, что новичок в проекте не знает (лучше вынести в AGENTS.md или CLAUDE.md и ссылаться на файл).
🚀 Быстрый старт — вставь в чат:
Вот шаблон промпта для агента-ревьюера кода. Адаптируй под мой проект: [опиши проект и стек].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про приоритеты проекта, неочевидные правила кодовой базы и способ запуска тестов. Именно эти поля дают главный эффект: направляют внимание агента и позволяют ему проверять догадки. Она возьмёт структуру из шаблона и соберёт промпт под ваш проект.
Ограничения
⚠️ Агент не заменяет человека: даже лучший ревьюер пропускает больше пятой части известных багов. Полностью «выключить свет» (убрать человека) пока нельзя.
⚠️ Большие и разнородные PR: чем крупнее и разнороднее изменение, тем хуже находки. Режь PR или добавляй человека.
⚠️ Баги, невидимые из диффа: там, где нужно понимать весь проект, ревью заметно слабее. На закрытых крупных репозиториях качество проседает до четверти от результата на открытых.
⚠️ Доверие к описанию PR: агенты поддаются на вводящие в заблуждение описания и комментарии. Автоматический ревьюер можно невольно убаюкать формулировкой автора.
⚠️ Прирост от промпта скромный: +5,8% — это не скачок. Серьёзные приросты через рост усилий рассуждения или мультиагентную схему дороги: во много раз дороже по цене.
⚠️ Измеряли только баги: бенчмарк проверяет, найден ли известный баг, но не стиль, архитектуру и читаемость. Ложные срабатывания (шум в ревью) в доступной части статьи не оценены. Текст статьи в доступной версии обрывается на описании экспериментов, поэтому детали по RQ4 известны лишь из резюме во введении.
Как исследовали
Идея была простой: хороший ревьюер должен как минимум ловить баги, которые люди уже подтвердили и исправили. Команда из Microsoft и CMU собрала бенчмарк CRBugBench: 1000 задач из 98 открытых репозиториев GitHub (5 языков) и ещё 800 задач из закрытых репозиториев одной большой компании. Баги брали из двух источников. Первый — комментарии ревьюеров, которые позже были исправлены до слияния. Второй — PR с исправлением, от которого по истории кода (метод SZZ) добирались до PR, внёсшего баг. Выборочная проверка 40 задач показала, что 92,5% из них корректны.
Агент получал песочницу с репозиторием, описание PR и дифф, без подсказки, что баг есть. Он писал review.md с замечаниями по серьёзности. Совпадение с настоящим багом оценивали три LLM-судьи разных семейств (большинством голосов). Согласие с человеком получилось почти идеальным (κ = 0,89). Метрика — полнота в топ-5: нашёл ли агент баг среди первых пяти замечаний, ведь внимание разработчика ограничено.
Сравнили большие и малые модели от Anthropic и OpenAI. Лучшая связка за пять месяцев выросла с 47,7% до 71,9%: модели улучшаются быстро, поэтому настройки нужно пересматривать. Удивило, что агенты почти не запускают код (лучший — в 9,7% шагов) и сильно различаются по упорству: половина прогонов Claude заканчивается к 35-му ходу, у GPT — к 17-му. Затем меняли устройство агента: подталкивающий к исследованию промпт (+5,8% за +10% цены), мультиагентность (+4,7% за 5,5× цену), усиленное рассуждение (с 36% до 57% за 23× цену). Вывод для практики: самый выгодный рычаг — текст промпта.
Адаптации и экстраполяции
🔧 Техника: добавить проверку исполнения → меньше ложной уверенности
Агенты редко запускают код, поэтому прямо потребуй: «Для каждого critical/high замечания приложи минимальный воспроизводящий тест и результат его запуска. Если воспроизвести не удалось — пометь замечание как «не подтверждено»». Замечания делятся на подтверждённые и гипотезы, и вы не тратите время на пустые.
🔧 Техника: разнести проверку по приоритетам → быстрее читать топ
Если приоритетов несколько, не перегружай один промпт. Для PR, затрагивающих деньги, запускай отдельный проход с блоком
<Контекст_проекта>только про деньги. Для безопасности — отдельный. Это не мультиагентность из статьи, а ручная аналогия: два дешёвых прохода вместо одного дорогого.
Экстраполяция: свой мини-бенчмарк. Авторы рекомендуют собрать собственный набор из багов вашего репозитория. Для небольшой команды это можно сделать за вечер:
Вот 10 багов из истории нашего проекта: {ссылки_на_исправляющие_PR}.
Для каждого найди PR, внёсший баг, и сформулируй задачу ревью:
«Вот PR, найди в нём баг». Баг агенту не раскрывай.
Прогони ревьюера по каждому PR и покажи таблицу: баг найден в топ-5 — да/нет.
Прогоняйте этот набор при смене модели или промпта: так вы заметите, что ревьюер стал хуже или лучше. Это моя экстраполяция идеи авторов, в статье такого промпта нет.
Ресурсы
- Работа: «(When) Should a Software Factory be Lights-off? Benchmarking Code Review Agents on Bug Detection» (CRBugBench)
- Авторы: Chenyang Yang (Carnegie Mellon University), Hao He, Ti-Chung Cheng, Jenna Butler, Emerson Murphy-Hill (Microsoft), Carmen Badea, Christian Bird (Microsoft Research)
- Упомянутые в статье работы: CodeReviewer, SWR-Bench, c-CRAB, CR-Bench, AACR-Bench, метод SZZ для поиска PR, внёсшего баг