Проверка кода с Claude Code: ловите баги до продакшена

Что такое Claude Code Review?

Claude Code Review — это многоагентная система проверки кода, которая анализирует PR в контексте репозитория и сообщает о потенциальных багах, проблемах безопасности и регрессиях. GitHub Code Review запускает агентов на PR в GitHub, а локальная команда /code-review даёт вам обзор текущего диффа прямо из Claude Code.

Ключевое слово здесь — контекст. Обычная проверка диффа предлагает посмотреть на изменённые строки. Агент(ы) Claude рассматривают эти изменения в контексте всего репо. В GitHub‑процессе несколько специализированных агентов работают параллельно, после чего выполняются верификация, дедупликация и ранжирование по важности.

Например, 10 строк, меняющих преобразование в pandas, могут зависеть от схемы, созданной вышестоящей моделью dbt, детализации таблицы Snowflake и предположений, заложенных в нижестоящем дашборде.

Claude ни одобряет, ни блокирует PR. GitHub Code Review выставляет нейтральный итог проверки, поэтому ваши текущие правила защиты веток остаются без изменений, если только вы не построите собственную логику CI вокруг результатов проверки.

Три варианта поверхности для ревью

Сейчас есть 3 основных способа проверять код с помощью Claude Code.

Локальная команда /code-review просматривает коммиты вашей ветки. Ей можно также передать конкретный файл, ветку, номер PR или диапазон Git‑ссылок.

GitHub Code Review ориентирован на сам PR. В зависимости от настроек репо он может выполняться один раз после создания PR, после каждого пуша или только по запросу с помощью @claude review.

/code-review ultra — более тяжёлый вариант. В Anthropic эта функция называется ultrareview, и /ultrareview работает как псевдоним, если функция доступна вашему аккаунту. Запускается пул агентов‑рецензентов в удалённой песочнице, и каждый найденный баг воспроизводится и подтверждается перед публикацией. Сейчас это research preview; типичный обзор занимает около 5–10 минут.

Что Claude помечает, а что пропускает

Главный приоритет Claude Code Review — корректность. В документации Anthropic отдельно выделяются баги, влияющие на прод, в отличие от предпочтений форматирования и отсутствующего покрытия тестами.

Выводы имеют 3 уровня важности:

Это разграничение полезно, потому что у дата‑саентистов часто разные взгляды на то, чему стоит уделять время ревью. Предложение по именованию revenue_df вместо weekly_revenue — это не то же самое, что умножение выручки на 2 из‑за многих‑ко‑многим соединения, просочившегося в трансформацию.

Как настроить Code Review в Claude Code?

Настройка Claude Code Review зависит от того, нужен ли вам локальный обзор или ревью PR в GitHub. Локальный /code-review не требует GitHub App и может выполняться ещё до открытия PR. 

GitHub Code Review требует, чтобы Владелец организации (Owner или Primary Owner) настроил приложение Claude GitHub App и выбрал репозитории. При проверке PR стоит создать специальный файл REVIEW.md с правилами именно для ревью.

CLAUDE.md и REVIEW.md

CLAUDE.md и REVIEW.md служат разным целям, и их смешение — простой путь к «шумному» ревью.

CLAUDE.md содержит общие инструкции по проекту, которые Claude использует в разных задачах. Ревью кода тоже читает эти инструкции, и новые нарушения отмечаются как «nits». REVIEW.md, напротив, предназначен именно для поведения при ревью и указывает агентам, что нужно помечать, пропускать или считать Important.

Для Python‑репозитория с данными я бы держал CLAUDE.md сфокусированным на структуре репо, запуске pytest, использовании pandas или polars для трансформаций и расположении SQL‑моделей. 

А правила ревью поместил бы в REVIEW.md. Примеры возможных правил:

• «Проверять, что у каждой новой трансформации есть соответствующий тест».
• «Никогда не логировать учётные данные».
• «Пропускать сгенерированные файлы».

Небольшой REVIEW.md может выглядеть так:

# Review instructions

## Important findings

Report as Important:
- Incorrect joins or filters that can change dataset grain
- Missing tenant or customer scoping
- Secrets or credentials written to logs
- Silent changes to revenue or customer metrics

## Do not report
- Formatting already enforced by Ruff
- Generated files
- *.lock files

## Always check
- New transformations have tests
- Joins use the intended keys
- Datetime operations specify timezone assumptions
- Missing values are handled explicitly

Рекомендую держать REVIEW.md коротким: длинные инструкции «размывают» важные правила. Текущая реализация также читает файл как обычный текст инструкций, поэтому стоит помещать правила прямо в него, а не использовать сокращения с @. 

Кстати, при локальной разработке /code-review не читает REVIEW.md. Он следует CLAUDE.md, а конвейер GitHub Code Review использует REVIEW.md для специфики ревью.

Если вы хотите одинаковые правила локально и в GitHub, разместите общие правила в CLAUDE.md и повторите специфичные для ревью в REVIEW.md при необходимости.

Подробности — в нашем руководстве по написанию лучшего файла CLAUDE.md.

GitHub App и режимы запуска

GitHub Code Review настраивается Владельцем организации через админ‑настройки Claude. Админу нужно установить Claude GitHub App, выдать доступ к репозиториям, выбрать репозитории для ревью, а затем назначить поведение ревью для каждого.

Есть 3 режима запуска:

Общее исключение для всех трёх: Claude никогда автоматически не проверяет PR из форка. Кто‑то должен оставить комментарий @claude review.

По состоянию на июль 2026 года изменились и ручные команды: 

• @claude review запускает одиночное ревью и не подписывает PR на будущие пуши. 

• @claude review always запускает ревью и подписывает PR на будущие ревью при пушах.

• @claude review once ведёт себя так же, как и базовая команда.

Если вы знакомились с Claude Code Review ранее в 2026 году, старые руководства могли утверждать, что @claude review подписывает PR на будущие ревью. Это изменилось в июле 2026 года и остаётся актуальным в сентябре 2026 года.

Пользователи Pro и Max, у которых нет доступа к организационному GitHub Code Review, могут вообще не использовать приложение и запускать /code-review локально, а для более глубокого ревью — /code-review ultra.

Как локально проверить дифф с помощью /code-review?

Локальная команда /code-review проверяет вашу текущую ветку до открытия PR. Я всегда начинаю с этого, потому что так проще поймать проблемы во время работы и не уронить CI.

Сценарий для проверки

Представим, что у нас есть e‑commerce‑репозиторий с таблицей заказов, содержащей order_id, customer_id, order_date, status и revenue, и мы создаём weekly_revenue.py для расчёта недельной выручки:

orders = load_orders()
customers = load_customers()

# Derive the reporting week from the order date
orders["week"] = orders["order_date"].dt.to_period("W").dt.start_time

weekly_revenue = (
    orders
    .merge(customers, on="customer_id", how="inner")
    .groupby("week", as_index=False)["revenue"]
    .sum()
)

На первый взгляд всё выглядит нормально. merge() явный, группировка читаемая, а выручка агрегируется после соединения.

Проблема в том, что в таблице клиентов для некоторых клиентов хранится несколько исторических записей. Клиент с 2 записями после соединения даёт 2 строки, из‑за чего выручка по этому клиенту удваивается. Это как раз тот тип бага, который легко упустить, просматривая локально трансформацию без проверки детализации таблицы.

Ограничьте дифф

В сессии Claude Code выполните /code-review.

Команда проверяет коммиты текущей ветки относительно upstream‑ветки, а также несохранённые изменения. Можно также указать конкретный файл, ветку, PR или диапазон, например main...feature/weekly-revenue.

Например:

/code-review weekly_revenue.py

или:

/code-review main...feature/weekly-revenue

Можно также передать уровень «усилий», например /code-review high. На уровнях low и medium отчёт включает только самые уверенные находки, тогда как high и выше расширяют охват ценой увеличения риска ложных срабатываний. 

Используйте флаги для настройки ревью

Когда вы освоитесь с процессом, пригодятся два флага: 

• --fix применяет найденные исправления к вашему рабочему дереву после ревью.

• --comment публикует их как инлайн‑комментарии.

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

Ревью может сообщить примерно следующее:

🔴 Important
weekly_revenue.py:9

The merge on customer_id can duplicate order rows because
customers contains multiple records per customer. This can
inflate revenue when a customer has more than one matching
customer record.

Verify that customer_id is unique in customers or join against
the intended current-record subset before aggregating revenue.

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

Изучите находки

Я всё равно сделал бы ручную проверку, прежде чем запускать /code-review --fix. Сначала найдите код, формирующий customers, проверьте ограничения уникальности и посмотрите тесты вокруг weekly_revenue.py.

Если customers.customer_id действительно уникален, находка Claude — ложноположительная. Если таблица содержит по одной строке на клиента на каждую дату вступления в силу, проблема реальна, и трансформацию нужно менять.

Ключевой момент: рецензент Claude смотрит на поведение кода, а я отвечаю за понимание того, что представляют данные.

Вы можете попросить Claude провести расследование после ревью:

Investigate the customer_id join finding.
Check how the customers table is built and determine whether
customer_id is unique at the point of this merge. Do not modify
the code yet.

Этот второй шаг часто полезнее, чем просить Claude «вслепую» исправить комментарий. Так ревью превращается в короткое исследование, а не в генерацию кода.

Как запустить Claude Code Review на PR в GitHub?

GitHub Code Review публикует выводы Claude прямо в PR, чтобы рецензенты видели проблему рядом с изменённым кодом. 

Последовательность важна, поскольку ревью «прикрепляется» к уже существующему PR:

1. Отправьте ветку weekly-revenue в GitHub через git push.

2. Откройте pull request. Claude может проверить только открытый PR, до этого ничего не произойдёт.

3. Если репозиторий настроен на автоматический триггер, ревью стартует само. Если выбран Manual, опубликуйте @claude review как верхнеуровневый комментарий в PR.

Есть три частых «подводных камня». Команда должна быть верхнеуровневым комментарием PR, а не ответом на инлайн‑комментарий. У вас должны быть права write, maintain или admin на репо. Команда также должна начинать комментарий, с once или always на той же строке, если они добавлены.

Запустите ревью

Выбор, который действительно влияет на расходы, — между двумя ручными командами, а не между ручным и автоматическим режимом.

@claude review запускает одно ревью и не подписывает PR. @claude review always запускает ревью и подписывает PR, поэтому каждый следующий пуш стартует новое.

Так работает после июля 2026 года и по состоянию на сентябрь 2026‑го. До этого базовая команда @claude review подписывала PR на будущие ревью, так что, если вы следуете старому руководству, проверьте это сначала.

Ревью часто занимает около 20 минут, хотя Anthropic отмечает, что стоимость и длительность зависят от размера и сложности PR. Каждый обзор также тарифицируется отдельно по кредитам использования и не расходует включённые лимиты Team или Enterprise. Если вы хотите подробнее о структуре стоимости, загляните в наш гайд по лимитам использования Claude Code.

Читайте инлайн‑комментарии и проверку (check run)

Когда ревью завершится, Claude оставит инлайн‑комментарии в соответствующих строках. В GitHub check run также будет сводка по уровням важности — это полезно, когда в PR есть несколько находок в weekly_revenue.py, SQL‑моделях и тестах.

Например:

Инлайн‑комментарий — место для изучения самой проблемы. Check run — источник общей картины ревью.

Учтите: нажатия 👍 или 👎 не запускают новое ревью, а ответ на инлайн‑комментарий не вызывает реакцию Claude. Чтобы получить ещё одно ревью, исправьте код и отправьте пуш или оставьте @claude review как новый верхнеуровневый комментарий в PR.

Ревью само по себе также не блокирует слияние. Проверка имеет нейтральный результат, хотя её вывод включает машиночитаемую информацию о важности, которую команда может обработать через gh и jq, если захочет построить собственный «мердж‑гейт».

Как приоритизировать комментарии Claude?

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

Я использую простую «вилку» из трёх вариантов:

Этот последний пункт важен. Рецензент, оставивший 30 замечаний, не обязательно лучше того, кто оставил 5. Ложная тревога по поводу pandas-соединения может стоить больше времени, чем исходное изменение кода.

Исправить, пропустить или оспорить

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

The customer_id finding is valid. Inspect the existing customer
model and update weekly_revenue.py to join only the current
customer record. Add a regression test for a customer with
multiple historical records, then run the relevant tests.

Затем Claude может изучить репозиторий, изменить Python‑код, добавить тест и запустить тесты.

Если вы хотите работать с комментариями в GitHub, Claude Code также может взаимодействовать с репозиторием через GitHub CLI (gh). Важно выбирать конкретные правки, которые вы считаете корректными, а не поручать «исправить всё» из ревью.

Так разработчики остаются в цикле ревью:

1. Claude находит возможную проблему.
2. Я проверяю проблему относительно кода и допущений о данных.
3. Claude вносит запрошенное исправление.
4. Запускаются тесты.
5. Claude снова проверяет получившийся дифф.

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

Что в PR по данным всё ещё требует человека?

Риск, который Claude не покрывает, — код работает корректно, но делает не то. Три варианта этой проблемы встречаются снова и снова:

• Предположения вне диффа. Claude читает ваш репозиторий, а не ваш дата‑вэрхаус, сервис конфигураций или контракт другой команды. Соединение может использовать верные ключи и всё же менять детализацию результата, потому что количество строк на ключ — это свойство вышестоящей таблицы, а не кода перед вами.

• Определения, известные только вашей команде. Считать ли выручку на уровне заказа, клиента или недели — бизнес‑решение. Claude подскажет, что groupby() честно суммирует любые переданные строки. Но он не скажет, какое число подтвердит ваша финкоманда.

• Предположения о времени и типах. Что означает 2026-08-27: день в UTC, локальный рабочий день или отчётная дата из вышестоящей модели? «Тихое» приведение типов похоже: операции над object, nullable integer, timezone‑aware datetime и строковыми столбцами могут возвращать правдоподобный результат, незаметно меняя поведение сравнений.

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

Поэтому я рассматриваю Claude как рецензента поведения реализации, а не владельца определений.

Когда использовать обычное ревью, а когда Ultrareview?

Используйте /code-review для быстрой локальной обратной связи и /code-review ultra для более глубокой проверки перед слиянием. Оба проверяют код, но /code-review рассчитан на итерации, тогда как ultra‑проверка запускает несколько удалённых агентов и независимо подтверждает найденные баги.

Anthropic сейчас описывает ultra‑ревью как research preview. Подписчики Pro и Max получают 3 бесплатных запуска единоразово (квота не обновляется), после чего ревью обычно стоит $5–$25 в зависимости от размера изменений. Пользователи Team и Enterprise не получают эти бесплатные запуски; функция недоступна в Amazon Bedrock, Google Cloud Agent Platform, Microsoft Foundry и для организаций с включённым Zero Data Retention.

Ключевое отличие — верификация. /code-review ultra отправляет состояние репозитория в удалённую песочницу и запускает пул агентов‑рецензентов, при этом найденные баги независимо воспроизводятся перед возвратом как находки.

Я бы не запускал это на каждый коммит. Если я меняю имя переменной в Python‑ноутбуке или форматирование модели dbt, достаточно локального /code-review. Если меняю логику генерации признаков для прод‑модели, переписываю трансформацию выручки или корректирую агрегацию на уровне клиентов — дополнительный проход оправдан.

Есть и нюанс в названии. Документированная команда — /code-review ultra, а /ultrareview — псевдоним, который работает, если функция доступна вашему аккаунту. В старых руководствах часто фигурирует /ultrareview как основная команда, но документация Anthropic теперь рассматривает глубокую облачную проверку как часть семейства команд /code-review, и /code-review ultra откатывается к локальному ревью, когда облачная функция недоступна.

Запустите ultra‑ревью на том же PR

Из репозитория выполните:

/code-review ultra

Чтобы проверить PR в GitHub напрямую:

/code-review ultra <pr#>

Без аргумента /code-review ultra сравнивает вашу текущую ветку с веткой по умолчанию и включает незакоммиченные и подготовленные изменения. Обзор ветки по умолчанию ограничен примерно 500 изменёнными файлами и 8 000 изменёнными строками, хотя Anthropic отмечает, что эти числа могут меняться. Если дифф слишком велик, отправьте ветку и запустите ревью как PR.

С номером PR удалённая среда клонирует PR из GitHub, и ничего не загружается с вашей машины.

Перед запуском Claude показывает объём ревью, оставшиеся бесплатные запуски и оценку стоимости. После подтверждения ревью идёт в фоне, так что вы можете продолжать работать в Claude Code, пока удалённые агенты заняты.

В примере с weekly_revenue.py я бы сравнил находки, а не предполагал, что более глубокий обзор обязательно прав.

Если /code-review помечает соединение с клиентами, а ultra‑ревью независимо воспроизводит то же завышение выручки, уверенность в находке возрастает. Если ultra‑ревью игнорирует её из‑за гарантированной уникальности вышестоящей таблицы, я бы изучил доказательства из обоих обзоров и фактическое определение модели до внесения изменений.

В этом и польза нескольких рецензентов: расхождение даёт повод для расследования.

Есть и вопрос стоимости. GitHub Code Review сейчас в среднем стоит $15–$25 за ревью, тогда как ultra‑ревью обычно обходится в $5–$25 после бесплатных запусков для Pro и Max. Стоимость GitHub Code Review не связана с включённым использованием в плане, и Anthropic предоставляет организациям инструменты контроля расходов.

Если вы работаете в одиночку, локальный /code-review плюс изредка /code-review ultra — разумная отправная точка. Если вы на плане Team или Enterprise и хотите, чтобы каждый PR сопровождался автоматическим ревью, логичнее использовать GitHub Code Review.

Практичный рабочий процесс Claude Code Review

Полезный процесс — это не «запускайте Claude перед каждым слиянием». Это последовательность, где каждое ревью происходит на своём этапе разработки, потому что каждое стоит по‑разному и ловит разный класс проблем.

Вот процесс, который я бы использовал для прод‑изменения:

Write code
	   ↓
Run tests and data checks
	   ↓
/code-review
	   ↓
Fix verified findings
	   ↓
Open GitHub PR
	   ↓
GitHub Code Review
	   ↓
Human triage
	   ↓
/code-review ultra for higher-risk changes
	   ↓
Final tests
	   ↓
Human merge

Локальное ревью ловит проблемы, пока их дёшево исправлять. GitHub‑ревью даёт команде общий журнал находок, а ultra — более затратное «второе мнение» перед значимым слиянием.

Дополнительные проверки для дата‑саентистов

Для задач с данными я бы добавил 4 проверки вокруг Claude, а не ожидал, что модель выполнит всё ревью целиком:

• Проверьте количество строк и детализацию датасета до и после важных соединений
• Запускайте модульные или интеграционные тесты вокруг трансформаций и логики признаков
• Проверяйте утечки при построении признаков для ML
• Сверяйте бизнес‑метрики с эталонным запросом или дашбордом

Claude может участвовать во всех четырёх активностях, но ожидаемый результат должен подтверждаться кодом, тестами или данными, а не объяснением Claude.

Итоги

Claude Code Review лучше всего работает, когда к нему относятся как к ещё одному инженеру в треде ревью, а не как к автоматическому «штампу одобрения».

Локальная команда /code-review даёт быстрый обзор до появления PR. GitHub Code Review приносит многоагентные находки прямо в PR для организаций Team и Enterprise, а /code-review ultra обеспечивает более глубокое удалённое ревью, когда изменения заслуживают дополнительного прохода.

Я бы начал с малого. Включите /code-review в обычный рабочий процесс с ветками, напишите короткий REVIEW.md для GitHub‑ревью и попробуйте /code-review ultra для изменений, где плохое слияние может вам реально дорого обойтись.

Для базовых понятий о модели полезен наш курс «Введение в модели Claude», а GitHub Foundations и Intermediate GitHub Concepts охватывают Git и рабочий процесс GitHub, поверх которого работает Code Review. Для вдохновения по триажу репозиториев GitHub с помощью Claude рекомендую наш туториал по коннектору Claude Code.