# Why 75% of Developers Prefer Claude Code Over Codex > Discover why most developers choose Claude Code over Codex based on cost, workflow, and trust factors. > By Dave · 2026-08-13 > Source: https://otf-kit.dev/blog/claude-code-preference The 75% number everyone read wrong A [recent ZDNet survey of 138 developers](https://www.zdnet.com/article/why-most-developers-prefer-claude-code-over-codex/) is being read as a verdict: Claude Code won, Codex lost. Three out of four respondents chose Claude Code. Only a little more than a third chose Codex. That framing is shallow, and it misses the most useful datapoint in the whole survey. Twenty-two percent of respondents — almost a quarter — said they use both. The ZDNet author is in that cohort. Most professional developers probably are. Treating "Claude Code vs Codex" as a binary is a category error. It's a workflow question, not a benchmark question. What the survey actually measured was preference intensity under real-world constraints: cost, trust, integration with existing tools, and how each product handles a real codebase. Once you frame it that way, the 75% stops looking like a knockout and starts looking like a tie with a slight lean. ![three side-by-side bars, not stacked — 75% prefer Claude Code, roughly 33% use Codex, 22% ](https://cdn.otf-kit.dev/blog/claude-code-preference/inline-1.png) ## What 138 developers actually said Naman Ahuja, a software engineer at Meta, put the Claude Code preference in plain language: > "I use Claude Code extensively at Meta because it fits naturally into my development workflow. I treat it like a peer: brainstorming ideas, shaping plans, and executing. It has improved my productivity and lets me focus on more business problems to solve. I'm happy with it, though I review its output carefully." Read that quote carefully. The win isn't "better code" or "faster completion" — it's peer status. Ahuja treats Claude Code like a teammate. That changes the unit of evaluation. You don't benchmark a teammate; you onboard one. Onboarding is about workflow fit, and that phrase — "fits naturally into my development workflow" — kept surfacing across the responses. A senior software engineering manager quoted in the same survey framed her own choice around trust, cost, and what survived daily use — the durable factors, not the leaderboard ones. That matches the broader pattern. Developer preference in this survey tracked integration depth and compounding trust more closely than it tracked benchmark scores, which is the inverse of how most AI tool comparisons get written. ## Where Codex still wins Codex didn't lose this survey. It lost the headline. Roughly a third of respondents still reach for it, and the article's own conclusion is that Codex has "crucial advantages" the 75% number obscures. What that meant in the responses: - **Established trust.** Codex has been around long enough that some respondents have institutional muscle memory with it. Trust is sticky, and sticky trust is hard to displace. - **Workflow-specific comfort.** A chunk of respondents reported Codex fitting specific tasks or repos better. The survey didn't enumerate those cases — which is itself information. They are repo-shaped, not benchmark-shaped. - **A different working style.** The ZDNet author's earlier side-by-side noted that the two tools produce "amazing similarities" in capability surface but diverge in temperament. Some workflows prefer one over the other for reasons that don't show up on a scoreboard. The takeaway isn't "Codex is better at X, Claude at Y." It's that two serious agentic coding AIs with overlapping capability surfaces differ in working style, and a meaningful population of experienced developers have legitimate workflow reasons for picking the less popular one. ## Cost, workflow, and trust — the boring axis that decides The ZDNet key takeaways put cost, workflow, and trust on the same plane as code quality. That was the survey's actual finding, and it's the one most AI tool comparisons skip. - **Cost isn't just list price.** Subscription tiers, API rate limits, and the productivity tax of waiting on long agent loops — they all roll up to a per-feature cost that ends up mattering more than headline pricing. - **Workflow integration is the moat.** A tool that lives in your terminal, reads your repo, and respects your conventions beats one with a better benchmark and a web-only UI. Survey respondents repeatedly cited "fits naturally" — language that maps to integration depth, not model quality. - **Trust compounds.** A tool you used last Tuesday ships code you didn't have to re-validate. That trust bucket fills slowly and is expensive to displace. If you're choosing between these tools for a serious project, ignore the public benchmarks for a week. Spend that week running each against your actual codebase, on tasks you actually do, with your own conventions loaded. The answer will be different from the 75%. ## How to actually evaluate both in your own workflow The ZDNet author linked out to two earlier side-by-side pieces; the practical pattern is the same in either direction. ```bash # 1. Run both for a week, side by side, on the same tasks mkdir -p ~/eval/cc-vs-codex && cd ~/eval/cc-vs-codex git init # Copy in a real subfolder of your working repo (read-only) # 2. Pick 5 tasks you actually did this week: # - one refactor # - one test scaffold # - one bug repro from your issue tracker # - one doc pass # - one API client from a real spec ``` Concrete evaluation steps: 1. Pick five tasks you actually did this week. One should be a refactor, one a test scaffold, one a bug repro. Don't cherry-pick — pick the ones that made you tired. 2. Run each tool against the same task in the same repo. Time the round trip, including your review and fix-up. Don't time just the model call. 3. Record what each one did that you'd have done differently by hand. Both tools will produce solutions that look right but feel off — count the diffs. 4. After a week, look at which tool produced code you didn't have to revisit. That's your tool. Trust, not benchmarks. The author's earlier piece on `Record-a-Skill` is the kind of feature that makes "fits naturally" concrete: a way to teach the tool a repeatable pattern so the next ten invocations don't cost you the prompt. Tools that grow a vocabulary inside your repo are the ones that compound. ## Human review is the durable skill The ZDNet takeaways end on a line that should be carved into every AI-coding-tools onboarding doc: human review remains essential. Every developer quoted in this survey, on both sides, said some version of "I review its output carefully." That's not a complaint about the tools. It's the workflow. The durable skill across the agentic-coding era is reviewing AI-generated diffs quickly and accurately. Neither vendor can sell you that. You build it by using both tools and failing in public often enough to learn the failure modes. The 22% who use both aren't smarter — they just got there faster, because each tool's blind spots are visible against the other. If you're early in your career and reading this to decide which tool to learn first: learn both. Use whichever one fits the current task, then review the diff like it's a PR from a competent stranger. ## The layer that survives the model churn Here's the angle worth stating plainly: the codebase outlives the model. Claude Code will be displaced by something else in 18 months. Codex already has been, in the workflow sense, by Claude Code. The thing that doesn't churn is your repo, your conventions, your review checklist, and the muscle memory of moving work through these tools without breaking the build. Build the durable layer — the same component rendering identically on web, iOS, and Android from a single API; the validated config schema both models can be pointed at; the test harness every agent has to pass; the review pattern that catches the failure mode this week's model hasn't shipped yet — and the question of which agentic coding AI wins next quarter stops mattering for your roadmap. It still matters for your Tuesday morning. Pick the one that earns your workflow trust this week, and treat the other as a backup the way you'd treat a second keyboard layout. The survey measured preference. What you actually need is a workflow that doesn't break when the preference flips.