Two Agents, One Engineer: How I Run Claude and Codex Together

Most people I talk to treat AI coding tools as an either/or decision — you're a "Claude person" or a "Codex person". I stopped picking about a year ago. Today I run Claude Code and Codex side by side, as coworkers, and the combination has quietly become the biggest multiplier in how I ship — across Sipo POS products at work, freelance client sites, and personal builds like FinPlanner and OnSite Tracker.

This post is about the actual workflow: how I plan, how I split work between the two agents, and where I deliberately keep humans (me) in the loop.

Why two agents instead of one

Two agents don't just double throughput — they change the shape of the work.

• Different perspectives catch different bugs. The same diff reviewed by two models surfaces different problems. One flags an architectural smell, the other catches an edge case in date handling. It's the cheapest code review panel you'll ever assemble.
• Parallelism becomes real. While one agent is deep in a refactor, the other can be scaffolding an unrelated feature, chasing a flaky test, or drafting a migration. I stop being the bottleneck on typing and become the bottleneck on decisions — which is where an engineer should sit.
• No single point of style. Each model has habits. Alone, those habits leak into your codebase unchecked. Together, they keep each other (and me) honest.

My planning style: plan first, type never

Whatever the task, the workflow starts the same way — a written plan before any code. I'll open Claude in plan mode, describe the outcome I want, and push back on the plan until it reads like something I'd hand a teammate:

1. State the outcome, not the steps. "Guests should be able to reorder their last meal in two taps" — not "add a button to the order page."
2. Make the agent enumerate the files it will touch. If the list surprises me, the plan is wrong or my mental model is — either way, better to find out now.
3. Agree on what won't change. Scope creep from an eager agent is real. The plan explicitly names the things to leave alone.

Only when the plan survives my questions does anyone — human or agent — write code. For bigger features I keep the plan as a markdown file in the repo, so both agents (and future me) work from the same source of truth.

How I split the work

The split isn't "Claude does X, Codex does Y" — it's role-based, and the roles rotate:

• Builder — one agent owns the implementation for a task. It gets the plan, the constraints, and the freedom to work through the details.
• Reviewer — the other agent reviews the diff cold, with no context beyond the plan. Cold review matters: an agent that watched the code being written will rationalize it the same way its author did.
• Scout — whoever is idle gets the exploratory jobs: "find every place we format currency", "check which client sites still use the old menu API", "reproduce this bug and tell me the failing path."

A typical afternoon on the Sipo ecosystem looks like: Claude building a new ordering-flow feature in one terminal, Codex reviewing yesterday's branch in another, and me switching between them like a tech lead doing desk check-ins — reading diffs, answering questions, making the judgment calls.

The rules that keep it sane

Running two agents without discipline just produces mess at twice the speed. These are my non-negotiables:

• One branch per agent, always. Two agents in one working tree is how you lose an afternoon. Worktrees are cheap; confusion isn't.
• Agents propose, I merge. Nothing lands on main that I haven't read. The point is leverage, not abdication.
• Verify in the real app, not just tests. Every UI change gets exercised in the browser before it ships — agents are great at making tests pass and occasionally great at making tests meaningless.
• Small, named tasks. "Fix the checkout" is a prompt for chaos. "Order total ignores the delivery fee when a promo code is applied — fix and add a test" is a prompt for a clean diff.
• Write down what worked. Both tools support persistent project context (CLAUDE.md and friends). Every correction I make twice goes in there once.

Where each one shines for me

After months of daily use, some patterns are consistent. I lean on Claude Code for multi-file architectural work, long refactors, and anything where taste matters — component APIs, naming, the shape of a data model. Its plan mode is also where most of my thinking happens now. I reach for Codex when I want fast, focused execution on a well-defined task, a second opinion on a gnarly diff, or parallel grunt work cleared out while Claude is mid-refactor.

But honestly — the specific assignment matters less than the structure: plan → build → cold review → human merge. That loop works regardless of which logo is on the terminal.

What this changed about my job

The surprising part isn't the speed, though the speed is real — this portfolio, the OnSite Tracker product, and a steady stream of Sipo client sites all shipped alongside a full-time job. The surprising part is what my time is spent on now: reading, deciding, and directing instead of typing.

That's not a smaller job. It's the senior half of the job, sooner. The agents handle the mechanical middle; the intent at the start and the judgment at the end are still mine — and sharpening those two ends is, I think, the most durable career investment an engineer can make right now.