htmlEdit

Claude and Codex as a Team: Divide the Work, Not the Context

In short: Treat Claude and Codex like two colleagues who don't share a memory. Give each a self-contained job with clear inputs and outputs, and you get more done than trying to run one giant conversation.

If you want two AI assistants to help you build something, the trick is to divide the work, not the context between them. Give Claude and Codex each a clean, self-contained job, and they get on with it. Try to run one enormous shared conversation across both and you get mush: two assistants half-aware of a problem, neither fully responsible for any part of it.

I've landed on a simple mental model. Think of them as two capable colleagues who happen to have no shared memory. Everything one knows, the other doesn't, unless you tell it. That constraint sounds like a handicap. In practice it forces you to do the one thing that makes delegation work with people too: write a brief that stands on its own.

Split along seams, not down the middle

The instinct when you have two helpers is to halve the task. Don't. Halving a task usually means slicing through the middle of a problem, and now each assistant needs the other's half to make sense of its own. That's where things fall apart.

Instead, look for natural seams. A seam is a place where the work already comes apart cleanly: the data layer and the interface, the feature and its tests, the thing you're building and the thing that checks it. When I was working on htmlEdit, a small tool for editing HTML documents by pointing and clicking rather than re-prompting, the seams were obvious once I looked. One assistant could focus on how the editing behaved on the page. The other could focus on the packaging and the plumbing around it. Neither needed to hold the whole thing in its head.

The test for a good seam: can you describe one side of it without constantly referring to the other? If yes, you've found a place to divide the work. If every sentence starts with "well, it depends on what the other part does," you're cutting through the middle, not along a seam.

Each brief has to stand alone

Once you've split along a seam, write each assistant a brief it can act on cold. State the goal, the inputs it has, the output you want, and the constraints. Don't assume it remembers a decision you made an hour ago in a different window, because it doesn't.

This feels like extra work. It is, slightly. But it's the same discipline that makes a good ticket or a good handover note, and it pays off twice: the assistant does better work, and you understand your own problem more clearly for having written it down. Half the time I catch a muddled requirement while drafting the brief, before either assistant touches it.

A rough shape I use:

  • Goal: one sentence on what done looks like.
  • Inputs: the files, data, or context it needs, pasted or pointed to directly.
  • Output: what I want back, and in what form.
  • Constraints: what not to touch, and any rules that matter.

You are the shared memory

Here's the part people skip. If the two assistants don't share context, something has to. That something is you. Your job in this setup is to hold the shared picture, reconcile what comes back, and decide what happens next, rather than to type prompts. You're the tech lead, not a relay.

That reframing changes how it feels. You stop trying to keep two conversations perfectly in sync and start treating each as a source of work you'll review and integrate. When Codex hands back one piece and Claude hands back another, the reconciling happens on your desk. Sometimes they disagree, and the disagreement is useful: it surfaces an assumption you hadn't made explicit.

The payoff is real. Small, well-scoped jobs are easier to check than one sprawling conversation where you've lost track of what was decided and when. You can hold a self-contained piece of work in your head, spot when it's wrong, and send it back with a clear correction. Try doing that across a 300-message thread and you'll miss things.

None of this depends on the specific tools. It's an operating model: divide the work along clean seams, brief each side so it stands alone, and keep the shared picture yourself. Do that, and two assistants genuinely add up to more than one. Skip it, and you've just doubled the number of conversations you can't quite follow. If you want the companion piece on choosing between them for a given job, see when to reach for each one.

Key takeaways

  • Two assistants beat one when the work splits cleanly into separate jobs.
  • The failure mode is a bloated shared context nobody can hold, not the models.
  • Hand each assistant a brief it can act on without the other's history.
  • Reconcile the outputs yourself; you're the shared memory.
  • Small, well-defined tasks are easier to check than one sprawling one.