Claude Code: как Anthropic ревьюит код, который пишут агенты

Команда Claude Code выпустила большой текст о том, как она выживает в потоке кода, который генерируют агенты: по их словам, около 90% собственного кода Claude Code пишет Claude. Авторы — Addy Osmani, Morgan Westlee Lunt и Qing Wang. Суть в одной фразе: ревью не отменили — его переставили. Машины читают код непрерывно, человек подключается там, где риск, а вся система заточена на то, чтобы ошибку было дёшево заметить и откатить.

Ниже — полный перевод. В конце — мой фактчек (что подтверждается, а что только на слово) и короткий план внедрения для вашей команды.

Мы уже говорили, что около 90% кода Claude Code пишет сам Claude. Как ревьюить код в таком объёме? Кто-нибудь вообще ещё читает код? И если что-то ломается — кто это ловит?

Этот пост — про то, как устроено код-ревью в команде Claude Code и как оно менялось. С июня по сентябрь число влитых пулл-реквестов в кодовую базу Claude Code выросло больше чем вдвое, а доля откатов упала больше чем на 40%.

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

Переосмысление задачи код-ревью

Когда код пишут агенты, число изменений растёт быстро. В монорепозитории Anthropic (общем репозитории компании) объём изменений в день вырос примерно с 2 500 в мае до более чем 30 000 в сентябре этого года (мы писали об этом отдельно).

Claude Code живёт в отдельном репозитории, не в монорепо, но давление там похожее. При такой скорости ручное построчное ревью почти невозможно.

У код-ревью две работы:

1. Найти и починить проблемы до релиза
2. Создать общий контекст и понимание кодовой базы в команде

Этот текст в основном про первую работу, ко второй вернёмся в конце.

Наша позиция: вопрос «человек прочитал код?» — неточный заменитель настоящего вопроса: «что может пойти не так с этим изменением и какая проверка — автоматическая или человеческая — правильная, чтобы это поймать?»

Этот вопрос изменил и то, когда происходит ревью. Раньше ревью было воротами в конце пути: пишем код, открываем PR, ждём коллегу.

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

Дефицитный ресурс: время и внимание людей

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

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

Цель: большинство пулл-реквестов в репозиториях Claude Code (CLI, десктопное и веб-приложения, мобильные приложения) вливается при участии максимум одного человека, и это может быть сам автор — без роста откатов и инцидентов. Чтобы мерить человеческое время, мы считаем человеческие апрувы на PR (медиану и 95-й перцентиль), человеческие комментарии и сколько PR ждёт человека. Доля откатов и инцидентов — ограничитель: если они растут, мы не сэкономили время, а просто передвинули его.

Жизнь одного изменения

Типичное изменение — с ноутбука инженера или из Claude-сессии в Slack — проходит несколько слоёв ревью.

Иллюстрация: проверки пулл-реквеста сверху вниз. До PR работу проверяет сам автор с агентом. На каждом PR: обязательный CI, ревью кода и ревью безопасности от Claude — всё автоматически, затем одобрение по уровню риска, где решает человек. Дальше очередь слияния; после слияния — фича-флаг, который сначала включают внутри компании, затем постепенный релиз и последний шаг: наблюдать, чинить на ходу или откатывать.

Большая часть пути автоматизирована; внимание человека идёт туда, где риск

Слой за слоем

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

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

1. Работа проверяется до того, как её увидят чужие глаза

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

Перед открытием PR многие из нас прогоняют пару внутренних скиллов (готовых сценариев для Claude): один ищет баги, второй упрощает дифф, третий проверяет поведение от начала до конца. Изменения интерфейса дополнительно сверяются с нашими гайдлайнами по дизайну.

Борис Черни, создатель Claude Code, назвал привычку давать Claude способ проверить свою работу вероятно, самой важной для хорошего результата. По его оценке, это улучшает итог в два-три раза:

«Проверка в каждой области выглядит по-своему. Это может быть просто запуск bash-команды, прогон тестов или проверка приложения в браузере или симуляторе телефона».

Если автоматический ревьюер помечает одно и то же снова и снова, мы чиним источник: в скилле, правилом линтера или обновлением инструкций:

• CLAUDE.md рассказывает Claude, что за проект: стек, конвенции, цели и не-цели. Его читает каждое ревью, поэтому в большой кодовой базе мы держим его коротким и ссылаемся из него на другие документы. Ревьюер помечает и код, нарушающий конвенции из CLAUDE.md, и изменения, из-за которых строка в нём устарела.
• REVIEW.md, который пишут владельцы кода, объясняет ревьюеру, что важно в их части кодовой базы. Мы отдельно проверяем, следует ли ревьюер этому файлу. Хорошие короткие: они говорят, как выглядит поломка в этом репозитории (для документации — «врёт», для конфигов — «маршрутизирует не туда»), ограничивают число мелких придирок, перечисляют пути, которые можно не читать, и требуют доказательство — файл и строку, а не догадку по названию. Просят и резюме, которое начинается с числа проблем и прямо говорит, когда исправлять нечего.

2. ИИ-ревью на каждом пулл-реквесте

Каждый пулл-реквест до человеческого взгляда проходит ревью Claude. Он читает дифф в контексте целого репозитория и заявленной цели PR и спрашивает: решает ли изменение свою задачу, вписывается ли в систему, ломает ли что-то ещё?

На исправлении бага он проверяет, что найдена первопричина. Публичная версия — Code Review for Claude Code — теперь общедоступна на тарифах Team и Enterprise, а /code-review локально запускает облегчённый вариант.

Когда мы запускали исследовательскую версию, доля внутренних PR с содержательными комментариями ревьюера выросла с 16% до 54%. Большинство PR длиннее 1000 строк получают находки, большинство маленьких возвращаются чистыми. Админы выбирают для каждого репозитория режим Quick, Standard или Deep. Deep оправдан там, где цена пропущенного бага выше, чем дополнительное время ревью.

Прежде чем попасть к человеку, находки проверяют другие агенты. Несколько агентов параллельно ищут баги. Затем отдельная группа голосует по каждой находке, и она публикуется, только если достаточно агентов считают её настоящей. Находки про стиль, диагностику или «прибраться» отбрасываются. Эти фильтры мы прогнали A/B-тестом на собственных PR, прежде чем оставить. Оставшееся приходит комментариями прямо в коде, отсортированными по серьёзности. У каждого метка Important, Nit или Pre-existing, чтобы баг, который PR не вносил, не выглядел виной автора.

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

3. Ревью безопасности с правом вето

У безопасности своё автоматическое ревью. PR не вольётся, пока открыта хоть одна находка из ревью багов или ревью безопасности. Либо чинишь, либо закрываешь тред коротким объяснением — так снимается ложное срабатывание.

Если следующий коммит чинит проблему, находка закрывается сама. То же можно настроить у себя: опенсорсный GitHub Action для security-ревью или команда /security-review. Настройка описана в статье про автоматические проверки безопасности в Claude Code.

4. Автоматические проверки, которые блокируют

Обычный набор: линтер, проверка типов, тесты на всех платформах и сборка. (О том, как мы масштабировали CI под такой объём, мы писали отдельно.) Типичный PR для CLI прогоняет десятки проверок, прежде чем его увидит человек. Шаблон PR спрашивает, как изменение тестировалось и как его откатить. Claude может заполнить это сам, но подписывается человек, который попросил изменение.

5. Человеческое одобрение, масштабируемое по риску

Правка в документации и изменение автообновлятора несут разный риск — и получают разное ревью.

Уровень задаёт изменение, а не автор. Классификатор читает изменение и выбирает уровень риска. Второй классификатор спрашивает, не нужен ли этому конкретному изменению дополнительный человек, даже если уровень говорит, что не нужен. Некоторые пути всегда требуют человека: всё, что владельцы объявили чувствительным, и любые файлы CI-workflow.

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

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

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

6. Очередь слияния, флаги и постепенный релиз

Очередь слияния заново прогоняет все проверки поверх свежего main с вашим изменением, поэтому два PR, которые проходят по отдельности, не могут вместе сломать main. Новое поведение обычно вкатывают за флагом (выключателем, который включают и выключают без релиза) сначала сотрудникам Anthropic — их активное использование часто вскрывает регрессии раньше пользователей. Публичные релизы сначала идут в канал latest, канал stable отстаёт.

7. Быстро заметить, быстро откатить

Часть ошибок всё равно проскочит, поэтому последний слой — про скорость обнаружения. Флаги выключаются без деплоя. У Claude Code есть еженедельное дежурство, и разбор каждого инцидента спрашивает: какой слой должен был это поймать?

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

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

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

Процесс ревью постоянно крутится в цикле улучшений.

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

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

Экзаменационный набор растёт с каждым инцидентом, и каждое изменение ревьюера оценивается по всем кейсам.

Шум меряем по тому, что люди делают с комментариями. Ловить больше багов просто, если не смущает куча ложных тревог, — значит, нужен контроль. Каждый комментарий ревьюера мы раскладываем по реакции человека на PR: починил; сказал, что неверно; сказал, что поведение намеренное; решил, что неважно. Ещё мы гоняем ревьюера на заведомо чистых PR и считаем, как часто он сообщает то, что могло подтолкнуть кого-то к вредному изменению. Наш приоритет записан: сначала ловить настоящие баги, во вторую очередь сокращать круги ревью.

Шум дороже, когда автор — агент. Человек отмахнётся от придирки за секунды. Агент её чинит — а это ещё один коммит и ещё один круг ревью.

Ревью должно сходиться. Агент-автор и агент-ревьюер могут гонять друг друга бесконечно. Один PR для CLI за ночь прошёл больше пятидесяти кругов ревью и правок, пока автор его не остановил.

Когда мы прогнали git blame по тому, что ревьюер продолжал помечать, около 59% оказалось кодом, стоявшим там ещё с первого прохода. Ревьюер редко находил новые баги — он находил по несколько старых за каждый круг.

Себе мы навредили сами. Мы привыкли гонять несколько кругов по умолчанию: каждый проход что-нибудь да находит. На рискованном изменении это оправдано, но не на каждом PR. Теперь команда отслеживает число кругов до прохода наряду с полнотой поиска и переделала повторное ревью:

• Лимит кругов. После трёх кругов ревьюер просит автора остановиться и пересмотреть подход.
• Повторное ревью — только по диффу после первых нескольких проходов.
• Помечать класс бага, чтобы автор починил все экземпляры, а не одну строку.
• Без повторов уже отправленных находок.

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

Иллюстрация: до и после работы над сходимостью — PR, проходящие за один круг ревью и правок, выросли с 65% до 78%; PR, требующие пяти и более кругов, упали с 8,9% до 1,5%; среднее число ревью до прохода упало с 2,08 до 1,32.

Меньше кругов ревью на внутренний PR после изменений

Где человек остаётся в процессе

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

• Стоит ли это вообще делать? Направление, вкус, объём. Одна команда, объявившая свой узок в ревью решённым, всё равно оставила человеческое ревью для изменений извне команды — чтобы кто-то спросил: «а надо ли это вообще?»
• Рискованный код: биллинг, автообновлятор, CI-workflows.
• Архитектура, задающая паттерн, который другие будут копировать.
• Чтение доказательств. Вывод тестов, команда, которая запускалась, и что она вернула, скриншот, находки ревьюера. Если не можешь сказать, что проверки могли пропустить, проси настоящее ревью, а не быстрый апрув.
• Ответственность за результат. За каждое вышедшее изменение отвечает человек — кто бы ни печатал код.

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

Люди сместились с чтения каждого диффа на решения, в которых машины плохи

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

Вторая работа код-ревью всегда была в распространении понимания кодовой базы. Читая дифф коллеги, ты узнаёшь, что изменилось и как детали соединяются. Если машины читают большую часть, как кто-нибудь выучит код?

Формального процесса у нас нет. Никто в команде не держит в голове полную модель Claude Code, и мы не считаем, что кому-то это нужно. Когда кто-то хочет понять часть кодовой базы, он просит Claude написать объяснение ровно этого куска. Это занимает минуты и отражает код в его сегодняшнем виде.

Иллюстрация под заголовком «Если машины читают большую часть, как кому-то выучить код?»: слева сетка, изображающая кодовую базу, выделен фрагмент — управляемые настройки (managed settings), которые нужно понять; полной картины нет ни у кого в голове. Стрелка «спроси Claude ровно про этот кусок» с примером вопроса «как Claude Code достаёт managed settings?» ведёт к двум результатам: Claude пишет объяснение, которое занимает минуты и отражает код на сегодня; а для кого-то Claude собирает небольшой артефакт, который визуализирует эту часть кода и объясняет её так, как этому человеку удобно учиться. Внизу: построчное чтение тривиальных диффов учит почти ничему, объяснение модуля, который ты собираешься менять, — многому.

Некоторые идут дальше и просят Claude собрать небольшой артефакт, который визуализирует эту часть кода и учит её так, как этому человеку удобно.

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

«Залил — отвечай» («you land it, you own it»)

Если ты вкатил маленькое или среднее изменение и что-то всё равно сломалось — по норме команды чинить обычно тебе. Несколько вещей не дают этому кончиться плохо:

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

Ответственность к тому же разделена. Большая часть команды работает в открытых каналах, где любой видит, что строят другие, может подхватить тред или направить Claude на дыру, — и фидбек приходит и от людей, не владеющих кодом. Эта открытость — большая часть того, почему качество держится высоким без ворот на каждой строчке.

Когда направление меняется

Агенты удешевили старт, поэтому часть работы вкатывать не стоит. Обычно кто-то в канале спрашивает «зачем», указывает на прежнее решение или предлагает путь попроще — и автор закрывает или перекраивает PR.

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

Как внедрить этот процесс у себя

Большинство деталей уже доступны сегодня.

До пулл-реквеста

• Дай агенту проверки, которые он может сам запустить, перечисли их в коротком CLAUDE.md, добавь hooks (автозапуск форматтеров и линтеров).
• Гоняй /code-review и /security-review локально — или субагента-ревьюера с чистым контекстом.
• Заведи REVIEW.md и переноси туда повторяющиеся комментарии ревью.

На каждом пулл-реквесте

• Требуй CI и добавь в шаблон PR поля «Тестирование», «Риск» и «Как откатить».
• Подключи ИИ-ревьюер (Code Review for Claude Code или Claude Code GitHub Action) на один репозиторий, пару недель настраивай REVIEW.md, потом расширяй.
• Добавь автоматическое ревью безопасности и требуй закрытия всех тредов до слияния.
• Соразмеряй усилия по риску: быстрый проход на рутине, глубокий там, где пропущенный баг дорог (Quick, Standard или Deep в Code Review).
• Ограничь число кругов; после первых — повторное ревью только по новому диффу.

Одобрение

• Опиши уровни риска от изменения, а не от автора; стартуй строго, ослабляй по фактам.
• Облегчённые пути держи для доверенных авторов.
• Используй CODEOWNERS и защиту веток: auth, биллинг, CI и релизные workflows, установщики — всегда через человека.
• Никогда не позволяй боту заменить обязательного человека; снимай апрувы при новых коммитах.

Слияние и после

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

Куда это движется

В анонсе Code Review сказано: одобрить пулл-реквест — по-прежнему решение человека; продукт публикует находки, а не апрувы. Собственные репозитории Anthropic идут дальше: владельцы решают, какие низкорисковые изменения вливаются только по автоматическим проверкам, и эта граница сдвигается.

Когда ревью что-то пропустило, мы спрашиваем: чего у модели не было перед глазами? — и чиним это в CLAUDE.md, в скилле или новой проверке. Цель не менялась: меньше человеческого времени на изменение и не больше откатов, чем раньше.

Если ваша команда разрешает агентам открывать пулл-реквесты, поделитесь: какие проверки вы автоматизировали, какие ещё требуют человека и что, по-вашему, мы поняли не так.

Спасибо Эмме Уэбб, Майклу Сегнеру и Эми Ротерем за ревью.

Фактчек

• «Claude пишет около 90% кода Claude Code». Эту цифру команда и Борис Черни называли и раньше в публичных выступлениях. Но это самопризнание разработчика, независимой проверки нет и быть не может. Заявление не новое — оно согласуется с прошлыми публикациями Anthropic.
• Инструменты реальны. /code-review, /security-review, CLAUDE.md, hooks, субагенты, GitHub Action для security-ревью — существующие публичные возможности Claude Code, описанные в официальной документации. Проверяется за минуту.
• REVIEW.md — не встроенная фича. Такого файла с автоматическим поведением в документации Claude Code нет. Это командная договорённость Anthropic: работает, потому что команды сами учат ревьюер этот файл читать. Полезная практика, но «из коробки» её нет.
• Статус «GA на Team и Enterprise». Исследовательская версия Code Review действительно существовала публично. А вот заявление об общедоступности именно на этих тарифах мне подтвердить нечем — даты публикации статьи выходят за пределы того, что я могу надёжно проверить, так что сверяйте с актуальной документацией.
• Все цифры — внутренние. 2 500 → 30 000 изменений в день, рост PR вдвое, минус 40% откатов, 16% → 54%, 59% старых находок, 65% → 78%, 8,9% → 1,5%, 2,08 → 1,32, «50+ кругов за ночь» — всё замерено самим Anthropic на своих репозиториях и сослано на их же посты. Проверить снаружи нечем. Отдельно: «откаты упали на 40%» — наблюдение, а не доказательство причинности, хотя команда связывает это со своим процессом.
• «В 2–3 раза лучше» от Черни — личная субъективная оценка, не измерение.
• Классификаторы риска, доверенный список авторов, голосование агентов по находкам — внутренние системы Anthropic, описание только со слов команды. Механика при этом повторяет стандартные средства GitHub: защита веток, снятие устаревших апрувов, CODEOWNERS — это всё существует и работает как описано.
• Соавторство Addy Osmani — Osmani публично известен как руководитель инженерии Chrome в Google. Его имя среди авторов блога Anthropic подтвердить нечем, оставляю как заявлено в статье.
• Общая кухня не нова. Очередь слияния, фича-флаги, поэтапный релиз, дежурства и разборы инцидентов — стандартная инженерная практика. Новая часть здесь — ИИ-ревью перед человеком и фильтрация находок голосованием агентов.

Как применить

Кому это нужно в первую очередь: командам, где агенты уже открывают пулл-реквесты, и тем, кто настраивает процесс. Если вы только пробуете Claude Code — начните с пунктов 1–4.

1. Укороти CLAUDE.md. Стек, конвенции, цели и не-цели — коротко, подробности в отдельных документах со ссылками. Этот файл читает каждое ревью.
2. Заведи REVIEW.md. Опиши, как выглядит поломка именно в вашем репозитории, ограничь число придирок, перечисли пути, которые можно не читать, потребуй в качестве доказательства файл и строку.
3. Дай агенту проверку. Тесты, сборка, скриншоты — проси показывать вывод, а не «готово». Автозапуск форматтеров и линтеров — через hooks.
4. Прогоняй перед PR /code-review и /security-review локально. Для репозитория на GitHub подключи security GitHub Action.
5. Обнови шаблон PR: поля «Как тестировалось», «Риск», «Как откатить».
6. Собери обязательные проверки: CI плюс правило «все треды ревью закрыты до слияния» в защите веток.
7. Опиши уровни риска. Через CODEOWNERS и защиту веток сделай так, чтобы auth, биллинг, CI-файлы и релизные workflows всегда требовали человека. Апрув бота никогда не заменяет человека, а при новых коммитах апрувы снимаются.
8. Ограничь круги ревью. После трёх кругов — стоп и пересмотр подхода; повторное ревью — только по новому диффу; находки не дублировать. Иначе агент-автор и агент-ревьюер будут крутить друг друга всю ночь.
9. Превращай инциденты в экзамен. Собери пулл-реквесты, вызвавшие инциденты и откаты, и регулярно проверяй на них промпт своего ревьюера — особенно после смены модели или инструментов.
10. Меряй время людей. Человеческие апрувы на PR и сколько PR ждёт человека — как основные метрики; доля откатов и инцидентов — как ограничитель снизу. Если откаты растут, ты не сэкономил время, а передвинул его.

Источники

1. https://claude.dev/blog/solving-code-review-at-anthropic/