Yesterday, Anthropic released the research report "Agentic Coding and the Returns to Expertise."
The report, based on approximately 400,000 Claude Code sessions, reveals a counterintuitive conclusion: coding agents aren't eliminating experts—they're rewarding those who truly understand the business.
Core data shows that in agentic coding, humans are responsible for roughly 70% of planning decisions (what to do), while Claude handles roughly 80% of execution decisions (how to do it). "People decide what to build; agents decide how to build it."
Even more striking, non-software professionals achieve coding success rates nearly on par with software engineers (verified success 26% vs 30%, partial success 88% vs 89%), with the top ten occupational groups all within a 7-percentage-point spread.
The real differentiator is domain expertise, not programming ability. Expert users trigger 2.4x more Claude actions per prompt than novices (12 vs 5) and generate 5x the text output (3,200 vs 600 words).
When trouble hits, novices abandon sessions at a 19% rate, while intermediate-to-expert users abandon at only 5–7%. But the key finding: the jump from novice to intermediate yields the biggest gains; intermediate to expert adds only marginal improvement. "Working mastery of a domain captures most of the returns, while deep specialization adds only a little more."
Over seven months, debugging sessions plunged from 33% to 19%, while software operations, data analysis, and documentation writing doubled. Average task economic value rose 25%, with building tasks up 43%.
The report hints at a labor-market reshuffle: when "acting like a manager" drives higher success rates, domain experts + AI tools are replacing pure coders.
Below is the full report—
"Agentic Coding and the Enduring Returns to Expertise"
Key Findings
Building on prior work, we introduce a framework for studying interactive agentic coding, based on a privacy-preserving analysis of approximately 400,000 Claude Code sessions from October 2025 through April 2026. We evaluate task composition, human–AI collaboration, and success rates.
In a typical session, humans make the majority of planning decisions (what to do), while Claude makes the majority of execution decisions (how to do it). The more domain expertise a person brings to a session, the more work Claude completes per prompt.
On coding tasks, each major occupation's success rate—completing the user's stated goal with verifiable evidence such as passing tests or submitted work— is, on average, nearly identical to that of software engineers.
The more domain expertise a person has, the more likely a session is to end in success—though the gap between intermediate and expert users is small.
Over the seven months we observed, the share of sessions used for debugging fell by nearly half, with usage shifting toward more end-to-end agentic use: deploying and running code, analyzing data, and writing non-code documentation.
Over those seven months, the estimated economic value of the typical task—approximated by comparison to freelance job postings—rose across nearly all types of work, by about 25% on average.
Introduction
Agentic coding has taken off. Since late 2025, the share of GitHub repositories showing coding-agent activity has more than doubled, and Claude Code users now average 20 hours per week with the tool.
Can people without formal coding experience successfully steer agents through complex technical work? What does the rapid adoption and improvement of these tools mean for knowledge work broadly? While we don't yet have complete answers, we look for early signals in Claude Code usage data.
This report provides evidence on how Claude Code is used in practice, based on a privacy-preserving analysis of approximately 400,000 interactive sessions from roughly 235,000 users between October 2025 and April 2026.
It builds on prior work focused on measuring autonomy in Claude Code sessions and on how Claude Code is changing work at Anthropic.
Here we introduce a framework for describing interactive AI coding assistant use: what kind of work is being done, who does what, and whether it succeeds. We focus on Claude Code used via the command-line interface (CLI), Claude.ai, or the Claude Code desktop app.
By tracking how agentic coding use changes as model capabilities improve, we can better understand how these tools affect the labor market for coding professionals and knowledge workers alike.
What happens in Claude Code may preview where knowledge work is headed as agents embed into non-coding tasks. We find Claude is handling more complex, higher-value tasks. At the same time, a clear division of labor persists in agentic coding: people decide what to build; agents decide how to build it.
We also see evidence that domain expertise—not coding proficiency—amplifies effective tool use. In particular, domain experts succeed more often and recover more easily from errors and misunderstandings.
However, the gap between experts and intermediate users is small—suggesting that competence in a domain is enough to use the tool nearly as effectively as deep mastery.
These findings give us an early read on how labor markets may shift.
In our data, success depends on how well a person understands the problem they're trying to solve, not on whether they were trained to code.
If these patterns hold across the economy, it suggests that while agentic coding tools may be absorbing some implementation-heavy work, they are also rewarding those who have a solid grasp of the problems their work solves.
Coding agents aren't replacing domain expertise—the more understanding a worker brings to the agent, the higher-quality work the agent can do.
Division of Labor
What People Use Claude Code For
To understand what people use Claude Code for, we classify each session into one of nine work modes—the single activity that best describes what the session is trying to accomplish.
Four modes involve directly writing or maintaining code: building new things, fixing broken things, testing code, and orchestrating other agents or automation pipelines.
Another category is operating software—deploying, configuring, running pipelines, monitoring systems.
Two categories are more about figuring out what to do: understanding how existing systems work, and planning before making changes. Two more take actions unrelated to code, or where code is incidental to the final product: analyzing data, and communicating via presentations and other prose-based documents.
About 56% of sessions involve writing (25%), fixing (26%), or testing and orchestrating code (5%). Operating software accounts for 17%, 14% of sessions are planning or exploring, and 13% produce analysis or prose (Figure 1).
Figure 1: Nine Work Modes. Each interactive session is classified into the single mode that best describes what it is trying to accomplish.
We classify each session by having a model read its transcript, then check against telemetry automatically recorded for each session—including whether any lines of code were added or deleted—using our privacy-preserving analysis tool.
The two sources are highly consistent—for example, over 90% of sessions our classifier labels as creating or modifying code show code changes in telemetry.
Who Decides What
How autonomous is Claude Code? Capability evaluations suggest a high and rising ceiling: on benchmarks like METR's time-horizon evaluation, frontier models can now autonomously complete software tasks that take humans hours, overcoming obstacles along the way.
But what about real-world use? Here we look at how much steering is done by the person versus by Claude in actual sessions.
We study this from two angles. First, we look at the extent to which people delegate decisions to Claude; second, we look at how much latitude they give Claude to act.
To understand the division of decisions in a session, we build a privacy-preserving decision-attribution classifier from session content. We ask the classifier to list all substantive decisions in a session.
We categorize these as planning (what to do, which approach to take, what counts as done) and execution (which files to change, what code to write, which language to use, which commands to run). The classifier then attributes each decision to Claude or the user, giving each session two numbers: the user's share of planning decisions and the user's share of execution decisions.
On average, people make about 70% of planning decisions but only 20% of execution decisions (Figure 2). In practice, there is a clear division of labor in agentic coding—people decide what to build; agents decide how to build it.
To understand delegation of action in a session, we look at session structure rather than content. A Claude Code session involves the user and Claude exchanging prompts (from the user) and actions (taken by Claude)—the user writes a prompt, Claude does some work, then the user writes another prompt, and so on. A typical session involves about four such rounds.
In our October 2025–April 2026 historical data, each user prompt triggers an average of about 10 Claude actions—sometimes over 100. In each round, Claude reads files, edits code, runs commands, and writes an average of 2,400 words of output.
The amount of work Claude does between checkpoints depends heavily on who is making the decisions. When the user retains control of execution (making over 80% of execution decisions), Claude takes fewer actions per round (about 8).
When Claude controls planning (making over 80% of planning decisions), it takes the highest number of actions (about 16).
Figure 2: Claude's Share of Planning and Execution Decisions
Distribution across sessions of the share of planning decisions (what to do) and execution decisions (how to do it) attributed to Claude rather than the user. In a typical session, the user makes about 70% of planning decisions while Claude makes about 80% of execution decisions.
Levels of Expertise
From each transcript, Claude rates the user's apparent expertise on a five-level scale from novice to expert.
The expertise classifier looks for three signals: how precisely the user articulates their instructions, what they ask Claude to verify, and whether the user tends to correct Claude or vice versa. Note that expertise captures something distinct from job title or general capability—and critically, it is task-specific.
A senior engineer asking their first Rust question is a novice in Rust. An accountant who has never written Python but tells Claude exactly which reconciliation rules the Python script must implement and catches edge cases it mishandles during month-end close is an expert on that task.
The table below shows how we define each expertise level in the classifier, along with example prompts from the public agentic coding session dataset SWE-chat. Novice conversations give generic instructions with no implied domain-specific knowledge. Expert conversations convey deep knowledge of the codebase and technical environment.
Table 1: Expertise Classifier
Example prompts are paraphrased, anonymized, and condensed from real sessions flagged by our classifier. Many sessions used in the table come from SWE-chat, a public dataset of agentic coding sessions.
We quantify the relationship between expertise and Claude's per-prompt output and activity. In a typical novice session, each prompt triggers about 5 Claude actions and about 600 words of output, while expert sessions trigger action chains more than twice as long (12 actions) carrying five times the output (3,200 words) (Figure 3).
This novice–expert gap appears in every work mode and every task-value band.
These metrics complement our prior report's autonomy measures, which tracked how long the agent runs and how often people auto-approve its actions.
By contrast, our decision-attribution measure captures who makes substantive decisions across the whole session, while our per-prompt output and action measures capture how much autonomous activity each human prompt triggers.
Figure 3: Claude Does More Per Prompt for More Expert Users
Claude produces more actions (left panel) and text output (right panel) per prompt for more expert users. Boxes span the interquartile range (split at the median). Whiskers represent the 5th to 95th percentiles. White dots are geometric means. Both upward trends are statistically significant (p < 0.001), as is each step between adjacent levels, and remain significant in regressions controlling for work mode, task value, month, occupation, and model family (9% more actions and 13% more output per expertise level), with standard errors clustered by user.
Who Uses Claude Code, and For What
Users
To understand who is doing this work, we infer each user's occupation from the session transcript, mapping it to one of 23 major groups in the Bureau of Labor Statistics Standard Occupational Classification (SOC) taxonomy.
The classifier is instructed to rely only on signals such as the project context the agent loads at session start, the names and structure of its files, any artifacts they reference (e.g., legal documents, clinical data, financial reports, curricula), and the vocabulary they use. It is explicitly instructed not to treat coding behavior as evidence of a coding occupation.
A session is classified under a coding SOC code (Computer and Mathematical Occupations) only when there is a clear signal that software or data work is the user's job. A session where a lawyer builds a script to auto-flag missing clauses in a folder of contracts maps to the legal occupation, even though the session's work is mostly software. When no signal about the user's occupation exists, the session remains unclassified.
We could infer an occupation for about 70% of sessions. In this set, Computer and Mathematical Occupations—the category covering most software-related jobs—is unsurprisingly the largest group. Next come Business and Financial Operations; Arts, Design, and Media; Management; and Life, Physical, and Social Sciences. The fastest-growing non-software occupational groups in our sample are Management, Sales, and Legal occupations.
Work
The composition of work done with Claude Code shifted significantly between October 2025 and April 2026.
The most striking change is the drop in sessions for fixing broken code from 33% to 19% (Figure 4). In its place, we see growth in the share of work around code. Operating software grew from 14% to 21%. Writing and data analysis roughly doubled, from about 10% each to 20%.
Tasks themselves also became more valuable. We approximate the economic value of each session by asking what the work would cost on a freelance market, calibrated against a public dataset of real postings. By this measure, the average session's estimated value rose 27% from October to April.
This growth applies across many work types. Building, operating, and fixing tasks saw value increases of roughly 43%, 34%, and 32%, respectively.
These price estimates are rough, so we use them mainly to compare tasks over time rather than interpret as literal dollar values.
Figure 4: Composition and Value of Claude Code Work, October 2025 – June 2026
Share of sessions in each work mode over the seven-month window. Sessions for fixing broken code fell from 33% to 19%, while operating software, analyzing data, and writing documentation grew.
Success Depends on What the User Brings
Task estimated value is one way to see how Claude Code helps people get work done. Another is to look at how many sessions succeed, and which session features correlate with success.
Across all our success measures, we see a clear pattern: the more expertise a person demonstrates in a session, the more likely the session is to succeed.
Most of the gains concentrate at the low end of the expertise scale—the gap between novice and intermediate sessions is larger than between intermediate and expert.
Before turning to the features of successful sessions, we should be precise about how we measure success. We cannot observe real-world user outcomes or directly ask whether they got what they wanted from Claude.
Instead, we rely on two complementary transcript-based measures. First, adjudicated success comes from a classifier that reads the full transcript and decides whether the person successfully completed what they set out to do (options: success, partial success, failure, no clear goal). Two companion classifiers then evaluate the strength of evidence for that judgment to determine verified success. The success-signal classifier looks for verifiable evidence of success.
Specifically, it looks for git activity matching the work—such as commits and pull requests—passing test suites, and explicit user confirmation. It scores sessions from "no signal" to "weak signal" (1) to "multiple hard signals" (5).
A parallel failure-signal classifier scores evidence of things going wrong—errors, failed tests, retries, user pushback on output. Verified success requires a session to be adjudicated as successful and have at least one hard verifiable success signal.
For the following analyses focused on how sessions succeed or fail, we exclude sessions the success-outcome classifier judges as "no clear goal," about 7.7% of our full sample.
The Returns to Expertise
So what kinds of sessions succeed most? It turns out the expertise rating of the session above is critical to how it ends.
One might worry expertise isn't the real driver—maybe experts just pick different tasks or differ in other ways.
In this section we partially address that concern by comparing sessions doing the same type of work, at the same estimated value, in the same month, on the same task topic, from the same broad occupational group, and asking how the person's rated expertise affects outcomes.
Table 2: Success and Failure Definitions from Classifiers
Example prompts are paraphrased and summarized from real sessions in SWE-chat, a public dataset of agentic coding interactions, flagged by our classifiers.
Across all our success measures, the more expertise a person demonstrates in a session, the more likely the session is to succeed. Sessions rated novice achieve our strictest measure—verified success—15% of the time and achieve at least partial success 77% of the time. Sessions rated intermediate or above achieve verified success 28–33% of the time and at least partial success 91–92% of the time (Figure 5).
In every measure, most of the gain comes from moving from novice to intermediate; the slope flattens between intermediate and expert. In the appendix we give details of the regressions behind Figure 5.
Figure 5: Expertise and How Sessions End
Session outcomes by the user's rated expertise on that task (five-level scale from novice to expert). Left panel includes all sessions. Middle and right panels restrict to sessions that encounter trouble (failure signal > 3) and show the fraction that still end in various success and failure definitions. Each point is an adjusted rate—we estimate differences across expertise levels by comparing only sessions that share the same work mode, same task-value band, same month, same task topic, and same user type (software-related occupation or not). Details of the regressions behind these points are in the appendix. Whiskers are confidence intervals on the sample means (most too small to be visible in this figure). These figures exclude sessions adjudicated as having no clear goal by the success-outcome classifier.
A similar gradient appears in sessions that encounter challenges along the way. When failure signals record verifiable evidence of struggle, we say a session encounters trouble. This could be errors, failed tests, multiple attempts at the same thing, or the user expressing frustration or dissatisfaction. In sessions that encounter trouble, the verified-success rate rises from 4% for novice-rated sessions to 15% for expert-rated sessions, with all the controls above (Figure 5). Looking at the looser measure, we find at least partial success rates of 60% for novices and 80–81% for intermediate-through-expert sessions.
We also track the reverse relationship—expertise versus various failure measures. Note that in this analysis, sessions adjudicated as failures are those that do not even achieve partial success. We say a session encountering trouble is abandoned if it is adjudicated as a failure and no lines of code are written: 19% of sessions that look novice end up abandoned, versus 5–7% for everyone else.
In other words, the least experienced users are more likely to walk away when the effort to achieve their intended outcome stalls. Part of expertise's value appears to be the ability to steer the agent back on track.
Occupation May Matter Less Than Expertise
People in software-related occupations achieve verified success in about 30% of their sessions, while users in other occupations achieve it in about 26%. In sessions that produce code (i.e., add or modify at least one line of code), these numbers are 34% and 29% respectively (Figure 6).
The gap between software-related and other occupations narrows under our looser success definition—both groups reach at least partial success in 89% and 88% of code-producing sessions, respectively.
This five-point gap is small, and it neither widened nor narrowed over the seven months, even as both groups' success rates improved. In code-producing sessions, every one of the ten largest occupations in our dataset is within seven percentage points of software engineers on verified success.
Management occupations score highest on verified success, slightly above software engineering occupations. Their higher verified success may reflect management skills transferring to steering agents. But it may also partly reflect our measure: verification relies partly on explicit confirmations in the transcript, and managers may be more likely to communicate when they get what they asked for.
Figure 6: Verified and Adjudicated Success Rates in Coding Sessions by Inferred Occupation
Share of sessions meeting strict success definitions—adjudicated success and verified success—by the user's inferred occupational group, for the ten largest groups, in sessions that add or change at least one line of code. Every group is within seven percentage points of software/math users (SOC code Computer and Mathematical Occupations). Error bars are 95% confidence intervals clustered by distinct accounts.
Looking Ahead
The results in this report offer a preliminary picture of how agentic coding amplifies certain forms of knowledge and skill while substituting for others. In sessions that produce code, every major occupation's success rate is within a few percentage points of software-related occupations. Coding agents appear to be making coding background less relevant to successful programming.
At the same time, successful sessions are more likely to demonstrate domain expertise. Sessions rated expert achieve verified success more than twice as often as novice-rated sessions, and when sessions encounter trouble, novices abandon them at multiples of the rate of others. The shape of the collaboration adds further color—domain experts are able to direct Claude to do more work with each prompt they give.
So the ability to steer Claude to success comes more from mastery of the domain than from the ability to write code. Anyone with that kind of mastery in any domain may now be able to do technical work they couldn't before. Those without any such expertise will get far less from the same tool. And the returns come mainly from competence, not mastery—working mastery of a domain captures most of the returns, while deep specialization adds only a little more.
These findings are preliminary. As with most of our research, we cannot measure real-world outcomes like whether code written in a session is actually used or later discarded, or whether it produces economically valuable artifacts.
Also, non-interactive use—which this report excludes—is a substantial fraction of activity. Developing measurement frameworks for it is a priority for future work. All of our session classifications rely on models reading transcripts.
In the appendix, we show that our classifiers track independent telemetry in the expected directions and agree with a strong reference model on most sessions. But classifiers remain challenging to validate at scale, and Claude Code sessions add further difficulty because they can be too long and complex for human labels to serve as ground truth.
The picture in this report will update as models, users, and the division of labor between them change. We hope these measures will let us track major shifts as they happen. For example, if the returns to expertise start to fall over time, that would suggest models are starting to supply the basic judgment users currently bring, and the tools' benefits are expanding beyond domain experts.
If the share of coding sessions successfully completed by users outside software occupations continues to grow, that may signal software production is becoming a routine part of work in every domain, not the product of a single occupation.
These shifts will change who benefits from agentic coding, and how much, with consequences for what is valued most in the labor market.