I Switched from OpenAI Codex to Claude Code — Here's Why

I was a Codex user. It was my daily driver for iOS development, and I was happy with it. Then I decided to give Claude Code a proper try — and I'm
not going back.

Here's what changed my mind, and where Codex still has an edge.

The Context

I work on a SwiftData-backed iOS app. Feature work, refactoring, debugging — the full range of day-to-day development tasks. I'd been using Codex
long enough to know its rhythms, its strengths, and where it annoyed me. I came into Claude Code with real opinions, not a blank slate.

What Finally Pushed Me to Try Claude

Codex is capable. But living with it daily, a few things wore on me.

It doesn't stay in its lane. Ask for one thing, get back three. Features I didn't request, abstractions I didn't need, conventions I didn't
establish. Reading Codex output often felt like auditing a stranger's code rather than reviewing a small change to mine.

It's also verbose in a way that adds noise rather than clarity — unnecessary abstractions, code that technically works but takes longer to
understand than it should.

None of this was a dealbreaker on its own. But it accumulates.

What Claude Does Differently

The first thing I noticed with Claude Code was how much it doesn't do. That sounds like faint praise, but it isn't.

When I ask Claude to change one thing, it changes one thing. It follows the patterns already in the codebase. It writes code that looks like the
code around it. Reviewing Claude's output is fast because it's usually doing exactly what I asked, in a style I'd have written myself.

That restraint turns out to be incredibly valuable when you're working in a real codebase every day. The cognitive load of reviewing AI output
drops significantly when you can actually trust it to stay focused.

Where Codex Is Still Better: The Bug That Humbled Me

Here's the honest part.

I had a SwiftData query fetching the latest record from a database, sorted by timestamp. Most of the time it worked fine. Occasionally it returned
the wrong record. I suspected something was wrong with the sorting itself.

I brought it to Opus 4.6 — the most capable Claude model — with high reasoning effort. Opus locked onto the optional join and stayed there. We
went back and forth for about thirty minutes. I gave hints. It held its ground. It wasn't until Opus itself asked for the console output that it finally shifted — and then identified the fix immediately.

I ran the same problem by Codex out of curiosity. Three minutes later it had the answer: when timestamps are identical — which absolutely happens
— sort order is undefined. Add a secondary sort descriptor. Done.

Codex didn't have tunnel vision on a plausible-but-wrong hypothesis. It just saw the bug.

To Claude's credit: once it had the console output, it got there too. But the time it took, the tokens burned on the most expensive model, and the
confidence with which it pursued the wrong lead — that was a real contrast.

Opus vs. Sonnet

I used both during this period without much strategy. In practice, Sonnet is my default now — fast, capable, and good enough for most tasks. Opus
is worth reaching for on genuinely complex problems, but as the bug story shows, "more reasoning" doesn't always mean "better diagnosis."

Where I've Landed

Claude Code is my daily driver now. The combination of focused changes, readable output, and staying within established patterns makes it a better
fit for sustained development work.

But I keep Codex accessible. When I'm stuck on a bug and my primary tool is going in circles, a cold read from a different model has real value.
The debugging example above wasn't a fluke — different tools have different blind spots, and sometimes a fresh perspective is exactly what breaks
the logjam.

This is personal experience on a specific iOS/SwiftData project, not a controlled benchmark. Your mileage will vary.