The Architect and the Coder

Most of the conversation about AI agents treats “the agent” as one thing: a single worker you hand a job to. In my setup it is two things, and keeping them apart is most of why it works.

There is an architect and there is a coder. The control plane is the architect: it holds the big picture, triages what matters, decides what to do next, and writes the contract for the work, which is the build prompt. The coding agent, Claude or Codex, is the coder: it takes that contract and executes against it. One side decides what should happen and why. The other makes it happen.

This is not a new idea. It is separation of concerns, the oldest move in software design, pointed at LLMs, and the reasons to do it are the reasons we have always done it. The two jobs need different things. The architect needs context, judgment, and room to be slow and careful. The coder needs a clear task and tight constraints, and it benefits from being fast, cheap, and swappable. Fuse them into one agent that plans and builds in the same breath and you have rebuilt the monolith, with the same old problems: no clean place to review the plan before it runs, no way to swap the executor, no record of the decision that is separate from the doing.

The contract is what makes the split real. The build prompt is the interface between the architect and the coder, and like any good interface it buys you things. Because what the architect hands down is a written contract, you can change executors, Codex today and something else tomorrow, and the architect does not care. The coder still reads the shared design context, the CLAUDE.md and the architecture, so its small local decisions account for the whole; what it does not own is the decision about what to build. That decision is the contract, and the contract is portable, so the next executor inherits the same context and picks up where the last one left off. Because the contract is written down before the work runs, you can review the intent on its own, and you can debug the instruction when the result comes back wrong. Because the deciding and the doing are separate records, “who decided this” and “who built it” become two answerable questions instead of one blurry one.

It also lets the roles have different economics, which matters most when I am running several at full tilt. The architect can run on a careful, expensive model, because it runs less often and a bad plan is costly. The coder can run on whatever clears the bar, and how cheap that is depends on the task: a junior-coder job on a low-stakes change, a more careful model when the stakes are higher. You route the model to the role, and to the stakes.

This is the institutional version of the argument, too. Organizations that ask one person, or one team, or one system to both set direction and execute it tend to do both badly. The fix in a company is the same as the fix here: name the roles, write down the handoff, and let each side be good at its own job. The control plane is that idea turned into infrastructure.

The first design question I ask of any agent now is not what it should do. It is what it should stop being responsible for.