Last week I told my mentee Jacob something that made him stop typing.
“I’m basically a glorified typing monkey at this point.”
He looked confused. I was describing my actual workflow for building software — one where I write the spec, describe the vision, and then two AI agents handle the rest. Claude Code builds. Codex reviews. I approve merges. That’s my job now.
He laughed. Then he said, “That’s kind of incredible.”
Yeah. It kind of is.
The Actual Workflow
Here’s how it works in practice.
I open Warp — that’s my terminal — and I pull up two panes side by side. Command-D gives you a vertical split. On the left, I launch Claude Code. On the right, I launch Codex.
These are two separate coding agents. Claude Code is Anthropic’s. Codex is OpenAI’s. Different models, different strengths, and critically — a different perspective on the same code.
I give Claude Code a spec. Not a vague request — a proper spec with the outcome I want, the features needed, any constraints or preferences. Then I say: make a plan, then build it.
Claude Code does its thing. When it’s done with a feature, it commits the code and creates a pull request. That’s the moment it hands off.
Why Codex Reviews Claude Code’s Work
Here’s the thing most people don’t know about AI coding agents: they’re genuinely bad at reviewing their own work.
Claude Code will produce code, look at it, and say it looks great — because it has no fresh perspective on what it just wrote. It can’t step back and see what’s missing or where the logic breaks down.
Codex can. Different model, different training, different set of eyes on the same PR.
So when the pull request is created, I switch to the right pane and tell Codex: “Review PR number X. Fix any issues if needed. Leave a comment.”
Codex pulls up the diff, reads the code, tests it. If something’s off, it fixes it. If everything looks good, it leaves a review comment saying so. Then Claude Code comes back, reads the comment, and merges it.
That’s the loop. Build → review → merge. Two agents. No me in the middle.
Running It Overnight
I usually have 3-4 instances of this running simultaneously on separate branches. Each pair is working on a different feature. Because they’re on separate branches, they don’t conflict — GitHub keeps everything isolated until it’s time to merge.
Sometimes I leave this running overnight. Write the specs before bed. Set it going. Go to sleep. Wake up and check GitHub.
New features. Merged. Sometimes a whole app, depending on how ambitious the spec was.
The quality depends almost entirely on how good the spec is. Really good spec? The agents can get to 80-90% of what I wanted without a single interaction. Vague spec? You get vague results. The writing is now the work.
What I Actually Do All Day
What changed is where my time goes.
Writing code: almost zero. Running things manually: barely. Debugging random errors by hand: rarely.
What I do is: write specs. Review PRs. Say approve. Sometimes redirect.
That sounds like nothing. But it’s actually the hardest part — knowing what to build, in what order, with what constraints, to what quality bar. That thinking doesn’t get automated. It gets more important.
The concept at play here is what I think of as multi-tool native — the idea that these models aren’t interchangeable. Claude Code is great at building. Codex is great at reviewing. You get the best of both by routing the right work to the right model, not picking one and using it for everything.
The Foundation You Still Need
I told Jacob — who had never used GitHub before this session — that this workflow only works once you understand what’s underneath.
Branches. Commits. Pull requests. Reviews. Merges.
Not so you can do all of it yourself. You won’t. The agents will. But you need to speak the language so you can orchestrate them correctly. So when Claude Code says “should I push to main or create a feature branch?” you know what that means and why it matters.
Jacob spent 8 months watching YouTube videos trying to learn to code. He barely got anywhere. Then we started doing hands-on sessions — actually building things, actually using the tools — and six weeks in he’s already at an intermediate level.
The difference isn’t intelligence. It’s method. Doing beats watching. Every time.
The Bottom Line
I’m a glorified typing monkey. I write specs and say approve. My agents ship code around the clock.
That’s the 2026 version of building software.
The people who figure out how to orchestrate these tools — who learn the underlying mechanics, write strong specs, and stay in the judgment seat — they’re going to build things at a pace that wasn’t possible two years ago.
The tools are ready. The question is whether you are.
Thanh Pham is the founder of Asian Efficiency. He teaches AI fluency through workshops and the 4-Day AI Sprint — designed to take people from occasional AI use to real, running workflows.
