Two Years on Claude Code, Then I Gave Codex a Real Shot. Here's What Changed My Mind.AITools

Title: Two Years on Claude Code, Then I Gave Codex a Real Shot. Here's What Changed My Mind. Tags: ai, tools Excerpt: Claude Code is still where I trust my actual code the most, but Codex's limits don't run out, which makes it the better tool for one specific job: turning a feature description into a development plan before I touch the editor. Prompt for preview: A split-screen style illustration of two AI coding assistants, one labeled with sharp precise code editing, the other labeled with a long unwinding roadmap or task list, both feeding into the same project, clean minimal tech editorial style, dark background

I've used Claude Code for two years. It's where I do almost all my actual development: refactors, debugging, the work where the model needs to understand the codebase and not just generate something that compiles. I trust it more there than anything else I've tried, and that hasn't changed.

What changed is that I stopped trying to make it do everything.

Why I Even Looked at Codex

I didn't switch because Claude Code got worse. I switched a piece of my workflow because Claude Code's session limits are real, and on a busy week I hit them constantly, usually in the middle of something I didn't want to stop doing.

Codex has the opposite problem. Its limits are loose enough that I genuinely don't think about them. ^{I expected that to mean worse output}. It doesn't, it just means a different kind of output, because Codex isn't trying to be the tool that holds your entire codebase in its head while it edits four files at once. It's better suited to something else entirely.

So the real question wasn't "which tool is better." It was: which job is each tool actually built for?

The Split: Claude Code Writes, Codex Plans

Here's where I landed, and it's held up across several client projects now:

• Claude Code does the actual implementation — reading existing code, editing it, refactoring, debugging. Anything where correctness depends on understanding what's already there.
• Codex does planning and task breakdown — turning a feature description into a structured development plan before anyone opens an editor.

Neither tool is doing the other's job anymore. That's the whole point.

What Planning With Codex Actually Looks Like

When a new feature comes in on a client project, I don't open the editor first. I write the feature up in plain language and hand it to Codex with a prompt built specifically to produce a plan, not code:

I need a development plan for the following feature, not implementation code.

Feature: [plain-language description of what the feature needs to do]
Existing context: [relevant stack, constraints, what already exists that this touches]

Break this down into:
1. An ordered list of implementation steps
2. Which existing files/modules each step likely touches
3. Open questions or decisions I need to make before starting
4. Edge cases worth handling

Do not write code. I want a plan I can review and adjust before any implementation starts.

That last line, "do not write code", matters more than it looks like it should. Without it, Codex defaults to jumping straight into implementation, which isn't what I want at this stage. I want something I can actually review on its own: read it, push back on it, reorder steps, kill ones that don't make sense, before a single line gets written.

Handing the Plan to Claude Code

Once the plan looks right, it goes into Claude Code, where the real editing happens:

Here's the plan I want to implement: [paste the reviewed plan]

Start with step 1. Show me the change before moving to step 2,
and flag anything in the plan that doesn't match what's actually in the codebase.

That second instruction is doing real work, not just boilerplate. A plan generated from a description of the codebase, not from reading the actual code, will occasionally assume a file or pattern exists that doesn't. Catching that at step 1 is cheap. Catching it at step 4, after three steps of work are built on a wrong assumption, is not.

The plan is only as good as the gap between "what the codebase looks like in my head" and "what it actually is." Codex never closes that gap on its own, it just writes down its best guess. Claude Code is what catches the guess before it becomes a bug.

What This Actually Buys Me

It's not speed. I want to be clear about that, because "I use two AI tools now" sounds like a productivity hack, and that's not really what's happening here.

What it buys me is a clean handoff between two completely different modes of work:

• Codex runs long, exploratory planning passes without me watching a session limit creep up mid-thought.
• Claude Code stays focused entirely on what it's best at: turning an already-reviewed plan into code I actually trust.
• I'm no longer negotiating with rate limits in the middle of the part of the work that matters most.

That last point is the one I'd underline. The expensive failure mode isn't "I ran out of Claude Code limits." It's running out of them mid-implementation, with half a feature in an inconsistent state. Moving planning somewhere with no real ceiling means the tool with tighter limits only ever gets used for the work it's genuinely best at.

The Actual Question to Ask

If you're running both Claude Code and Codex, or considering it, "which one is better" is the wrong frame. They're not competing for the same job.

The better question: which part of your workflow makes you anxious about hitting a limit at the worst possible moment — and can that part move somewhere else?