Разделение ответственности между Claude и Codex: как я перестал выбирать одну нейросеть и усилил сразу две

Я Go-разработчик, но у меня есть собственный проект — и это значит, что Go только часть работы. В обычную неделю я переключаюсь между Go-бэкендом, SQL, React и TypeScript, дизайном API, архитектурой, Docker, CI/CD, инфраструктурой, тестами и UX.

Проблема не в том, что я чего-то из этого «не знаю». Невозможно держать все эти области в голове одновременно и при этом в одиночку делать продукт целиком. Контекст-свитчинг стоит дорого сам по себе.

AI помогает. И примерно здесь у всех начинается один и тот же спор: Claude или Codex? Кто лучше пишет код, за какую подписку платить.

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

задача → нейросеть сама придумала → сама написала → сама себя проверила → сказала, что всё готово

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

Поэтому я перестал выбирать и развёл роли: Claude принимает решения. Codex реализует. Claude независимо проверяет результат.

Это дало три вещи, а не одну:

1. Модели проверяют друг друга. Codex до реализации разносит план Claude, Claude после реализации читает diff Codex. Ни одна не подписывает собственную работу.

2. Токены тратятся осмысленнее. Дорогое рассуждение — на требования, архитектуру и ревью; чтение кода, boilerplate и тесты — на более экономичного исполнителя.

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

Дальше — как это устроено, как повторить, полный skill и честный список того, что подход не решает.

Почему не «одна модель на всё»

Когда сравнивают Claude и Codex, их обычно ставят на одну и ту же роль: кто напишет функцию лучше. Ответ всегда получается «зависит от задачи», и он бесполезен.

Мне в рамках одной задачи нужны три разные функции: решить (требования, границы изменений, подход, критерии), сделать (прочитать много кода, вписаться в конвенции, реализация и тесты) и проверить (сверить diff с тем, что было заявлено). У них разная цена ошибки, разный объём, и третья требует независимости от того, кто делал вторую.

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

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

• «Тесты проходят» становится доказательством корректности. Хотя тесты писала та же модель из тех же предположений: неверное предположение тест не поймает, а закрепит.

• Отчёт о выполнении не равен выполнению. «Реализовано, всё работает» встречается и там, где часть требований потерялась по дороге.

• Контекст размывается. К концу длинной сессии требования уже переформулированы самой моделью, и не в лучшую сторону.

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

Разделение ролей

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

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

Ключевое правило: Claude не делегирует Codex архитектурные решения и приёмку, Codex не переопределяет план по ходу дела.

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

И PLAN.md здесь — письменный контракт, который нельзя незаметно переформулировать в середине разговора.

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

Стек и модели

Работаю на macOS, основной редактор — VS Code. Локально стоят Claude Code, Codex CLI, расширения Claude и Codex для VS Code и официальный OpenAI-плагин codex-plugin-cc для Claude Code — именно он позволяет Claude делегировать работу локальному Codex без кастомной настройки MCP. (К Codex, кстати, можно подключиться и по MCP прямо локально — такая возможность есть.)

VS Code удобен тем, что оба агента видят один репозиторий, изменения сразу в редакторе, git diff и терминал рядом, и не надо копировать куски проекта в браузерные чаты. Но схема его не требует — всё работает из обычного терминала. Это просто мой рабочий интерфейс, настроенный за годы под себя.

Рабочая конфигурация:

• Claude: Opus / high — решения, план, ревью, приёмка

• Codex: GPT-5.6 Terra / high — реализация, тесты, фиксы

Opus / high отвечает там, где ошибка дороже всего: понимание задачи, границы изменений, архитектурный выбор, критерии приёмки, проверка diff. Здесь важно удерживать связи между частями системы и различать «работает» и «корректно».

Terra / high отвечает за объём: прочитать много кода, вписаться в конвенции, написать реализацию и тесты, прогнать проверки. Это большая механическая работа с уже готовой спецификацией.

Terra / xhigh поднимаю для действительно сложного: concurrency, распределённые системы, нетривиальная работа с БД, миграции, сложный root-cause debugging, крупный взаимосвязанный рефакторинг. Sol — только escalation, когда Terra реально не справляется или цена ошибки особенно высока. Держать максимум везде смысла нет: дороже и медленнее, а на типовой реализации по готовому плану качество заметно не растёт.

Sonnet использую, когда хочется и есть возможность сэкономить, но минимум — Sonnet / high. Начиная с medium он критично пропускает контекст кода и смысла; выяснил на личном тестировании, особенно заметно в большом репозитории, где изменение затрагивает несколько слоёв. Экономия оказывается ложной: дальше идут дополнительные итерации и правки того, что было упущено.

Отсюда главный практический вывод: high — минимально комфортный reasoning для разработки на экономичных моделях. На пониженных режимах я стабильно получал пропущенные связи между файлами, игнорирование конвенций репозитория, поверхностные тесты на happy path и необходимость объяснять одно и то же по второму кругу. Каждая такая итерация — ещё один полный проход по контексту плюс моё время.

Это не касается Sol и Fable: они нормально отрабатывают и на medium, но для постоянной работы требуют дорогих тарифов. А зачем платить больше, если можно платить меньше? =)

Установка

Claude Code:

npm install -g @anthropic-ai/claude-codeclaude --version

или плагин для IDE.

Codex CLI:

Cтавится отдельно и должен быть доступен как codex в PATH (codex --version). Актуальные команды установки обоих инструментов лучше сверить с официальной документацией — они меняются.

Плагин codex-plugin-cc — внутри claude:

/plugin marketplace add openai/codex-plugin-cc/plugin install codex@openai-codex/reload-plugins/codex:setup

актуальную информацию лучше смотреть тут->

Появятся команды /codex:review, /codex:adversarial-review, /codex:rescue, /codex:status, /codex:result. Ими можно пользоваться вручную, но смысл skill ниже ровно в том, чтобы не оркестрировать это руками при каждой задаче.

Дефолтный worker — в ~/.codex/config.toml:

model = "gpt-5.6-terra"model_reasoning_effort = "high"

Стоит по-умолчанию в нынешнем релизе codex

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

Skill cdx

Skill описывает весь процесс: кто за что отвечает, как исследовать репозиторий, как писать PLAN.md, как запускать adversarial review, как вести builder-thread, как ревьюить diff и принимать работу.

Я назвал /cdx, просто потому что мне так удобно. Это локанично, удобно писать каждый раз, не перекликается с другими скиллами, логически понятно. Вы можете назвать как вам угодно.

Создаём папку скилла для claude:

mkdir ~/.claude/skills/cdx

Потом в нём добавляем сам файл со скиллом, который будет использовать claude:

Дальше создать в папке ~/.claude/skills/cdx/ файл SKILL.md и положить туда следующее целиком:

---name: cdxdescription: Claude leads software development while Codex implements. Claude owns requirements, architecture, review and final acceptance.disable-model-invocation: true---# CDXClaude is the lead engineer.Codex is the implementation worker.## OwnershipClaude owns:- understanding the task- requirements- architecture- planning- technical decisions- acceptance criteria- review- final approvalCodex owns:- implementation- tests- necessary refactoring- fixes requested during reviewClaude must not delegate final architectural decisions or acceptance to Codex.Do not write substantial implementation code yourself while CDX is active.## 1. InvestigateBefore asking the user questions, inspect the repository.Read relevant:- CLAUDE.md- AGENTS.md- README- manifests and build configuration- related implementation- tests- git status- current diffUse read-only repository exploration when useful.Do not ask questions whose answers can reasonably be found inside the repository.Ask the user only when ambiguity materially affects:- behavior- architecture- public API- data model- security- compatibility- destructive behavior- task scopeFor minor reversible implementation choices, choose a reasonable default.## 2. PlanFor non-trivial tasks create PLAN.md.Keep it short.Structure:# Goal# Requirements# Non-goals# Constraints# Acceptance criteria# Implementation plan# VerificationAcceptance criteria must be observable and independently verifiable.## 3. Challenge the planFor non-trivial changes, run one independent Codex planning review before implementation.Use the installed codex-plugin-cc and its Codex delegation capabilities.Start a fresh Codex task.The planning review must be READ-ONLY.Default:- model: gpt-5.6-terra- effort: high- fresh task- read-onlyAsk Codex approximately:"Read PLAN.md and inspect the relevant repository context.This is a READ-ONLY adversarial planning review.Do not modify files.Do not implement the task.Challenge the plan.Look for:- misunderstood requirements- unnecessary complexity- missing edge cases- architectural conflicts- compatibility problems- security risks- concurrency problems- data-integrity risks- migration and rollback risks- missing tests- simpler solutionsReturn only meaningful findings.Classify each as:BLOCKERMAJORMINORFinish with:VERDICT: APPROVEor:VERDICT: REVISE"Claude evaluates every finding independently.Codex is an advisor, not the authority.Revise PLAN.md only for findings Claude considers valid.Do not perform a fixed number of planning review rounds.One adversarial review is normally enough.## 4. BuildAfter PLAN.md is approved, start a NEW fresh Codex implementation task.Use codex-plugin-cc.Default:- model: gpt-5.6-terra- effort: high- write enabled- freshThis task becomes the persistent builder thread.Tell Codex:"Implement the approved PLAN.md.PLAN.md is the implementation contract.Rules:- inspect repository conventions before editing- follow AGENTS.md when present- preserve all pre-existing user changes- stay inside scope- prefer the smallest coherent implementation- do not redesign unrelated code- add or update tests where appropriate- run relevant tests, builds, linters and static checks- do not commit- do not push- do not deploy- do not modify secrets- do not weaken tests merely to make them passWhen finished report:1. changed files2. implementation summary3. tests/checks executed4. failures or limitations5. assumptions"## 5. ReviewNever trust Codex's completion report as proof of correctness.Claude independently inspects:- git status- complete relevant diff- changed files- added or changed tests- verification resultsCompare the implementation directly with PLAN.md.Check:- requirements- every acceptance criterion- correctness- edge cases- error handling- security- authorization- validation- compatibility- concurrency- race conditions- resource leaks- transaction boundaries- data integrity- unnecessary complexity- repository conventions- test quality- accidental unrelated changesClaude is the quality gate.Do not approve merely because tests pass.Do not approve merely because Codex reports success.## 6. FixIf Claude finds problems, continue the SAME Codex builder task.Do not start a new builder thread.Resume the existing Codex task.Send only concrete verified findings.Prompt approximately:"Continue the existing implementation.Fix only these verified review findings:...For every finding:1. identify the root cause2. make the smallest correct fix3. add or update a regression test when appropriate4. rerun relevant verificationDo not expand scope.Do not rewrite unrelated code."After Codex finishes, Claude reviews the new diff again.Repeat only while real issues remain.## 7. EscalationDefault Codex configuration:gpt-5.6-terra / highUse Terra xhigh for genuinely difficult:- concurrency- distributed systems- database correctness- migrations- complex debugging- large interacting refactorsUse gpt-5.6-sol only when:- Terra repeatedly fails- correctness is unusually critical- stronger reasoning is clearly justifiedDo not escalate ceremonially.Do not use maximum reasoning by default.If the same substantive defect survives two meaningful fix attempts,stop repeating the same instruction.Re-investigate the root cause and reconsider PLAN.md.## 8. AcceptanceBefore approval, explicitly check every PLAN.md acceptance criterion.Each criterion must be:PASSFAILorNOT VERIFIEDApprove only when required criteria PASS and no known BLOCKER or MAJOR correctness issues remain.## 9. FinishReturn a concise result:### BuiltWhat changed.### ReviewImportant problems found and returned to Codex.### VerificationTests, builds, linters and checks performed.### ResultAPPROVEDorAPPROVED WITH CAVEATSorNOT APPROVED### Remaining risksOnly actual unresolved limitations or risks.## EfficiencyThe goal is not maximum agent activity.Prefer:- one good specification- one PLAN.md- one adversarial planning pass- one persistent Codex builder thread- focused fix iterations- one independent Claude acceptance gateDo not:- ask questions answerable from the repository- perform fixed review rounds- start fresh Codex threads for every fix- escalate models without evidence- use multiple agents when one is enoughCore rule:Claude decides.Codex implements.Claude verifies.

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

Три решения внутри, которые я считаю принципиальными:

1. disable-model-invocation: true — skill запускается только явной командой /cdx, а не когда модель сама решит, что пора звать Codex.

2. Один persistent builder thread — исправления по ревью идут в ту же Codex-задачу. Новый thread теряет контекст реализации и чинит симптом вместо причины.

3. Число итераций не фиксировано. Ни «ровно три раунда ревью», ни «ровно два adversarial-прохода»: модель, которую попросили что-то найти, обязательно что-нибудь найдёт. Плюс стоп-правило: если один дефект пережил две осмысленные попытки починки — возвращаться к причине и к PLAN.md, а не повторять инструкцию третий раз.

Запуск и пример

claude

Внутри: /model opus или sonnet, /effort high, затем /cdx и постановка задачи на уровне требования, а не техзадания:

/cdxДобавь в кабинет пользователя историю фоновых задач.Backend API уже существует.Нужно показывать: активные задачи, завершённые, прогресс, ошибку выполнения.Активные задачи должны обновляться автоматически.При действиельной и подтвержденной необходимости можно использовать подходящие скиллы и агентов для улучшения качества результат, эффективности и производительности.Спроси меня какие подходят списком, я выделю какие применить.

Дальше — как проходит один цикл. Стек в примере: Go на бэкенде, React + TypeScript на фронте. Эндпоинты, имена и findings ниже иллюстративные — они показывают форму процесса, а не мой реальный код.

1. Claude читает репозиторий, а не задаёт вопросы: существующий API задач, типы, routing, похожие страницы, принятый подход к загрузке данных, тесты. Вопрос ко мне остаётся один — за какой период показывать историю (это влияет на API и UX, из кода не выводится).

2. Claude пишет PLAN.md:

# GoalСтраница «Фоновые задачи»: активные и завершённые задачи с прогрессом и причиной ошибки.# Requirements- активные задачи с индикатором прогресса- завершённые (успех/ошибка) за 30 дней, для упавших — текст ошибки- обновление активных без перезагрузки страницы- состояния загрузки, пустого списка и недоступности бэкенда# Non-goals- отмена и перезапуск задач, пагинация, изменения backend API# Constraints- существующий API: GET /api/tasks, GET /api/tasks/stream (SSE)- React + TypeScript, существующий api-client, новых зависимостей не добавлять# Acceptance criteria1. Роут /account/tasks доступен из меню кабинета.2. Прогресс активных задач берётся из потока обновлений.3. Упавшая задача показывает текст ошибки из API.4. При обрыве потока UI переходит в состояние «обновления недоступны» и переподключается.5. Одновременно открыто не более одного потока обновлений.6. Пустой список — пустое состояние, а не бесконечная загрузка.7. Тесты: рендер списков, состояние ошибки, обрыв потока.# Implementation planтипы → api-client → хук подписки → компоненты → страница и роут → тесты# Verificationunit-тесты, typecheck, линтер, ручная проверка на активной и упавшей задаче

3. Codex делает read-only adversarial review плана:

MAJOR: не определено поведение при разрыве SSE-соединения.План описывает получение обновлений, но не реакцию UI на разрыв,стратегию переподключения и предотвращение дублей.VERDICT: REVISE

Это резюме аудита, оно не носит характер требования — Claude оценивает каждое замечание сам. Здесь я согласен: обрыв SSE в проде случается регулярно, а в разработке не воспроизводится. Из этого замечания и появились критерии 4 и 5 выше.

4. Terra реализует в новой Codex-задаче с правами на запись — это и есть persistent builder thread. PLAN.md передаётся как контракт.

5. Opus читает diff, а не отчёт Codex. Пример находки:

MAJOR: логика переподключения может открыть два SSE-соединения.Обработчик onerror инициирует переподключение, предыдущее соединениеявно не закрывается, очистка срабатывает только при размонтировании.При кратковременной сетевой ошибке получаем два активных подписчика.Нарушен acceptance criterion 5.

Это ровно та категория дефектов, которую не поймают ни тесты (они не эмулируют флап сети), ни отчёт исполнителя (с его точки зрения всё реализовано).

6-7. Замечание уходит в тот же thread, Terra чинит корневую причину и добавляет регрессионный тест, который эмулирует ошибку соединения и проверяет, что подписка ровно одна.

8. Opus проверяет критерии явно, по списку:

1. Роут и пункт меню                   PASS2. Прогресс активных задач             PASS3. Текст ошибки упавшей задачи         PASS4. Явное состояние при обрыве потока   PASS5. Не более одного потока              PASS (regression test добавлен)6. Пустое состояние                    PASS7. Тесты                               PASSRESULT: APPROVEDRemaining risks: переподключение проверено только в тестах,поведение при длительной недоступности бэкенда вручную не проверялось

Раздел «Remaining risks» считаю обязательным: APPROVED без списка непроверенного — это APPROVED, которому не стоит верить. Дальше diff смотрю уже я.

Экономика

Я не утверждаю, что это дешевле в каждом отдельном запросе — запросов тут больше, чем в обычном диалоге. Экономия появляется на распределении:

• Opus: требования, архитектура, решения, review.

• Terra: чтение кода, реализация, boilerplate, tests, fixes.

Основной объём токенов в разработке — это не «придумать», а прочитать половину репозитория, написать десять файлов, обновить тесты и починить то, что не собралось. Этот объём уходит исполнителю, у которого уже есть спецификация. Дорогая модель не пишет каждую функцию и каждый React-компонент, а делает то, где её преимущество реально проявляется.

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

Чего я не делаю

Оркестрацию можно переусложнить не хуже микросервисов. Я сознательно не использую десяток subagents, пять моделей-ревьюеров, фиксированные пять итераций, максимальный reasoning везде, отдельный MCP-слой поверх уже установленного плагина и автоматический бесконечный Claude ↔ Codex loop.

Каждый лишний участник — это ещё одна передача контекста, на которой что-то теряется. Обязательный третий раунд ревью без замечаний порождает выдуманные замечания. А бесконечный автоматический loop без человека, который скажет «здесь достаточно», не сходится — два агента способны долго улучшать друг друга, уходя от исходной задачи.

Плагин Superpowers

Отдельно про плагин Superpowers: он у меня установлен, но частью cdx не является. Понятная инженерная задача → /cdx. Сырая идея, где сначала надо понять, что вообще строить → brainstorming, и уже его результат становится входом для /cdx. Есть похожий скилл grill-me, но с Claude, как мне показалось, работает лучше Superpowers: brainstorming. На задачах, например, маркетинга или написания сценария для контента, мне понравился больше grill-me, но и специфика чуть-чуть иная.
За поиском новых идей лучше вообще идти в скилл llm-council.

Что это не решает

• AI регулярно пишет ерунду — и Claude, и Codex. Разделение ролей повышает шанс, что её заметят до попадания в репозиторий, но не гарантирует.

• PLAN.md не гарантирует хороший код. Плохой план даёт аккуратно реализованное плохое решение.

• Второй агент тоже ошибается. Adversarial review возвращает и ложные findings — принимать их не думая значит ухудшить план.

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

• Ревью человеком остаётся обязательным. APPROVED от Claude — фильтр, а не подпись под релизом.

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

Итоги

Исходный вопрос «Claude или Codex» я в итоге не решил — я его снял. Обе модели остались, но каждая работает на своей роли и под контролем другой. Однако снял не до конца кто за какую роль отвечает. На данный момент Claude мне нравится как планировщик, а Codex как исполнитель. Возможно это изменится в будущем.

Что это дало: несогласованность требований всплывает на этапе PLAN.md, а не на этапе diff; появился письменный контракт задачи; ревью перестало быть формальностью, потому что проверяющий не автор кода; проще переключаться между областями, потому что решения и объём работы разведены по разным шагам.

Чего не дало: волшебства. Мне по-прежнему нужно понимать, что происходит в системе, читать финальный diff и отвечать за результат.

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