Agentic coding rewards domain expertise, not coding skill

I lead generative and agentic AI in production, and the question I hear most often — from engineers, from executives, from people whose work has nothing to do with code — is a version of the same worry: if an agent can write the code, what is my expertise still worth?

Anthropic published a study that gives the clearest data-backed answer I have seen. It analyzes roughly 400,000 Claude Code sessions from about 235,000 people between October 2025 and April 2026, and its central finding lines up with what I watch happen on my own teams: agentic coding does not flatten the value of expertise — it pays a premium for it. The twist is which kind of expertise.

People decide what; the agent decides how

The first thing the data settles is the division of labor, and it is remarkably stable. Across sessions, people make about 70% of the planning decisions — what to build, which approach to take, what counts as done — while the agent makes about 80% of the execution decisions: which files to change, what to write, which commands to run.

That ratio matches the texture of real sessions. A typical session runs about four turns, and each human prompt sets off a chain of roughly ten agent actions — sometimes more than a hundred — with the agent producing on average around 2,400 words of output per turn. The person is not typing code. They are setting direction and judging results, and the amount the agent does between check-ins tracks who holds the decisions: hand it the planning and it takes on far more per turn; keep execution control yourself and it does less.

This is the part people miss when they picture "AI writing the code." The agent is not running the project. It is running the implementation, inside a frame a person defines and corrects.

Expertise is the throttle — and it is not coding skill

Here is the finding I would put in front of anyone deciding how to spend their learning time. The study rates each user's apparent expertise at the task on a five-point scale, and the gap in what the agent does is large. In novice sessions, each prompt sets off about five agent actions and 600 words of output. In expert sessions, the same single prompt drives more than twice the actions — twelve — and roughly five times the output, about 3,200 words.

More domain expertise means more useful work per instruction. A precise, well-framed request with the right constraints gives the agent room to run; a vague one keeps it on a short leash.

The crucial detail is that this expertise is task-specific and has little to do with job title or coding background. The study's classifier reads three signals: how precisely you frame your directions, what you ask the agent to verify, and whether you tend to correct the agent or it tends to correct you. By that measure a senior engineer asking their first Rust question is a beginner, while an accountant who has never written Python — but can tell the agent exactly which reconciliation rules a script must enforce, and catch the edge case it mishandles at month-end close — is an expert at that task. The advantage comes from understanding the problem, not from knowing the language.

Everyone succeeds; understanding decides how often

The most striking result for the labor-market question: on coding tasks, every major occupation in the data succeeds — accomplishes what the person set out to do, with verifiable evidence like passing tests or committed work — at nearly the same rate as software engineers. You do not have to be trained as a programmer to direct one of these tools to a real result.

More domain expertise does raise the success rate, and experts recover from errors and misunderstandings more easily. But the gap between intermediate and expert users is modest. You do not need deep mastery to use the tool almost as effectively as someone who has it — a firm grasp of the problem is enough. Success, in this data, is set by how well you understand what you are trying to do, not by whether you can write the code yourself.

The work is climbing the stack

The seven months of data also show the work moving. The share of sessions spent debugging fell by nearly half, and usage shifted toward more end-to-end agentic work: deploying and running code, analyzing data, and writing prose documents where code is incidental to the result. As the implementation-heavy middle gets absorbed, people spend more of their time at the ends — deciding what to do and putting the result to use.

The value of that work rose with it. Estimated against freelance job postings, the value of the typical task climbed in almost every category — about 25% on average over the period. The tasks people bring to the agent are getting more complex and more valuable, not more trivial.

What I take from this

None of this reads as expertise becoming optional. It reads as the bottleneck moving. In production, the constraint is rarely the model's raw ability; it is the quality of the specification and the verification around it. The people who get the most from these tools are the ones who can state precisely what they want, name the edge cases that matter, and tell whether the output is actually correct.

So the advice I give my teams has shifted. Spend less effort on syntax you can now delegate, and more on the things the agent cannot do for you: understanding the domain deeply enough to frame the problem, and being rigorous enough to verify the answer. Those are the same skills that made people good at their jobs before agents arrived. The tools did not replace them. They raised the return on them.