I Don't Use Claude Code Alone — Splitting Work With codex
Claude designs and verifies, codex implements. Splitting the work across two AIs avoids the trap of one model writing and the same model approving. A solo maker's real workflow.
Most people assume you do all your coding with Claude Code alone. I don't. I run two AIs and split the work between them: Claude Code and codex. Claude is the head that designs and verifies; codex is the hands that write the code.
At first I did everything with one. But the more things I built solo, the more one problem repeated. When one model writes the code and the same model says "looks good," it misses what's wrong — the way you can't catch typos in your own writing. So I split the roles.
Why split it in two
Two reasons.
1. Role separation. Designing and implementing use your head differently. Do both in one flow and either the design gets sloppy or the implementation wanders. Claude decides "what to build and how"; codex turns that into actual code. Separating the head from the hands made both cleaner.
2. Independent cross-checking. This one matters more. Claude verifies codex's code with a build and a type check. Same for facts in writing — codex re-checks, with a different engine, what Claude wrote. Because a different model verifies the other one's output, it catches what a single model would miss.
The actual split
| Job | Who |
|---|---|
| Planning / design (plan mode) | Claude |
| Writing the implementation spec | Claude |
| Generating the actual code | codex |
| Build / type-check verification | Claude |
| Integrating the code | Claude |
| Fact-checking writing & content | codex (independent cross-check) |
The key is that codex writes the implementation code itself. Claude writes a precise "build it like this" spec, codex turns it into code, and Claude checks whether that code actually runs.
How it actually runs
Building this very blog is the exact example.
- Get a plan from Claude. What to build, which files are needed, which existing patterns to reuse.
- Claude writes the spec. "Build this file like this. Follow this pattern, respect these constraints" — concretely.
- codex implements. It takes the spec and generates the actual code.
- Claude verifies. Runs the build and type check to confirm it really works, and fixes what doesn't.
Fact-checking runs separately too. Even this post gets one more independent pass from codex — checking whether what I wrote convincingly is actually true, through a different engine's eyes.
What I hold to when splitting
- Name the model. Specify exactly which model to run. In my experience, leaving it to defaults has let the wrong one get attached — going slow, or stalling.
- Write specs concretely. codex builds to the spec. Vague spec, vague result. Spell out the pattern to follow, the constraints to keep, and what not to touch.
- Verification stays the human's responsibility. Even with two AIs checking each other, judging "is this right" at the end is on me. Cross-checking is a guard against mistakes, not a way to hand off responsibility.
A team of one
The point isn't "two AIs, so twice as fast." It's that even alone, you can run two with different roles.
When a team has a designer, an implementer, and a verifier, the output is sturdier. You can build that structure by yourself. Give Claude the head, codex the hands, and let them verify each other.
Working alone doesn't mean working with one set of eyes.