Claude Thinks, Codex Types: How I Build and Debug Apps With Two AIs

I don't write much code by hand anymore. Not because I can't. I've spent about 25 years around electronics and software. It's because I found a division of labour between two AI models that ships working software faster than I can type, and I want to walk through exactly how it works.

The short version: one model plans and reviews, the other writes the code, and a small piece of custom plumbing connects them. The interesting part isn't the idea. It's the two or three unglamorous lessons that took the setup from "impressive demo" to "actually usable every day."

The division of labour

Most people reach for a single AI to do everything: plan, code, debug, explain. It works, but it's mediocre at all of them at once, and it burns through context fast.

I split the job in two.

Claude is the architect. It takes the idea or the bug, thinks through the approach, and writes a precise specification. Not a vague description, but something close to a build sheet: file structure, explicit constraints, the actual code where it matters, and acceptance criteria. When something breaks, Claude is also the one that reasons about root cause. It's the part of the system that thinks.

Codex is the builder. It takes that spec and writes the code. It runs on a dedicated workstation, edits the files, and does the mechanical work of turning a specification into a running application. It's the part of the system that types.

The principle that falls out of this is simple enough to put on a sticker: Claude thinks, Codex types. Keeping those two jobs separate is most of the reason the whole thing works.

How the two connect

For Claude to hand work to Codex, they need a channel. I built one using MCP, the Model Context Protocol, which lets an AI call external tools in a structured way.

The bridge exposes 19 tools grouped by function: running jobs (in the foreground or the background), managing those jobs, reading and writing files, checking git diffs, a review loop for going through pages one at a time, and session save and load. Claude calls these tools the way a developer would call a library.

The most used tool is the one that fires a build job in the background. Claude sends the spec, the job runs on the workstation, and the chat isn't blocked waiting for it. That single detail, asynchronous jobs, is what makes the loop feel fast instead of laggy.

I won't pretend the connection is elegant. It's a chain of small pieces: the desktop app, a bridge script, a tunnel, a socket, and a persistent process on the workstation. Which brings me to the first lesson.

Lesson one: the failure you plan for isn't the one you get

I built the workstation process to be persistent, managed by a process manager, so it survives crashes and reboots. I assumed that was the fragile part.

It wasn't. The process almost never dies.

The thing that actually drops is the tunnel between my laptop and the workstation. A network blip, the laptop sleeping, a socket timing out. When the tools suddenly vanish mid session, the instinct is to go restart the "server." Wrong layer. The server is fine. It's the connection that's gone, and the fix is to reload the tunnel, not touch the process at all.

The lesson generalises well beyond this setup: when a distributed system fails, suspect the link before the endpoints. The thing you hardened is rarely the thing that breaks. It's the quiet connective tissue in the middle.

Lesson two: don't drag the whole payload back into the room

This is the one that nearly killed the workflow, and fixing it is what made it economical.

Early on, when a Codex job finished, I'd have Claude pull the full result back to check it. That result included everything: file diffs, template contents, entire streams of build output. Every check dragged a wall of text back into Claude's context. It was slow, it was expensive, and most of what came back was noise. I was moving a filing cabinet across the room to read one sticky note.

The fix was a rule I now call the Job Summary Protocol. Every Codex job, as its final action, writes a tiny structured summary to a known location. Four fields, nothing more:

• status: did it work or not

• files_changed: paths only, no contents

• errors: one line each, if any

• notes: one sentence, maximum

No diffs. No file dumps. No essays. Claude reads that small summary instead of the raw output. If the status is clean, it moves on. Only if something errored does it dig deeper, and even then, deliberately.

The important move was making this automatic. I wrote the protocol into the coding agent's standing instructions, so it applies to every job without me adding it to each prompt. The behaviour is now the default, not something I have to remember.

The result is that the heavy output stays where it's produced, on the workstation, and only compact summaries ever cross into the conversation. Small context means fast, cheap, and repeatable. Those are the three things that separate a party trick from a tool you use every day.

What the debug loop actually looks like

Debugging follows the same shape. When something's broken, I don't ask the AI to "fix it" and hope. The first move is a read only job: print the exact code, change nothing. Claude reads it, reasons about the cause, and only then fires a second, targeted job to make the change. Then it's deploy and verify against the live behaviour.

Investigate, then act. Never act first. It's the same discipline any good engineer uses, just executed by two models instead of one person.

Why bother

Because it compounds. Once the loop is clean (plan, build, summarise, check, deploy) the cost of turning an idea into a running application drops to almost nothing. A tool I'd have shelved for lack of time gets built in an afternoon. The bottleneck stops being implementation and goes back to where it belongs: deciding what's worth building.

None of this requires exotic infrastructure. It requires a clear division of labour, a channel between the two halves, and the discipline to keep context small. The models are good. The leverage is in how you wire them together.

Claude thinks. Codex types. I decide what gets built.

I write about engineering, AI tooling, and building systems. If this was useful, follow along. Subscribe for latest updates https://pulse.runtimerec.com/subscription/form