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

> Около 90% кода Claude Code пишет Claude, а ревью делают семь автоматических слоёв; людей нужно 0, 1 или 2 по риску изменения. Что из этого есть на вашем плане.

- URL: https://blog.laozhang.ai/ru/posts/claude-code-team-code-review
- Published: 2026-10-23
- Updated: 2026-10-23
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ru/about)
- Topic: Claude Code
- Tags: Claude Code, Ревью кода, Code Review, CLAUDE.md, Разработка

---
Команда 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](https://claude.dev/blog/solving-code-review-at-anthropic/), и то, что из публичных инструментов ближе всего к каждому из них.

| Слой | Что ловит и кто решает | Чем заменить у себя |
| --- | --- | --- |
| 1. Проверка до PR | Агент запускает тесты, сборку или сравнивает скриншот с макетом и показывает вывод; затем субагент со свежим контекстом читает дифф. Решает автор | Короткий `CLAUDE.md` с командами проверки, hooks для форматтеров и линтеров, локальный `/code-review` |
| 2. ИИ-ревью каждого PR | Несколько агентов ищут ошибки параллельно, отдельная группа голосует за каждую находку; замечания про стиль отбрасываются. На каждое замечание нужно ответить: исправить или закрыть с причиной | Code Review (Team, Enterprise) или Claude Code GitHub Action в своём CI |
| 3. Security review | Отдельная автоматическая проверка безопасности; внутри Anthropic PR не сливается, пока открыто хоть одно замечание этого или предыдущего слоя | Команда `/security-review` или GitHub Action `anthropics/claude-code-security-review` плюс обязательное закрытие обсуждений |
| 4. CI | Линтер, проверка типов, тесты на всех платформах, сборка; у типичного PR в CLI десятки проверок | Обязательные проверки статуса в защите ветки |
| 5. Одобрение людьми | Классификатор выбирает уровень риска и число людей: 0, 1 или 2 | `CODEOWNERS` и защита веток; публичного аналога классификатора нет |
| 6. Очередь слияния и выкладка | Очередь заново прогоняет все проверки на `main` вместе с изменением; новое поведение сначала получают сотрудники Anthropic за флагом, затем канал `latest`, позже `stable` | Merge queue, feature flags, поэтапные релизы |
| 7. Обнаружение и откат | Флаги выключаются без деплоя, дежурство меняется раз в неделю, разбор инцидента выясняет, какой слой должен был поймать ошибку | Откат одной командой и дашборды откатов и инцидентов |

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

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

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

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

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

| Уровень риска | Примеры изменений | Сколько людей одобряют |
| --- | --- | --- |
| Низкий | Документация, тексты интерфейса, функции только для внутреннего использования, добавления за флагом | Никто, если автоматическое ревью и security review зелёные |
| Средний | Обычные изменения продукта, а также кэширование, автообновление, системные промпты | Один человек |
| Высокий | Самый рискованный код и небольшой набор путей, которым всегда нужны двое | Два человека |

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

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

![Схема одобрений PR в Claude Code: классификатор читает дифф и выбирает низкий, средний или высокий риск, от которого зависит 0, 1 или 2 человека](https://blog.laozhang.ai/posts/ru/claude-code-team-code-review/img/review-approvals-by-risk.webp)

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

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

| Цифра | Что именно измеряет | Оговорка |
| --- | --- | --- |
| Около 90% | Долю кода Claude Code, которую пишет Claude | Как считали и что входит в оставшиеся 10%, в посте не сказано |
| Слитых PR «более чем вдвое больше» | Число слитых PR в кодовой базе Claude Code, июнь → сентябрь 2026 года | Абсолютных чисел нет |
| Доля откатов «упала более чем на 40%» | Долю слитых PR, которые пришлось откатить | Это доля, а не число откатов; базовый период не опубликован |
| Более 30 000 изменений в день | Монорепозиторий Anthropic в сентябре (в мае было около 2 500) | Claude Code живёт в отдельном репозитории, к нему эта цифра не относится |
| С 16% до 54% | Долю внутренних PR с содержательными замечаниями ревью | Замер при запуске research preview в марте 2026 года, не после выхода в GA |

Две строки стоит прочитать вместе. Если 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](https://code.claude.com/docs/en/code-review-local), этот файл настраивает только управляемый сервис Code Review на GitHub. Поэтому одно и то же правило может работать в облачном ревью PR и молча не работать при проверке на ноутбуке.

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

```js
// 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 на этой машине настроен отвечать по-китайски; к самой команде это отношения не имеет.

![Итоги двух запусков /code-review: с правилом про TODO в REVIEW.md строка с TODO пропущена, с тем же правилом в CLAUDE.md отмечена как Important](https://blog.laozhang.ai/posts/ru/claude-code-team-code-review/img/todo-rule-review-md-vs-claude-md.webp)

У проверки узкие границы: по одному запуску на каждое условие, уровень `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-ключ.

| Инструмент | Где работает и кому доступен | Какие файлы правил читает | Как оплачивается | Может ли остановить слияние |
| --- | --- | --- | --- | --- |
| `/code-review` | В вашей сессии Claude Code, любой план | `CLAUDE.md`; `REVIEW.md` не читает | Из лимитов плана или по API, как остальная сессия | Нет, выдаёт отчёт; `--fix` вносит правки, `--comment` пишет замечания в PR |
| Ultrareview (`/code-review ultra`) | В облачной песочнице; нужен вход через аккаунт claude.ai, нет на Bedrock, Google Cloud Agent Platform, Microsoft Foundry и в организациях с ZDR или HIPAA | В документации ultrareview не описано | Pro и Max: 3 бесплатных запуска на аккаунт, затем кредиты использования | Нет, может опубликовать замечания в PR |
| Code Review | На инфраструктуре Anthropic для репозиториев GitHub; Team и Enterprise, включает владелец организации (роль Owner) | `CLAUDE.md` из корня и папок изменённых файлов, `REVIEW.md` из базовой или основной ветки | Кредиты использования, счёт организации, фиксированной цены нет | Только через ваш CI |
| Claude в своём CI (Claude Code GitHub Action, security review Action) | На ваших раннерах; любой, у кого есть API-ключ или доступ через облачного провайдера | То, что вы передадите в workflow | По API | Да, если job обязателен и падает при находках |

Если выбирать по плану, картина такая. Разработчику-одиночке на 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](https://code.claude.com/docs/en/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 октября не запускался):

```bash
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 о чтении результата из скрипта](https://code.claude.com/docs/en/code-review-pull-requests).

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

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

1. **Сократите `CLAUDE.md` и дайте агенту проверки, которые он может запустить.** Перечислите команды тестов и сборки, ключевые соглашения проекта и ссылки на остальные документы; файл загружается при каждом ревью, поэтому в большой кодовой базе его держат коротким. Когда именно Claude Code подгружает эти файлы, разобрано в статье «[Память Claude Code в 2026: CLAUDE.md, auto memory и когда нужен плагин](https://blog.laozhang.ai/ru/posts/claude-code-memory)». Форматтеры и линтеры запускайте через hooks, а не просьбой в промпте, как описано в статье «[Claude Code: чем отличаются hooks, skills и слэш-команды](https://blog.laozhang.ai/ru/posts/claude-code-hooks-slash-commands-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: что выбрать первым и как установить](https://blog.laozhang.ai/ru/posts/claude-code-best-skills)».

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

   ```markdown
   ## Как проверено
   Какие команды запускались и что вернули (вывод, скриншот).

   ## Риск
   Низкий / средний / высокий и почему; какие чувствительные пути затронуты.

   ## Как откатить
   Флаг, который выключает изменение, или команда отката.
   ```

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

   ```text
   # .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](https://code.claude.com/docs/en/code-review-customize).

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

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

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

Управляемый Code Review оплачивается по расходу токенов через кредиты использования отдельно от лимитов плана, и счёт выставляется организации, а не автору PR. Цена ревью растёт с уровнем Quick, Standard или Deep, размером изменения, сложностью окружающего кода и числом находок, которые нужно перепроверить, а режим «After every push» умножает её на число пушей. Цифра «$15–25 за ревью», которая ходит по обзорам, относится ко временам research preview, и в нынешней [документации о стоимости Code Review](https://code.claude.com/docs/en/code-review-costs) её нет. Чтобы оценить бюджет, документация предлагает пилот: задать месячный лимит расходов, включить несколько репозиториев в режиме «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](https://claude.com/blog/code-review-is-now-generally-available)). Как устроены сами кредиты использования и когда выгоднее перейти на Max, разобрано в статье «[Стоимость дополнительного использования Claude: кредиты или Max](https://blog.laozhang.ai/ru/posts/claude-extra-usage-cost)».

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

Если 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 и снижайте планку только там, где откаты и инциденты подтверждают, что автоматических слоёв хватает.

## Источники

Внешние страницы, на которые ссылается это руководство, в порядке упоминания. Последнее обновление: 2026-10-23.

- [посту Anthropic о ревью кода в команде Claude Code в блоге claude.dev](https://claude.dev/blog/solving-code-review-at-anthropic/) (claude.dev)
- [документации Claude Code о локальном ревью через /code-review](https://code.claude.com/docs/en/code-review-local) (code.claude.com)
- [документации Claude Code о сервисе Code Review](https://code.claude.com/docs/en/code-review) (code.claude.com)
- [разделе документации Code Review о чтении результата из скрипта](https://code.claude.com/docs/en/code-review-pull-requests) (code.claude.com)
- [документации о настройке Code Review через REVIEW.md и CLAUDE.md](https://code.claude.com/docs/en/code-review-customize) (code.claude.com)
- [документация Claude Code об ultrareview](https://code.claude.com/docs/en/ultrareview) (code.claude.com)
- [документации о стоимости Code Review](https://code.claude.com/docs/en/code-review-costs) (code.claude.com)
- [объявление Anthropic о выходе Code Review в GA](https://claude.com/blog/code-review-is-now-generally-available) (claude.com)