Ревью кода с Claude Code

Ревью — одна из задач, где агент полезен сразу, без настройки. Он не устаёт к сороковому файлу, не пропускает необработанный null из вежливости и умеет прочитать весь diff, а не только те места, куда упал взгляд. Но у ревью агентом есть свои особенности: он склонен находить замечания, даже когда их нет, и слабо отличает важное от вкусового. В этом уроке — как получать от него пользу и не утонуть в шуме.

Ревью своих изменений

Самый простой сценарий — перед коммитом. Вы поработали, изменения лежат в рабочем дереве. /diff покажет их целиком, включая правки, которые внёс агент. Дальше:

проверь мои изменения и предложи улучшения

Это работает, но лучше сузить запрос. Документация советует давать ревьюеру критерии: что считать находкой, а что нет.

проверь diff на корректность: обработка ошибок, краевые случаи,
гонки. стиль и именование не комментируй. для каждой находки —
файл, строка, почему это проблема.

Для Python-бэкенда стоит добавить: «проверь, что новые эндпоинты покрыты тестами и что миграция обратима». Для Flutter: «проверь, что виджеты не пересобираются лишний раз и что состояние не течёт при уходе с экрана». Чем конкретнее критерии, тем меньше мусора в ответе.

Встроенная команда /code-review

В Claude Code есть готовый навык ревью. Команда /code-review (синоним /review) проверяет текущий diff на ошибки корректности и возможности упрощения. Ей можно передать номер PR, имя ветки или путь — тогда она проверит их вместо рабочего дерева. Уровень тщательности задаётся словом: low и medium дают меньше находок с высокой уверенностью, high и выше — шире охват, включая сомнительные. Флаг --fix применяет найденное к рабочему дереву, --comment оставляет замечания в PR.

/code-review high
/code-review 1432 --comment

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

Рядом есть /security-review — проверка diff на уязвимости: инъекции, утечки секретов, небезопасная обработка данных. Для проектов, где ходят персональные данные или платежи, стоит запускать её перед каждым PR.

Ревью того, что написал агент

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

Первый — проверочный субагент против плана:

используй субагента, чтобы проверить diff экспорта в CSV против PLAN.md.
убедись, что каждое требование реализовано, для перечисленных краевых
случаев есть тесты, и ничего за пределами задачи не изменилось.
сообщай о пробелах, а не о стилистических предпочтениях.

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

Второй — две сессии, «писатель» и «ревьюер». В одном терминале агент пишет реализацию, во втором — свежая сессия получает запрос «проверь реализацию ограничителя запросов в @src/middleware/rateLimiter.ts, найди краевые случаи, гонки и несоответствия существующим middleware». Ответ второй сессии вы вставляете в первую: «вот замечания ревью, исправь». Свежий контекст здесь работает так же, как субагент, но вы видите обе стороны.

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

Ревью чужого PR

Для чужого кода агент особенно полезен как первый читатель. Если установлен gh, можно работать прямо с PR:

прочитай PR #1432 через gh, объясни, что он меняет и зачем.
потом проверь: есть ли изменения, не описанные в заголовке PR,
и есть ли места, где поведение старого API сломано.

Агент подтянет описание, diff и комментарии. Хороший первый вопрос — «что здесь изменилось на самом деле?» — часто расходится с описанием PR, и это уже находка. Дальше можно попросить сформулировать замечания в виде комментариев к строкам и оставить их через gh — но перед отправкой прочитайте: комментарии уходят от вашего имени.

Если вместо GitHub у команды GitLab, тот же сценарий работает через glab. Без CLI агент может обращаться к API напрямую, но без авторизации быстро упрётся в лимиты.

Ревью в CI

Неинтерактивный режим позволяет встроить ревью в конвейер:

git diff main --name-only | claude -p "проверь эти файлы на проблемы с безопасностью"

Для полноценной автоматизации — комментарии в PR при каждом пуше, разбор упавших проверок — есть готовые интеграции с GitHub Actions и GitLab CI/CD, а также GitHub Code Review, который делает автоматическое ревью каждого PR. Их настройка описана в документации; для вводного курса достаточно знать, что они существуют и что для них нужен отдельный доступ.

Пользовательский ревьюер

Если у команды есть устойчивые критерии ревью, их можно оформить в субагента и хранить в репозитории. Файл .claude/agents/security-reviewer.md из документации:

---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling

Provide specific line references and suggested fixes.

Вызов: «используй субагента security-reviewer для этого diff'а». Для проекта на Bitrix в таком файле уместно перечислить типичные проблемы платформы: прямые SQL-запросы вместо ORM, вывод без экранирования, чтение параметров запроса без проверки. О том, как устроены такие файлы, — в уроке про субагентов.

Что агент не заменяет

Ревью агентом хорошо ловит локальные ошибки: необработанные исключения, несогласованность с соседним кодом, пропущенные тесты. Оно плохо ловит то, что требует знания продукта: «эта фича противоречит тому, что мы обещали заказчику», «этот эндпоинт нельзя открывать без согласования с безопасностью». Такие вещи по-прежнему проверяет человек. Правильная схема — агент первым, человек вторым, и человек тратит время на смысл, а не на поиск опечаток.