The Coding Moat Was Never the Code

Anthropic published a study this month with a result that doesn’t fit on a recruiter’s slide. They looked at 400,000 Claude Code sessions and sorted users by occupation. The best ones weren’t the best programmers. Management, legal, and sales professionals landed within a few percentage points of software engineers, and management occupations scored highest of the lot.

Read that again. People who don’t write code for a living drive the most capable coding agent in the world about as well as the people who do. In some cuts of the data, better.

The Skill That Transfers Isn’t Syntax

The study’s other number explains the first one: expert users trigger more than twice as many agent actions per prompt as novices. They aren’t typing faster. They’re decomposing the problem into the right pieces, specifying each piece precisely enough that the agent can’t wander, and then looking at what came back and knowing whether it’s correct.

That’s the whole job now, and none of it is a coding skill:

• Decomposition. Breaking a vague goal into ordered, verifiable steps. A manager who has shipped projects through other humans has done this ten thousand times.
• Specification. Saying exactly what you want, including the edge cases, in language that removes ambiguity. A lawyer writes contracts for a living.
• Evaluation. Looking at output and judging whether it’s right. This requires domain knowledge, not language knowledge. You can’t evaluate a billing flow you don’t understand.

I’ve argued before that specifications became the unit of programming and judgment is the part humans keep. This study is the data behind it. The interface to the machine is clear thinking, and clear thinking is domain-specific.

What This Kills

For a decade the advice to anyone eyeing a tech salary was the same: learn to code. The premise was that typing the language was the scarce, defensible skill, the moat. Bootcamps sold the moat by the twelve-week course.

The agent just made typing free. The moat drained overnight, and what was sitting at the bottom of it turns out to have been something else entirely: knowing which thing is worth building, and recognising when it’s wrong. That doesn’t come from a syntax course. It comes from years spent deep in a domain that wasn’t programming.

The scarce skill was never producing the code. It was knowing what the right code was. We just spent a decade mistaking the typing for the thinking because the typing was the part that was hard.

The Career Read

This is uncomfortable for anyone who built their identity on craft, and freeing for everyone else.

If you’re a domain expert, a clinician, an accountant, an operations lead, the logistics person who knows why the warehouse actually breaks, the lateral move into building software now beats starting at the bottom of a craft the machine handles. You bring the half nobody can automate: you know what good looks like in your world.

If you’re an engineer, the defensible part of your job was never the syntax either. It’s the systems judgment, the sense of what will break at scale, the architecture taste. I’ve written that coding interviews test the wrong thing, and this is the sharper version: they test the skill the machine absorbed, not the one it can’t.

What It Doesn’t Solve

Before this turns into a victory lap for everyone who skipped the CS degree, the honest caveats:

• Anthropic measured its own tool’s users. People who self-selected into Claude Code and stuck around are not a random sample. The managers in that data are unusually technical managers. The result is real, but the population is curated.
• “Within a few points” isn’t “the same.” The gap is small at the median and probably yawns on genuinely hard systems work: concurrency, performance, the failure modes you only learn by getting burned. The lawyer ships the CRUD app. The lawyer does not ship the distributed database.
• Evaluation has a ceiling you can’t fake. You can only judge output as well as you understand the domain. Hand a non-engineer a subtly wrong auth flow and the agent’s confidence becomes their confidence. Domain knowledge protects you exactly up to its edge and no further, which is also the junior developer’s whole problem right now.

Closing

The study didn’t say engineers are finished. It said the thing we were selling as the engineer’s moat, the code itself, was never the moat. The moat was judgment about a domain, and that was always portable.

For ten years we told people the scarce skill was the one that was hard to type. The machine learned to type. What’s left is the thing that was always actually scarce: knowing what to build, and knowing when it’s wrong. That was never in the language reference. It was in the people who knew the problem.