Как команда Claude Code делает ревью кода: 7 слоёв и настройка

Команда Claude Code почти не читает диффы построчно. По посту Anthropic «How the Claude Code team does code review» от 15 октября 2026 года каждое изменение проходит семь слоёв: самопроверку агента ещё до PR, ИИ-ревью каждого PR, отдельное security review, CI, одобрение людьми по уровню риска, очередь слияния с флагами и быстрый откат. Сколько людей должны одобрить PR, решает само изменение, а не автор: документации и коду за флагом не нужен никто, обычной правке нужен один человек, самому опасному коду — двое. Claude пишет около 90% кода Claude Code, и с июня по сентябрь 2026 года слитых PR стало более чем вдвое больше, а доля откатов упала более чем на 40%, хотя абсолютных чисел Anthropic не публикует.

Перенести схему к себе можно по частям и на любом плане. Правила, которые должны соблюдаться при каждом ревью, пишите в CLAUDE.md: локальная команда /code-review читает его, а REVIEW.md пропускает, и прогон на демо-репозитории 23 октября 2026 года это подтвердил. Затем добавьте в шаблон PR поля «Как проверено», «Риск» и «Как откатить», закройте платёжный код, авторизацию, CI-воркфлоу и инсталляторы через CODEOWNERS и защиту веток, а если PR пишет агент и проверяет агент, ограничьте ревью тремя раундами.

Главное исключение касается блокировки. Управляемый сервис Code Review на планах Team и Enterprise не одобряет и не блокирует PR: он оставляет замечания и нейтральную проверку на GitHub. Запрет слияния при открытых замечаниях — это настройка репозиториев самой Anthropic, и в своём репозитории её нужно собрать отдельно.

Семь слоёв ревью в Claude Code и чем заменить каждый у себя

Ни один слой не ловит всё, поэтому Anthropic ставит их друг за другом и держит под ними быстрый откат. Большая часть пути автоматизирована, а внимание человека уходит туда, где выше риск. Ниже слои в порядке прохождения, по посту Anthropic о ревью кода в команде Claude Code в блоге claude.dev, и то, что из публичных инструментов ближе всего к каждому из них.

Самый дешёвый слой — первый, и Anthropic вкладывается в него сильнее всего: большинство изменений Claude проверил и исправил хотя бы раз ещё до того, как человека просят посмотреть. Борис Черни, создатель Claude Code, оценивает, что возможность проверить свою работу делает итог Claude «в два-три раза лучше»; это его оценка, а не замер. Повторяющиеся замечания ревьюера команда устраняет у источника: правилом линтера, правкой скилла или строкой в CLAUDE.md и REVIEW.md.

У слоя 2 есть деталь, которую стоит перенести без изменений. Каждое замечание помечено как Important (ошибка, которую надо исправить до слияния), Nit (мелочь, не блокирует) или Pre-existing (ошибка, которая была в коде до этого PR). Последняя метка нужна, чтобы старый баг не выглядел виной автора и не тормозил его PR.

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

Сколько одобрений нужно PR: 0, 1 или 2 по уровню риска

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

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

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

Что значат 90%, «вдвое больше PR» и «−40% откатов»

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

Две строки стоит прочитать вместе. Если PR стало вдвое больше, а доля откатов упала на 40%, то абсолютное число откатов могло даже вырасти: 2 × 0,6 = 1,2 от прежнего. Точно посчитать нельзя, потому что Anthropic даёт только нижние границы («более чем»), но вывод «откатов стало меньше» из этих цифр не следует. Сама команда страхуется от подмены цели: основная метрика у неё — время людей (одобрения на PR по медиане и 95-му перцентилю, комментарии, ожидание человека), а доли откатов и инцидентов служат ограничителем. Если они растут, время людей не сэкономлено, а перенесено на исправления.

Цифру 30 000 в обсуждении поста на Hacker News не раз приняли за число PR в Claude Code. Это изменения во всём монорепозитории Anthropic, где Claude Code нет.

Читает ли /code-review файл REVIEW.md: проверка 23 октября 2026 года

Нет. Локальная команда /code-review следует правилам из CLAUDE.md, в том числе в неинтерактивном запуске с -p, а REVIEW.md не читает: по документации Claude Code о локальном ревью через /code-review, этот файл настраивает только управляемый сервис Code Review на GitHub. Поэтому одно и то же правило может работать в облачном ревью PR и молча не работать при проверке на ноутбуке.

23 октября 2026 года это проверили на маленьком демо-репозитории: macOS, Claude Code 2.1.309, команда claude -p "/code-review low" --output-format json, один аккаунт. В ветке add-discount добавлена функция скидки с четырьмя заложенными проблемами:

// Apply a percentage discount to the first `limit` items only.
// TODO: support coupon codes
function discountedTotal(items, percent, limit) {
  let total = 0;
  for (let i = 0; i <= limit; i++) {            // (a) на одну позицию больше
    const line = items[i].priceCents * items[i].qty;
    total += line * (1 - percent / 100);        // (c) деньги во float
  }
  for (let i = limit; i < items.length; i++) {  // (b) позиция limit считается дважды
    total += items[i].priceCents * items[i].qty;
  }
  return total;
}

Комментарии с буквами добавлены здесь для читателя, в проверяемом коде их не было. В CLAUDE.md репозитория было правило «Money is always stored and computed as integer cents», а в REVIEW.md — правило Any comment containing "TODO" in a changed line is an Important finding. Четвёртая проблема (d) — строка // TODO, которую по REVIEW.md нужно отмечать как Important.

Первый запуск занял 17,2 секунды и, по оценке CLI, $0,19. Он нашёл обе ошибки в циклах (при limit >= items.length функция падает с TypeError, а позиция с индексом limit учитывается дважды) и расчёт денег во float со ссылкой на правило из CLAUDE.md, но строку с TODO пропустил. Во втором запуске то же правило про TODO дописали в CLAUDE.md, больше ничего не меняя: 8,7 секунды, $0,09, те же три находки и четвёртая: строка с TODO отмечена как Important, потому что, по правилам проекта, такие изменения не сливаются. Отчёты пришли на китайском только потому, что Claude Code на этой машине настроен отвечать по-китайски; к самой команде это отношения не имеет.

У проверки узкие границы: по одному запуску на каждое условие, уровень low (он выдаёт только самые уверенные находки), одна машина, а вывод модели от запуска к запуску различается. Стоимость — поле total_cost_usd, то есть оценка CLI по ценам API, а не счёт. Управляемый Code Review, ultrareview и /security-review не запускались; всё, что о них сказано ниже, взято из документации Anthropic. Практический вывод: правила, которые должны работать и локально, и в облаке, держите в CLAUDE.md, а в REVIEW.md оставляйте то, что касается только ревью PR в сервисе.

Что повторить на своём плане: /code-review, ultrareview и Code Review

На любом плане доступен локальный /code-review; на Pro и Max к нему добавляется облачный ultrareview; управляемый Code Review, который Anthropic использует у себя, есть только на Team и Enterprise. Четвёртый путь — Claude в вашем собственном CI через GitHub Actions — открыт всем, у кого есть API-ключ.

Если выбирать по плану, картина такая. Разработчику-одиночке на Pro или Max хватит /code-review перед каждым PR и ultrareview на крупных изменениях, пока не кончатся бесплатные запуски. Команде на Team или Enterprise имеет смысл включить Code Review на одном репозитории и настраивать его через REVIEW.md. Если плана Team или Enterprise нет, а ИИ-ревью нужно на каждом PR, ближе всего к схеме Anthropic GitHub Action с Claude в CI плюс локальный /code-review у каждого разработчика.

Блокирует ли Code Review слияние PR и как это настроить

Сам по себе нет. По документации Claude Code о сервисе Code Review, ревью никогда не одобряет и не блокирует PR: оно оставляет комментарии к строкам, сводку и проверку «Claude Code Review», которая не завершается ошибкой даже при найденных багах. Решение о слиянии остаётся за командой. Фраза из поста «PR не сливается, пока открыто хоть одно замечание» описывает то, как Anthropic настроила собственные репозитории.

Повторить это можно двумя способами. Простой — включить в защите ветки обязательное закрытие всех обсуждений перед слиянием (Require conversation resolution before merging): замечания Code Review — это обсуждения в PR, и пока их не исправят или не закроют с причиной, кнопка слияния будет недоступна. Точный — читать счётчики находок в своём CI. Последняя строка подробностей проверки Code Review — HTML-комментарий вида <!-- bughunter-severity: {"nit":1,"normal":2,"pre_existing":0} -->, где normal — число замечаний Important. Документация предлагает сначала взять ID проверки «Claude Code Review» из списка проверок коммита, а затем прочитать счётчики так (этот скрипт в прогоне 23 октября не запускался):

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID --jq '
  (.output.text | split("\n") | last
    | scan("^<!-- bughunter-severity: (.*) -->$")[0] | fromjson)?
  // error("no severity line")'

Job должен падать, если normal больше нуля, и отдельно — если заголовок проверки начинается с «Code review not repeated»: тогда сервис сохранил прежний результат с открытыми Important, а строки со счётчиками нет. Если заголовок заканчивается на «no new changes», новых изменений нет и job можно пропустить. Если строка отсутствует по другой причине (ревью упало, истекло по времени, отменено), это значит «вердикта нет», а не «ноль находок», и пропускать такой PR по умолчанию нельзя. Подробности — в разделе документации Code Review о чтении результата из скрипта.

Как выстроить ревью кода с Claude Code в команде: 6 шагов

Пост Anthropic заканчивается собственным чек-листом. Ниже он собран в порядок, в котором его удобно внедрять: от того, что сработает уже сегодня на одном ноутбуке, до правил одобрения для всей команды.

1. Сократите CLAUDE.md и дайте агенту проверки, которые он может запустить. Перечислите команды тестов и сборки, ключевые соглашения проекта и ссылки на остальные документы; файл загружается при каждом ревью, поэтому в большой кодовой базе его держат коротким. Когда именно Claude Code подгружает эти файлы, разобрано в статье «Память Claude Code в 2026: CLAUDE.md, auto memory и когда нужен плагин». Форматтеры и линтеры запускайте через hooks, а не просьбой в промпте, как описано в статье «Claude Code: чем отличаются hooks, skills и слэш-команды».

   markdownКопировать

   # Правила проекта
   - Проверка изменений: `npm test` и `npm run build`; покажи вывод, а не «готово».
   - Деньги храним и считаем только в целых копейках.
   - Изменения с TODO не сливаем: отмечай их как Important.
   - Архитектура: docs/architecture.md; API: docs/api.md.

2. Перед PR запускайте /code-review и /security-review локально. Уровень low выдаёт только самые уверенные находки, более высокие расширяют охват; последний введённый уровень /code-review запоминает и использует дальше. С --fix Claude сразу вносит исправления в рабочее дерево, с --comment публикует замечания в PR на GitHub. /simplify ищет только то, что можно упростить, и сам применяет правки, а с какого скилла начинать вообще, объясняет статья «Лучшие скиллы для Claude Code: что выбрать первым и как установить».

3. Добавьте в шаблон PR три поля. У Anthropic шаблон спрашивает, как изменение проверено и как его откатить; Claude может заполнить его сам, но подписывается под ним человек, который попросил об изменении.

   markdownКопировать

   ## Как проверено
   Какие команды запускались и что вернули (вывод, скриншот).
   
   ## Риск
   Низкий / средний / высокий и почему; какие чувствительные пути затронуты.
   
   ## Как откатить
   Флаг, который выключает изменение, или команда отката.

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

   Копировать

   # .github/CODEOWNERS
   /.github/workflows/  @your-org/platform
   /src/auth/           @your-org/security
   /src/billing/        @your-org/billing
   /installer/          @your-org/release

5. Подключите ИИ-ревьюер к одному репозиторию и несколько недель настраивайте REVIEW.md. На Team и Enterprise это Code Review: владелец организации (роль Owner) включает его в Admin settings → Claude Code, устанавливает Claude GitHub App и выбирает репозитории; для пилота документация советует режим «Once after PR creation» или ручной запуск по комментарию @claude review. Глубину выбирайте по цене пропущенной ошибки: Quick для рутинного кода, Standard по умолчанию, Deep там, где пропущенный баг дороже лишних минут ревью. Остальным подойдёт Claude Code GitHub Action. Хороший REVIEW.md, по опыту Anthropic, короткий: он говорит, как выглядит провал именно в этом репозитории, ограничивает число мелких замечаний, перечисляет пути, которые не нужно проверять, требует файл и строку как доказательство и просит сводку, которая начинается с числа находок.

   markdownКопировать

   # Инструкции для ревью
   ## Что здесь значит Important
   Только то, что ломает поведение, раскрывает данные или мешает откату.
   Стиль и именование — максимум Nit.
   ## Ограничение мелочей
   Не больше трёх Nit за ревью.
   ## Не проверять
   - Сгенерированный код в src/gen/ и файлы *.lock
   - То, что уже ловит CI: линтер, форматирование, типы
   ## Доказательства и сводка
   Каждое утверждение о поведении — со ссылкой файл:строка.
   Сводку начинай с числа находок; если исправлять нечего, так и напиши.

   Code Review читает REVIEW.md из базовой или основной ветки, а не из изменений самого PR, поэтому правку этого файла сначала нужно слить. Понижение серьёзности, исключение путей и лимит на Nit сервис выполняет, только если корневой REVIEW.md лежит в защищённой основной ветке, как сказано в документации о настройке Code Review через REVIEW.md и CLAUDE.md.

6. После слияния: очередь, флаги, поэтапный релиз и метрики. Очередь слияния (merge queue) не даст двум по отдельности зелёным PR сломать main; флаги и поэтапные релизы позволяют откатить ошибку за минуты. Инциденты и откаты складывайте в набор примеров, на котором заново проверяете ревьюер при каждой смене промпта, инструментов или модели. Измеряйте время людей (одобрения на PR, ожидание ревью) и следите, чтобы доля откатов и инцидентов при этом не росла.

Сколько стоит ИИ-ревью: от лимитов плана до кредитов организации

У трёх инструментов разная модель оплаты, и фиксированной цены за ревью нет ни у одного из них. Локальный /code-review расходует лимиты вашего плана или API-бюджет так же, как любая другая работа в сессии; на маленьком диффе в проверке 23 октября это были доли доллара. Ultrareview на Pro и Max даёт три бесплатных запуска один раз на аккаунт, они не обновляются, а дальше одно ревью обычно стоит от $5 до $25 в кредитах использования в зависимости от размера изменения; точную оценку показывает окно запуска, и без включённых кредитов платный запуск не стартует (документация Claude Code об ultrareview).

Управляемый Code Review оплачивается по расходу токенов через кредиты использования отдельно от лимитов плана, и счёт выставляется организации, а не автору PR. Цена ревью растёт с уровнем Quick, Standard или Deep, размером изменения, сложностью окружающего кода и числом находок, которые нужно перепроверить, а режим «After every push» умножает её на число пушей. Цифра «$15–25 за ревью», которая ходит по обзорам, относится ко временам research preview, и в нынешней документации о стоимости Code Review её нет. Чтобы оценить бюджет, документация предлагает пилот: задать месячный лимит расходов, включить несколько репозиториев в режиме «Once after PR creation» или вручную, посмотреть Average cost в Admin settings → Claude Code и умножить на число PR в месяц. Когда лимит или баланс кредитов заканчивается, ревью просто пропускается, и в PR появляется комментарий с причиной.

После выхода в GA 15 октября 2026 года большинство ревью Code Review занимает 6–10 минут вместо примерно 20 во время preview, а подходящие организации Enterprise до 15 января 2027 года могут получить не меньше $10 000 кредитов на Code Review, которые сгорают через 30 дней после активации (объявление Anthropic о выходе Code Review в GA). Как устроены сами кредиты использования и когда выгоднее перейти на Max, разобрано в статье «Стоимость дополнительного использования Claude: кредиты или Max».

Агент-автор и агент-ревьюер ходят по кругу: лимит в три раунда

Если PR пишет агент и проверяет агент, ревью может не сойтись никогда. Человек отмахивается от мелкого замечания за секунды, а агент его исправляет, что даёт новый коммит и новый раунд ревью. В Claude Code один PR в CLI за ночь прошёл больше пятидесяти раундов ревью и правок, пока автор его не остановил. Когда команда прогнала git blame по повторяющимся замечаниям, около 59% из них относились к коду, который был на месте ещё при первом проходе ревьюера: новых багов он почти не находил, а каждый раунд вытаскивал ещё несколько старых. После этого Anthropic ввела четыре правила, которые легко повторить в своём процессе:

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

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

Что остаётся людям, если код читают машины

Код по-прежнему читают люди, но не каждый дифф и не построчно. За людьми в команде Claude Code остаются решения, которые автоматическая проверка принять не может: стоит ли вообще это делать (направление, вкус, объём), рискованный код вроде биллинга, автообновления и CI-воркфлоу, архитектурные решения, которые другие будут копировать, и ответственность за результат, кто бы ни набрал код. Отдельная обязанность — читать доказательства: вывод тестов, команду и её результат, скриншот, замечания ревьюера. Правило из поста простое: если вы не можете сказать, что пропустили бы автоматические проверки, просите полноценное ревью, а не быстрое одобрение.

Второе назначение ревью — распространять знание кода по команде — Anthropic решает без формального процесса. Перед тем как менять часть кодовой базы, разработчик просит Claude написать объяснение именно этого фрагмента, иногда с небольшой визуальной схемой; работа в открытых каналах Slack показывает, кто что строит. Возражение о смене направления команда поднимает рано, в обсуждении, а не блокирующим комментарием к готовому PR. Действует и норма «слил — отвечаешь»: автор небольшого изменения обычно сам чинит то, что сломалось, но это не поиск виноватых, потому что изменения маленькие, обратимые, а строгость проверки растёт вместе с ценой ошибки.

Одно из сомнений в обсуждении поста на Hacker News — как можно сливать документацию, которую никто не прочитал. В схеме Anthropic такое возможно только на низком уровне риска, только для доверенных авторов и только после зелёного автоматического ревью и security review, а хороший REVIEW.md для документации, по совету поста, определяет провал как «она врёт», то есть ревьюер проверяет, что текст соответствует коду. Если для вашей команды этого мало, начните с одного обязательного человека на каждый PR и снижайте планку только там, где откаты и инциденты подтверждают, что автоматических слоёв хватает.