Почему ваш AI-ревьюер похож на автора, проверяющего свою же домашку
Вы замечали? Когда просите Claude Code проверить код, который он только что написал, он почти всегда отвечает: "Код выглядит отлично. Можно улучшить разве что нейминг." А потом этот же код падает в прод с NullPointerException. Дело не в том, что Claude плохой. Дело в контексте. Он помнит, как писал этот код, какие решения принимал, и невольно оправдывает собственные ошибки. Это как попросить студента проверить свою контрольную — найдет пару опечаток, но логическую дыру пропустит.
Нам нужен независимый ревьюер. Тот, кто смотрит на код свежим взглядом, без багажа предыдущих решений. В Claude Code для этого есть механизм — Codex exec. И сегодня я покажу, как выжать из него максимум. Если вы еще не знакомы с архитектурой под-агентов в Claude Code, рекомендую сначала прочитать этот разбор — там объясняется, как работают Subagents и зачем они вообще нужны.
Предупреждение: команда exec требует понимания, что вы делаете. Неправильное использование может сжечь квоту токенов за 5 минут. Читайте до конца, прежде чем экспериментировать.
Что такое Codex exec и почему это не просто "еще один промпт"
Команда exec — это способ запустить новый экземпляр Claude Code внутри текущей сессии. Представьте, что вы работаете в основном терминале, а потом говорите: "Эй, запусти-ка второго клода, дай ему только этот файл и задачу — найди баги". Второй клод стартует с пустым контекстом, без истории чата, без ваших предыдущих команд. Он видит только то, что вы ему скормили через exec.
Звучит просто, но на практике это открывает дверь к целому классу сценариев:
- Ревью кода без предвзятости — второй экземпляр не знает, что код писал предыдущий AI или вы сами.
- Параллельные проверки — можно запустить несколько exec для разных модулей.
- Безопасный аудит — exec не имеет доступа к вашей истории чата, только к переданным данным.
- Изоляция ошибок — если exec зависнет, основной сеанс не пострадает.
Но есть нюанс: exec — это не магия. Его надо правильно настроить, иначе получите бесконечный цикл из AI, проверяющего AI, проверяющего AI. Об этом чуть позже.
Готовим CLAUDE.md для работы с exec
Первое, что нужно сделать — описать алиас для ревью в файле CLAUDE.md. Без этого exec будет работать как пустая болванка без инструкций. Откройте CLAUDE.md в корне вашего проекта и добавьте туда блок:
# Code Review Agent
Вы — независимый ревьюер кода. Ваша задача — найти в коде:
- Логические ошибки
- Уязвимости (XSS, SQL injection, RCE)
- Проблемы с производительностью
- Необработанные краевые случаи
Правила:
- Никогда не говорите «код хороший». Всегда находите минимум 3 замечания.
- Если код идеален — напишите «Нужен второй ревьюер».
- Каждое замечание сопровождайте строкой кода и причиной.
- Не предлагайте исправления, только указывайте на проблемы.
Зачем такое ограничение — не предлагать исправления? Потому что иначе ревьюер начнет переписывать код, а нам нужен именно аудит. Исправления мы сделаем отдельно. Это одна из лучших практик, описанных в этой статье — разделяй процессы генерации и проверки.
Теперь сам алиас для exec. Добавьте в CLAUDE.md секцию с командами:
# Алиасы
/review [file] — запустить ревью указанного файла через exec
Но сам алиас мы пропишем не в CLAUDE.md (он не поддерживает динамические alias), а через файл .claude-commands или через настройки Claude Code. На момент версии 2.1 (июль 2026) это делается так:
# В .claude/config.yaml (или .clauderc)
aliases:
review: "exec -m 'Ты — ревьюер из CLAUDE.md. Проверь код в файле {args}'"
Если вы используете версию Claude Code ниже 2.0, обновитесь. Команда exec появилась только в версии 2.0, а в 2.1 добавили поддержку алиасов. Проверить версию: claude --version. Подробнее о горячих клавишах и обновлениях — в этом гайде.
Сценарий 1: Запуск ревью из текущего Claude Code
Самый простой способ — когда вы уже работаете в Claude Code и хотите проверить конкретный файл.
Допустим, у вас есть файл auth.py, который написал AI. Вместо того чтобы писать "Проверь auth.py", что приведет к самопроверке, используйте exec:
/exec -f auth.py -m "Ты — независимый ревьюер. Найди все баги и уязвимости. Не давай поблажек."
Флаг -f передает содержимое файла в новый контекст. Флаг -m устанавливает системное сообщение (инструкцию). Без -f exec не будет знать, что проверять.
Важно: exec не видит CLAUDE.md автоматически. Инструкция из CLAUDE.md не передается в под-агент. Поэтому мы либо передаем ее через -m, либо используем алиас, который это делает за нас.
Через алиас, который мы настроили выше, вызов будет еще короче:
/review auth.py
После выполнения вы получите список замечаний. Обратите внимание: exec работает в отдельном процессе, результат возвращается как текст. Вы можете сохранить его в файл или сразу обработать.
Сценарий 2: Запуск ревью из другого экземпляра Codex
А теперь самое интересное. Вы можете запустить exec прямо из консоли, используя утилиту codex (команда, которая присутствует в Claude Code, но доступна и как отдельный CLI-инструмент с версии 2.1).
Зачем это нужно? Допустим, вы пишете скрипт автоматизации, который:
- Берет все файлы из директории
- Запускает для каждого exec-ревью
- Агрегирует результаты
Или вы хотите встроить AI-ревью в пайплайн CI/CD. Тогда exec запускается не из интерактивного Claude Code, а из шелла или GitHub Actions.
Синтаксис:
codex exec --file auth.py -- "Ты — ревьюер. Проверь код и найди проблемы."
Обратите внимание на -- — он отделяет опции от самого промпта. Без него codex воспримет часть промпта как флаг.
Пример для всей директории:
for f in src/*.py; do
echo "=== Reviewing $f ==="
codex exec --file "$f" -- "Проверь файл на уязвимости. Выведи критичные сначала."
done
Этот подход экономит часы человеческого ревью. Но есть подводный камень: каждый вызов exec — это отдельный запрос к API. Если у вас 50 файлов, вы сделаете 50 запросов. Стоимость может вырасти. Рекомендую ограничивать количество параллельных exec через xargs -P 3, чтобы не превысить лимиты аккаунта.
Типичные ошибки и как их избежать
1 "Exec завис"
Если exec не отвечает больше минуты — скорее всего, AI ушел в бесконечный цикл размышлений. Причина: слишком размытая инструкция. Вместо "найди проблемы" дайте конкретные категории: "найди логические ошибки, уязвимости типа OWASP Top 10, проблемы с многопоточностью".
2 "Exec вернул пустой ответ"
Значит, файл не был передан. Проверьте, существует ли файл и есть ли права на чтение. Используйте абсолютный путь, если exec запускается из другого контекста.
3 "Exec видит больше, чем нужно"
По умолчанию exec может получить доступ к файловой системе проекта (если не ограничить права). Если вы передаете -f, он видит только этот файл. Если не передаете — он может начать исследовать директорию. Используйте флаг --sandbox (доступен с версии 2.1.3), чтобы изолировать exec от файловой системы.
--no-cache. Иначе AI может вспомнить паттерны из предыдущих ревью и начать их повторять, теряя объективность.Расширенные сценарии: каскадное ревью и аудит legacy
Однажды я запустил exec внутри exec. Звучит безумно, но работает. Сценарий такой: первый exec проверяет код на баги, второй exec проверяет отчет первого exec на полноту и адекватность. Так мы получаем каскадное ревью, где каждый следующий AI ищет ошибки предыдущего. Это полезно для критичного кода (ядро, безопасность, финансовые транзакции).
Пример для legacy-аудита: у вас есть старая кодовая база, написанная 5 лет назад без тестов. Запускаете exec для каждого файла с инструкцией "Найди потенциальные баги, устаревшие API, необработанные исключения". Результаты можно собрать в один отчет и передать команде на фикс. Подробнее про промпты для автономной работы — в этой статье.
Часто задаваемые вопросы
Можно ли использовать exec для security review?
Да, но с оговорками. Exec может видеть только переданный файл, а для security-review часто нужен контекст всего приложения (как данные текут, какие эндпоинты). Лучше передавать несколько файлов через -f file1 -f file2. Для OWASP-скрининга добавьте в промпт: "ищи XSS, SQLi, IDOR, RCE и SSRF".
Как избежать ложных срабатываний?
Добавьте в инструкцию: "Если замечание неуверенное — промаркируй его как LOW. Если уверен на 90%+ — HIGH." И настройте порог: все HIGH обязательно фиксировать, LOW — только если есть время.
Что делать, если exec потребляет слишком много токенов?
Ограничьте размер файла: --max-tokens 4000. Или используйте флаг --quick (появился в 2.1.5), который заставляет AI отвечать коротко. Также можно передавать не весь файл, а только diff (измененные строки).
Можно ли запустить exec для ревью PR целиком?
Да, через CI. Пример для GitHub Actions: передайте все измененные файлы через files=$(git diff --name-only origin/main...HEAD) и для каждого запустите codex exec --file "$file" -- .... Результаты можно запостить как комментарий к PR.
Хотите увидеть больше примеров настройки Claude Code под себя? Загляните в статью о скрытых настройках — там описаны фишки, которые многие пропускают.
И последнее. Не пытайтесь автоматизировать всё подряд. Exec — мощный инструмент, но доверять ему финальное слово по продакшен-коду пока рано. Используйте его как второй этап проверки, а третий этап оставьте за человеком. И обязательно логируйте все результаты exec — потом сможете проанализировать, какие ошибки AI пропускает, и улучшить его промпты.
Кстати, если вы еще не попробовали Claude Pro с расширенной квотой, для частых exec он окупается быстро. А если хотите сравнить с альтернативами — почитайте мой обзор Cursor, Warp и Claude Code.