Как Anthropic ревьюит код, который почти целиком пишет Claude 
Claude пишет около 90% кода Claude Code. При этом с июня по сентябрь количество влитых PR выросло больше чем вдвое, а доля откатов снизилась более чем на 40%, по данным команды.
Секрет не в том, что модель стала безошибочной. Они перестроили процесс вокруг другой идеи:
Не «человек прочитал каждую строку?», а «что здесь может сломаться и какая проверка это поймает?»
Вот что из этого можно забрать себе.
1. Вместо «готово» требуйте доказательство
До PR агент должен сам запустить тесты, сборку или проверить интерфейс и показать результат. Затем diff смотрит отдельный субагент со свежим контекстом.
2. Заведите короткий REVIEW.md
Не абстрактное «проверь всё», а конкретные правила вашего проекта:
- Что считается поломкой: документация врёт, конфиг отправляет запросы не туда, кеш возвращает устаревшее.
- Какие директории пропускать и сколько мелких замечаний допустимо.
- Каждое замечание подтверждать файлом и строкой, а не догадкой по названию функции.
- Если исправлять нечего, прямо так и писать.
Повторяющееся замечание лучше превратить в lint-правило, инструкцию или проверку, а не обсуждать заново в каждом PR.
3. Ревьюер тоже нуждается в ревью
У Anthropic несколько агентов ищут баги параллельно, а другая группа проверяет находки. Замечание попадает к человеку, только если достаточно проверяющих согласны, что проблема реальна.
4. Бесконечное AI-ревью - реальная ловушка
Один PR у них прошёл больше 50 раундов исправлений за ночь, пока человек это не остановил. Около 59% кода, на который ревьюер продолжал жаловаться, присутствовало ещё при первом проходе: он просто находил старые проблемы порциями.
Что поменяли:
- После трёх раундов предлагают остановиться и пересмотреть подход.
- После первых проходов проверяют только новый diff.
- Просят указывать весь класс ошибки, чтобы исправить все похожие места сразу.
- Не повторяют уже опубликованные замечания.
5. Человека подключают по риску
Для доверенных авторов низкорисковые изменения могут проходить без отдельного человеческого подтверждения, если автоматические проверки зелёные. Обычные изменения требуют одного человека, самые рискованные - двух.
При этом команда честно признаёт: автоматических механизмов, которые ужесточают требование подтверждения при росте инцидентов, у них пока нет. Это пока не история про включили автомердж и забыли.
6. Проверяйте ревьюера на собственных прошлых авариях
Они собрали PR, которые приводили к инцидентам, подтвердили реальные баги и ежедневно прогоняют ревьюер по этому набору.
Очень прикладная идея: поменяли модель, промт или инструменты - проверьте, ловит ли новая версия ошибки, на которых вы уже обожглись.
Главная мысль: экономить нужно не количество минут на ревью, а суммарное время человека - включая разгребание последствий. Если ревью ускорилось, а ошибок стало больше, вы просто перенесли работу на потом.