New Superpower Unlocked: Claude Code + Codex

A year ago I started using Claude Code every day. Yesterday I added Codex to the stack for the first time.

This morning I am writing it down, because the difference between one tool and two tools talking to each other is bigger than I expected.

The shift was not learning to code faster. It was learning to stop typing and start directing.

A quick translation before we go further. An AI session is a chat window with a coding assistant that can read and edit the files on your computer, not only answer questions. A handoff is a short script that pauses one assistant, summarizes where it is, and passes that summary to another tool so the work can continue. That is the whole vocabulary you need.

What a year of Claude Code taught me

For most of the last twelve months, Claude Code has been my one AI tool.

A setting called /opusplan does most of the heavy lifting. It puts the assistant into its most thoughtful mode and walks me through the design of whatever I am building before any code gets written. It sits with a half-formed thought, asks the right questions, and turns it into a real plan with phases and trade-offs spelled out.

Almost everything I have shipped this year started in that mode. Less time typing line by line. More time deciding what to build and why.

Big shoutout to Nate Herk, Jack Roberts, and Nick Saraev, the three creators whose channels have shaped most of my workflow ideas this year. And worth a quick shoutout to Matthias Frank, whose Notion content has changed how I plan projects. If you live in Notion, his channel is worth your time.

What changed yesterday when I added Codex

I had been watching senior developers describe a two-tool workflow on YouTube for weeks. Yesterday I finally tried it.

Codex is the opposite personality from Claude. Shorter-tempered. More skeptical. Less willing to nod along with whatever framing I walked in with. That makes it the right tool for what I would call the red-pen pass.

I ran the same set of changes past both assistants within an hour of each other. They came back with two almost-completely-different lists of problems.

That was the moment the workflow clicked.

Claude is the planner that sits with the ambiguity and helps you decide. Codex is the reviewer that shows up after you have a draft and tries to find what is wrong with it. Solo, each is useful. Together, they cover blind spots the other has.

It only took a day to see that. I imagine the workflow gets sharper over the next month.

Is AI coming for developer jobs?

This is the loudest question in the room right now, and the one nobody wants to bring up at dinner. So let me bring it up.

My honest read, after a year of using these tools every day, is that developers, programmers, and software engineers are about as safe as it gets.

What AI is genuinely good at is generating code that looks correct. That is real value. That is also the easy part of the job.

What AI is still bad at is the hard part. Four things, all of them load-bearing:

• Deciding what to build in the first place.
• Choosing between five plausible designs.
• Catching the bug that will bite you in production at three in the morning.
• Taking responsibility when something goes wrong.

Typing was never the hard part. Reading what got produced, judging whether it is right, and being on the hook when it is not. That is what gets paid for. The work is not shrinking. It is shifting toward the parts that still need a human brain.

The things that will trip you up

If you are about to try this for yourself, three traps to watch for.

The mistakes look correct

The code is better than it used to be, but the kinds of mistakes have changed. An AI assistant makes mistakes that look completely plausible, that pass the eye test and quietly fail on the edge case.

A few from my own week:

• Code that prints an API key into the log output as part of a helpful debug line.
• A query that works on five rows and silently falls apart on fifty thousand.
• A handler that returns the right shape on the happy path and the wrong status code on every error branch.

Reviewing well is the single skill that has mattered most for me this year.

Two assistants on the same files will fight

The first time I ran two assistants in parallel yesterday, they cheerfully overwrote each other's work for about forty minutes before I noticed.

The fix is explicit role assignment. One assistant owns planning. The other owns implementation. Both check a shared status file before doing anything. When work needs to move between them, the handoff routine takes over.

Not glamorous. Saves hours.

You do not need three subscriptions on day one

Plenty of this runs fine on a single good tool. A second assistant is something you add once you are already shipping regularly and want a second pair of eyes that never gets tired. Layering on a second one too early is how you end up paying for two and using neither.

That is the path I took. A year of one tool, then one more.

The discipline AI cannot replace

The unsexy part of all this is the discipline underneath.

Saving your work to version history in clean, small pieces. Naming things so somebody else could read them. Automated checks that catch problems before a real user does. Tests written alongside features, not after.

None of that is new advice. The catch is that when an assistant can produce a hundred lines of code in thirty seconds, the part of you that keeps the project coherent has to get stricter, not looser.

That tradeoff is what has freed me up to focus on the work that actually matters. With the boring parts getting automated, my time is going into building interactive photo and video experiences that I could not have shipped this fast a year ago.

You are not behind yet. But you will be.

The workspace is not on the verge of changing. It already has.

The people I know who started experimenting twelve months ago are running circles around workloads they used to spend whole weeks on. The ones who waited are not behind by a little. They are behind by a lot, and the gap is widening every quarter.

Getting started does not have to be dramatic.

1. Pick one assistant.
2. Open one project you already understand.
3. Spend an hour trying to do something with it that would normally take an afternoon.
4. Pay attention to where it helps and where it gets in the way.

That single hour will teach you more than any blog post, including this one.

One honest question for you

When an AI gives you code that works on the very first try, do you trust it more, or do you trust it less?

I have caught myself answering both ways in the same week, and I think how you answer that question quietly shapes what kind of developer you are becoming.

Drop your answer in the comments below. If you have questions, or you are not sure where to start, leave those there too. I answer everything in the comments, not in DMs, so the next person reading can learn from the same exchange.

We are all early on this, and most of what is true today will be wrong by spring. Better to be early and confused than late and confident.