Claude Code + Codex: двойное ревью AI-агентов через MCP

Изначально я собрал эту связку почти из жадности. У меня уже были две подписки: Claude Code для ежедневной работы и ChatGPT/Codex, который не хотелось держать просто “на всякий случай”. Потом @vlad_shlapakov подсказал идею: подключить Codex как отдельный инструмент к Claude Code и заставлять его проверять планы перед выполнением.

И ХОБА: это оказалось полезнее, чем очередной “лучший промпт”. Не потому что Codex всегда умнее Claude. А потому что второй агент не сидит в том же тоннеле контекста, в котором первый уже успел поверить в свой план.

Что поставить перед настройкой

Если вы открыли старую версию этой статьи и подумали “окей, а куда это вставлять?”, вы были правы. Минимальный сетап такой:

1. Поставьте Claude Code. Официальная инструкция здесь: Claude Code setup. Сейчас основной вариант для macOS/Linux выглядит так: curl -fsSL https://claude.ai/install.sh | bash, потом запускаете claude в папке проекта.
2. Поставьте Codex CLI. Официальная страница OpenAI: Codex CLI. Для macOS/Linux: curl -fsSL https://chatgpt.com/codex/install.sh | sh, потом запускаете codex.
3. Подключите нужный MCP-слой. Claude Code подключает внешние инструменты через MCP. Если у вас есть MCP-обёртка, которая вызывает Codex, в Claude появится инструмент примерно в духе mcp__codex__codex. Если обёртки нет — начните проще: держите Codex во второй вкладке терминала и копируйте туда тот же промпт для ревью вручную.

Отдельно полезно добавить OpenAI Docs MCP, если вы часто просите агента проверять свежие OpenAI API/Codex-доки. Это не заменяет ревью в Codex, но сильно снижает шанс, что агент несёт устаревшую документацию.

Протокол двойного ревью

Я храню это не огромным полотном в CLAUDE.md, а отдельным правилом/скиллом и подключаю из проектных инструкций. Смысл простой: до выхода из plan mode Claude обязан отправить план на независимую проверку.

## Dual review: Claude Code + Codex

Before ExitPlanMode on risky tasks, run an independent Codex review.

Send Codex this input:

Review this implementation plan.

## Plan
[full plan]

## Context
[repo constraints, user goal, files touched, deployment risk]

## Questions
1. Где план неполный?
2. Что может сломаться в проде?
3. Какие граничные случаи пропущены?
4. Есть ли более простой подход?
5. Какие проверки надо запустить до деплоя?

Return JSON:
{
  "verdict": "APPROVED" | "NEEDS_REVISION",
  "concerns": [],
  "suggestions": [],
  "missedCases": [],
  "testsToRun": []
}

Дальше правило такое:

• APPROVED — можно выходить из plan mode и делать задачу.
• NEEDS_REVISION — Claude обязан принять или явно отклонить каждое замечание, потом обновить план.
• Максимум 3 цикла. Если после трёх раундов агенты всё ещё спорят, я хочу видеть короткую историю разногласий и финальное решение, а не бесконечный пинг-понг.

Где это реально помогает

Я не включаю двойное ревью на каждую запятую. Оно полезно там, где цена ошибки выше стоимости лишних 2-5 минут.

• Архитектура и рефакторинг. Например, когда вы просите агента не “подчистить код”, а сначала сделать ревью без изменений. Для этого у меня есть отдельный разбор: промпт для улучшения архитектуры кодовой базы.
• Прод-деплой и миграции. Второй агент хорошо ловит “а что если redirect/cache/env var уже не такой”. Особенно когда первый агент слишком уверенно пошёл менять файлы.
• SEO-страницы и контентные кластеры. Один агент пишет страницу, второй проверяет intent, внутренние ссылки, FAQ, canonical и отсутствие воды.
• Работа со skills/MCP. Когда вы меняете инструкции агента, легко случайно сделать их длиннее, но хуже. Тут полезен отдельный ревьюер. Я подробнее писал, как не ломать skills, в статье про ошибки в Claude Code skills.
• Проекты с большим контекстом. Obsidian, GBrain, заметки, спеки, старые решения. Второй агент помогает не забыть, что надо сначала поискать уже сохранённые факты, а не изобретать новый план.

Где не надо

Для мелких задач двойное ревью превращается в бюрократию. Исправить typo, поменять ссылку, добавить один paragraph, обновить alt у картинки — обычно не надо гонять через Codex.

Ещё одна ошибка: просить второго агента “оценить качество” без входных данных. Он начнёт философствовать. Нормальное ревью начинается не с мнения, а с артефакта: план, diff, тесты, список ограничений, кусок документации.

Как не превратить это в спор агентов

Мой рабочий принцип: Claude остаётся исполнителем, Codex — ревьюером. Codex не должен переписывать задачу с нуля, если для этого нет сильной причины. Его работа — найти риски, пропущенные кейсы и более простой путь.

Если мнения конфликтуют, я не выбираю “какой агент умнее”. Я превращаю конфликт в проверку:

• прочитать конкретный файл;
• запустить тест;
• сделать маленький proof-of-concept;
• проверить официальную документацию;
• сузить задачу до одного diff.

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

Как это вписывается в мой сетап

Сейчас я смотрю на двойное ревью как на один слой в личной AI-инфраструктуре. Есть Claude Code setup, где агент получает инструменты через MCP, hooks и skills. Есть переход между Claude Code и Codex, где я разбирал, зачем вообще держать оба инструмента. Есть GBrain и общий контекст компании, где важна память проекта, а не длинный чат.

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

FAQ

Нужен ли MCP, чтобы сделать двойное ревью?

Нет. MCP просто делает флоу удобным: Claude может вызвать Codex как инструмент и получить структурированный ответ в той же сессии. Без MCP можно открыть Codex CLI во второй вкладке и вручную отправлять туда план или diff.

Это ускоряет работу?

Маленькие задачи — нет, замедляет. Большие задачи — часто ускоряет весь цикл, потому что меньше переделок после первого прохода. Особенно когда речь про деплой, миграции, сложный контент или изменения в инструкциях агента.

Какие вопросы задавать агенту-ревьюеру?

Самые полезные вопросы скучные: где план неполный, что сломается, какие граничные случаи пропущены, какие проверки нужны, где можно сделать проще. Чем конкретнее вход, тем меньше универсального слопа на выходе.

Мой вывод простой: двойное ревью — не “два AI лучше одного” по умолчанию. Это предохранитель для задач, где первый агент может уверенно не заметить собственную ошибку. Я оставляю его для планов, архитектуры, прод-деплоев и материалов, которые потом будут жить в поиске.