Разделение ответственности между Claude и Codex

Go-разработчик, ведущий собственный проект, столкнулся с типичной проблемой соло-разработчика: в течение недели приходится переключаться между Go-бэкендом, SQL, React, TypeScript, дизайном API, архитектурой, Docker, CI/CD, инфраструктурой, тестами и UX. Держать все эти области в голове одновременно невозможно, а контекст-свитчинг стоит дорого. ИИ помогает, но возникает спор: какая модель лучше — Claude или Codex? Автор решил не выбирать и развёл роли: Claude принимает решения, Codex реализует, Claude независимо проверяет результат.

Ключевая идея в том, что одна модель, выполняющая все роли — от постановки задачи до проверки собственной работы, — неизбежно страдает от отсутствия внешнего контроля. Модель защищает своё решение, даже когда видно, что подход неудачный; «тесты проходят» становится доказательством корректности, хотя тесты писала та же модель из тех же предположений; отчёт о выполнении не равен выполнению, а контекст размывается к концу длинной сессии. Это не проблема конкретных моделей, а отсутствие процесса: человек, который сам пишет требования, код, тесты и ревьюит себя за пять минут до релиза, даст тот же результат.

Схема автора выглядит так: Claude выступает tech lead — разбирает задачу, лезет в репозиторий, формулирует требования и ограничения, принимает архитектурные решения, пишет PLAN.md с проверяемыми критериями приёмки, затем читает diff и решает, принята работа или нет. Codex — исполнитель: реализует утверждённый план, пишет и правит тесты, делает рефакторинг задачи, исправляет найденное на ревью. Ключевое правило: Claude не делегирует Codex архитектурные решения и приёмку, а Codex не переопределяет план по ходу дела.

Проверка двусторонняя: Codex проверяет Claude до реализации, читая PLAN.md в read-only и пытаясь его сломать, — это дёшево, кода ещё нет. Claude проверяет Codex после, читая diff и сверяя с критериями. Каждая модель попадает под независимый взгляд там, где её ошибка стоит дороже всего: у Claude это неверно понятое требование, у Codex — реализация, разошедшаяся с планом. PLAN.md здесь — письменный контракт, который нельзя незаметно переформулировать в середине разговора.

Автор работает на macOS с VS Code, локально стоят Claude Code, Codex CLI, расширения для VS Code и официальный OpenAI-плагин codex-plugin-cc для Claude Code, который позволяет делегировать работу локальному Codex без кастомной настройки MCP. VS Code удобен тем, что оба агента видят один репозиторий, изменения сразу в редакторе, git diff и терминал рядом. Но схема не требует именно VS Code — всё работает из CLI.

Что подход даёт на практике: модели проверяют друг друга, токены тратятся осмысленнее (дорогое рассуждение — на требования, архитектуру и ревью; чтение кода, boilerplate и тесты — на более экономичного исполнителя), а качество растёт не за счёт бюджета. Дефекты, которые ловит схема, — это не «модель недостаточно умная», а «никто не сверил результат с требованиями». Это чинится процессом, а не более дорогой моделью.

Автор честно перечисляет, что подход не решает: он не заменяет понимание предметной области, не избавляет от необходимости формулировать требования, и требует дисциплины в следовании процессу. Но для соло-разработчика, который хочет усилить обе модели, а не выбирать одну, это рабочий вариант.