Используйте Claude Code Review как PR-гейт на базе CLAUDE.md и REVIEW.md

Anthropic выпустила Code Review для Claude Code 9 марта 2026 года — и с одной цифрой, от которой должен поморщиться любой инженерный менеджер: внутри Anthropic объём кода на одного инженера вырос на 200% за год, а ревью стало узким местом (Anthropic). Вот в этом и суть. AI-кодинг не убрал работу по ревью. Он просто перенёс точку давления.

Полезная реакция — не «пусть Claude сам проверяет свою домашку». Так вы получите вежливую фабрику багов. Полезная реакция — превратить Claude Code Review в повторяемый PR-гейт с правилами, в которые ваша команда реально верит.

Документация Anthropic по настройке теперь делает это вполне практичным. Ревьюер может запустить проверку комментарием @claude review, а Code Review читает файлы CLAUDE.md в репозитории плюс корневой REVIEW.md. Нарушения CLAUDE.md считаются замечаниями уровня nit, а Claude даже может отметить PR, из-за которого CLAUDE.md устаревает (Claude Help Center). REVIEW.md — место для правил именно ревью, включая пример Anthropic: “any new API route must have an integration test.”

Вот это предложение — ключ. Хватит просить AI-ревьюеров «быть внимательнее». Дайте им закон репозитория.

Проблема: AI сделал PR-ревью шумнее

Спор в сообществе мутный, потому что правы обе стороны.

В треде Hacker News про Claude Code Review разработчики спорили о цене, пользе и неловком факте: AI-вендор продаёт ревьюер для кода, сгенерированного AI. Один комментатор указал на собственные цифры Anthropic по большим PR и прочитал их как тревожный сигнал о качестве агентной разработки, а другие возражали, что именно глубокая вторая пара глаз — то место, где инструмент окупается (Hacker News).

На Reddit та же дискуссия звучит практичнее. В одном треде разработчик спросил, правда ли люди настолько доверяют коду, сгенерированному Claude, что готовы пропускать ревью, ведь Claude иногда пишет код, который они сами не понимают. Ответы были прямыми: ревьюйте, проверяйте, держите изменения маленькими и не притворяйтесь, будто делегирование отменяет ответственность (Reddit). В другом треде люди обсуждали использование отдельных AI-агентов для ревью результата Claude — но всё равно с проверкой самого ревью по кодовой базе (Reddit).

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

Он не должен быть финальным утверждающим.

Anthropic говорит это прямо. Code Review сам по себе не одобряет PR и не блокирует их. Существующие процессы ревью остаются на месте (Claude Help Center). Так что «гейт» — это гейт команды: никакого человеческого approval, пока Claude не запущен, Important-замечания не исправлены или явно не waived, а автор PR не разобрался с правилами конкретного репозитория.

Скучно? Отлично. Скучные гейты предотвращают инциденты.

Настройка: два Markdown-файла, две задачи

У Claude Code Review есть две важные поверхности памяти.

CLAUDE.md — общий контекст проекта. Он применяется к сессиям Claude Code в целом, не только к ревью. Anthropic рекомендует хранить там команды, соглашения, короткие архитектурные заметки, жёсткие ограничения и известные ловушки. Они также советуют держать файл плотным по сигналу, примерно до 200 строк, потому что он загружается в контекст, хотя prompt caching снижает повторную стоимость токенов в Enterprise-сессиях (Claude Help Center).

REVIEW.md — другое. Он лежит в корне репозитория и используется только для ревью. В документации Anthropic по Code Review сказано, что его содержимое внедряется в каждого ревью-агента как инструкции высокого приоритета, и именно там нужно управлять severity, объёмом nit, правилами пропуска, repo-specific checks, стандартами проверки и поведением при повторном ревью (Claude Code Docs).

Вот разделение, которым пользуюсь я:

Стабильный контекст кладите в CLAUDE.md. Давление ревью — в REVIEW.md. Всё детерминированное — в CI.

Настоящий гейт для API routes

Допустим, backend-команда постоянно выкатывает routes с unit tests только на happy path, но без integration coverage. Люди-ревьюеры иногда это ловят. PR, сгенерированные Claude, делают проблему хуже: агент отлично пишет правдоподобный код handler и плохо помнит review scars конкретной команды.

Начните с CLAUDE.md:

# Project conventions

- API routes live in `src/routes`.
- Integration tests live in `tests/integration`.
- Use `requireAuth()` on non-public routes.
- Validate request bodies with Zod schemas from `src/schemas`.
- Run `pnpm test:integration` before marking API work complete.

Затем добавьте корневой REVIEW.md:

# Code Review Rules

Treat these as Important unless stated otherwise.

## API routes

If a PR adds or changes a file under `src/routes/**`:
- Flag missing integration test coverage in `tests/integration/**`.
- Flag routes without explicit auth, unless the route is listed as public.
- Flag request bodies that are not validated with a Zod schema.

Do not accept unit tests as a substitute for route-level integration tests.

## Evidence bar

For every Important finding, cite the changed file and the missing or conflicting evidence.
If the claim depends on a convention, cite this REVIEW.md rule.

Последний раздел важен. LLM-ревьюеры умеют уверенно нести чушь. Требование evidence заставляет ревью привязывать замечание к файлу, строке или явной политике. Оно не уберёт false positives полностью, но изменит форму ревью: не «по ощущениям», а «покажи».

Теперь PR добавляет:

// src/routes/billing.ts
router.post("/billing/plan", async (req, res) => {
  const result = await updatePlan(req.body.planId);
  res.json(result);
});

Хороший комментарий Claude Code Review должен сказать примерно так:

• Important: src/routes/billing.ts добавляет новый POST route без видимого auth.
• Important: request body читает req.body.planId без schema validation.
• Important: под tests/integration/** не добавлен соответствующий integration test.

Решение всё равно принимает человек-ревьюер. Возможно, auth middleware навешан выше. Возможно, integration test живёт в сгенерированном contract suite. Окей. Гейт сделал свою работу, если заставил обсудить это до merge.

Как запускать и не сжечь деньги

Anthropic даёт три режима триггеров для репозитория: один раз после создания PR, после каждого push или вручную. Вручную значит без затрат, пока кто-то не оставит комментарий @claude review; после этого дополнительные pushes автоматически запускают ревью для этого PR (Claude Help Center).

Для большинства команд я бы не начинал с «после каждого push». Anthropic говорит, что Code Review в среднем занимает около 20 минут и обычно стоит $15–$25 за ревью, масштабируясь с размером и сложностью PR (Anthropic). Это дёшево по сравнению с production incident. Это дорого по сравнению с запуском ESLint.

Используйте tiered gate:

1. Каждый PR прогоняет обычный CI.
2. Рискованные PR получают @claude review.
3. Большие PR, изменения auth, изменения payments, миграции и изменения public API требуют ревью Claude до человеческого approval.
4. Повторяйте ревью Claude после крупных изменений, а не после каждой правки опечатки.
5. Финальный approval остаётся за людьми.

Лёгкий GitHub PR checklist делает гейт явным:

## AI Review Gate

- [ ] CI is green.
- [ ] `@claude review` has run, or this PR is exempt.
- [ ] Important findings are fixed or explained.
- [ ] If this PR changes conventions, `CLAUDE.md` is updated.
- [ ] If this PR changes review policy, `REVIEW.md` is updated.

Если вы предпочитаете запускать Claude внутри собственного workflow, документация Anthropic по GitHub Actions показывает anthropics/claude-code-action@v1 и конфигурацию code-review plugin, с обычным предупреждением использовать GitHub Secrets для API keys (Claude Code Docs). Этот путь даёт больше контроля в CI. Управляемый Code Review даёт более глубокого multi-agent reviewer, которого описывает Anthropic.

Не путайте их. Одно — programmable automation. Другое — платный depth-first reviewer.

Трюк: пусть Claude проверяет контракт, а не стиль

Плохие REVIEW.md читаются как печеньки с предсказаниями:

Please ensure the code is clean, maintainable, secure, and well tested.

На выходе будет каша.

Хорошие REVIEW.md кодируют scars:

## Database migrations

Flag as Important if:
- A migration adds a non-null column without a default on an existing table.
- A migration backfills data without batching.
- Application code starts reading a new column before the migration is deployed.

Skip:
- Formatting comments in generated Prisma client files.

Вот здесь AI-ревью становится полезным. Оно не заменяет вкус вашего senior engineer. Оно проигрывает институциональную память команды на каждом PR.

Несколько правил, которые хорошо работают:

## Re-review behavior

On the first review, report Important and Nit findings.
On later reviews of the same PR, suppress new Nits unless they are directly caused by the latest push.

## Test policy

Flag missing tests only when the changed behavior is observable through a stable public interface.
Do not request snapshot tests for purely visual copy changes.

## Security policy

Flag any new endpoint that:
- Accepts user input without validation.
- Performs authorization by trusting a user-provided account ID.
- Logs tokens, session IDs, API keys, or full request bodies.

Обратите внимание, чего здесь нет: «сделай код элегантным». Об элегантности люди могут спорить в ревью. Claude должен проверять контракты.

Чего не хватает этим тредам

HN и Reddit всё время крутятся вокруг одного вопроса: должен ли AI ревьюить AI-код?

Неправильный вопрос.

Правильный вопрос: какие части ревью вы готовы сделать явными?

Если ваша review culture живёт в головах senior engineers, Claude Code Review будет казаться шумным и произвольным. Если review culture записана как правила репозитория, она становится усилителем. CLAUDE.md объясняет Claude, как устроен проект. REVIEW.md говорит Claude, что ваша команда отказывается мержить.

Это также отвечает на жалобу «мы теперь документируем для Claude». Да, разработчики теперь пишут docs для агента. Звучит глупо, пока не понимаешь, что эти docs одновременно onboarding material, review policy и incident prevention. Хороший CLAUDE.md — это ещё и лучший файл «как работает этот repo» для людей.

Острый край — ответственность. Если Claude пропустил баг, вы всё равно его смерджили. Если Claude выдумал баг, вам всё равно нужно его отклонить. Если Claude ревьюит собственный output, вам всё равно нужны независимые сигналы: tests, type systems, static analysis, observability и человек, который понимает изменение.

Используйте Claude Code Review как гейт, а не как судью. Пусть он каждый раз задаёт раздражающие вопросы:

• Где integration test?
• Где enforced auth?
• Этот PR сделал CLAUDE.md ложным?
• Стоит ли комментировать этот generated file?
• Это замечание backed by code или просто догадка?

Этого достаточно, чтобы окупиться на правильных PR.

Попробуйте тот же setup с Claude Fable 5 on OneHop, drop-in, и начните с $10 бесплатно.

Дальше почитать: Getting started with Claude Fable 5.