What happened?

ZDNET writer David Gewirtz put a single question to 138 developers who actively use AI coding tools: "Do you use Claude Code or OpenAI Codex? If so, which did you choose, and why?"

The top-line data point: three out of four developers use Claude Code. A little more than a third of respondents use Codex, and 22% use both — which is why the numbers do not fully add up.

The limits of the method

The writer states plainly that this is not a fully scientific survey. Responses were gathered by posting a call for developer opinions on two services — HARO and Qwoted — that specialise in connecting experts who want to be quoted or interviewed with journalists and analysts.

That means the sample is not random: those who answered are people registered to speak to the media who saw the call and chose to respond. The result is therefore not a cross-section of the developer population but the distribution among participants on those two services.

In figures

  • Respondents: 138 developers
  • Using Claude Code: three in four
  • Using Codex: a little more than a third
  • Using both: 22%
  • Method: open call via HARO and Qwoted
  • Scientific sample: no

The writer's conclusions

Gewirtz lists three. First, that Claude Code dominates but Codex has crucial advantages. Second, that cost, workflow and trust matter as much as code quality. Third, that whichever AI is chosen, human review remains essential.

He also says the finding matches what he sees around him: very few of his developer colleagues talk about Codex, and all of them talk about Claude Code.

Why does it matter?

The criteria listed are more interesting than the number itself. If code quality alone decided the choice of a coding tool, the decision could be made from benchmark scores. Counting cost and workflow at the same weight shows the decision is being made in daily use.

The 22% who use both point the same way: the tools are being used not as mutually exclusive options but as different instruments for different jobs.

What the survey cannot say

What a distribution like this cannot show is how durable the preference is. Switching costs between coding tools are low: a different extension in the same editor, a different command in the same repository. A tool leading in this measurement does not mean it will lead six months on.

The second gap is intensity of use. An answer of "I use it" puts someone working eight hours a day in the same bucket as someone opening it once a month. When weighing a tool's position, those two users cannot count the same.

What is not settled

The survey does not rest on a scientific sample and the results cannot be generalised to the developer population. No breakdown was shared of respondents' countries, experience levels or the kinds of projects they work on.