Users Set the Direction, AI Does the Legwork

The research splits every decision in a session into two types. Planning decisions cover "what to do, which path to take, what counts as done." Execution decisions cover "which file to change, what code to write, which language to use, which command to run." A classifier then judges whether the user or Claude made the call for each decision, producing two numbers per session.

In plain terms: humans set the direction, AI does the legwork. This division shows up consistently, session after session.

Look at it from another angle — swap "decisions" for "actions." A Claude Code session is a back-and-forth between human and Claude: the user writes an instruction, Claude goes and does a string of work, then the user writes the next instruction. A typical session runs about 4 rounds. Historically, each user instruction triggers about 10 Claude actions on average, sometimes more than 100. In each round, Claude reads files, edits code, and runs commands, producing about 2,400 words of output on average.

How much gets delegated basically tracks who's making the decisions:

Note: when users make over 80% of execution decisions themselves, Claude does only about 8 actions per round; conversely, when Claude holds over 80% of planning decisions, action counts peak at about 16.

Original Figure 2: how much of the planning and execution decisions in a session go to Claude. In a typical session, users make about 70% of planning decisions and Claude makes about 80% of execution decisions. Source: Anthropic

How Do You Tell Whether Someone Is an "Expert"?

"Expert" here measures how well someone understands the specific task at hand — it has nothing to do with job title or whether they can code. It's task-specific: a senior engineer asking a Rust question for the first time is a novice at Rust; an accountant who's never touched Python is an expert at this task as long as they can precisely spell out the reconciliation rules and catch the edge cases Claude misses during month-end close.

The classifier scores each session on a five-point "novice to expert" scale, looking at just three signals: how precise the instructions are, what verification the user asks Claude to do, and whether the human is correcting Claude or vice versa.

The two passages above are illustrative, meant to show the three signals the classifier looks at — not verbatim from the original. The original report's grading examples were drawn from the public agentic-coding session dataset SWE-chat, rewritten, anonymized, and condensed for use.

Expert Users Get Claude to Do More Work

The higher the expertise, the more Claude produces from the same instruction. In a typical novice session, each instruction triggers about 5 Claude actions and about 600 words of output; in an expert session, the action chain doubles to 12, and word output is 5x, about 3,200 words.

Claude Actions Triggered per Instruction

Word Output per Instruction

Original Figure 3: the more expert the user, the more actions (left) and words (right) Claude produces per instruction. White dots mark the geometric mean; both upward trends are statistically significant (p<0.001). Source: Anthropic

Expertise Predicts Success Better Than Coding Background

First, how success is measured. The research can't see users' real-world outcomes and can't ask directly — it relies on two yardsticks for reading session transcripts.

Measured with these two yardsticks, the pattern is clear: the more expertise a person shows in a session, the more likely it is to succeed. And most of the gains cluster at the low end of the scale — the gap from novice to intermediate is bigger than the gap from intermediate to expert.

So what about professional background? The research infers user occupation from session transcripts and maps it to the 23 major categories used by the U.S. Bureau of Labor Statistics. The result: among sessions that produced code, professional background matters far less than you'd expect.

(Verified success rate among code-producing sessions) — the gap is just 5 percentage points, and it neither widened nor narrowed over the 7 months. Loosened to "at least partial success," the two groups sit at 89% and 88% respectively.

Going further: among sessions that produced code, all 10 largest professions in the dataset fall within 7 percentage points of software engineers. Management occupations even edge out software engineers slightly on verified success — possibly because management skills naturally suit directing an agent, or possibly just because managers are more prone to explicitly saying "done" in conversation, and verified success partly depends on that kind of explicit confirmation.

Original Figure 6: verified success rate and judged success rate by inferred profession, code-producing sessions only (10 largest profession groups). Every group falls within 7 percentage points of software and math occupations. Source: Anthropic

After Things Go Wrong, Expert Users Recover More Easily

Expertise doesn't just matter when things go smoothly — the gap widens when a session hits trouble.

The chart below lays out "verified success rate" across the five expertise tiers. Toggle between all sessions and sessions that hit trouble, and you'll see that in troubled sessions, novices nearly collapse while experts hold up.

The most extreme case is "outright giving up" — a session judged a failure where not a single line of code got written. This is where novices diverge from everyone else the most:

The least experienced users give up when stuck at 3 to 4 times the rate of everyone else. Part of the value of expertise, it seems, is the ability to pull the agent back onto the right track.

One methodology detail: the "hit trouble" filter selects different sessions for different people. Experts run into trouble less often overall, so the sessions where they genuinely get stuck tend to be harder problems. Using task value as a proxy for complexity, the average value of troubled sessions roughly doubles from the lowest to the highest expertise tier. So part of the gap in recovery rate may come from novices getting stuck on routine problems while experts get stuck on genuinely hard ones — not purely a difference in resilience.

Original Figure 5: session outcomes by the user's expertise on that task. Left: all sessions; middle and right: sessions that hit trouble only (failure signal >3). Every point controls for work type, task value, month, topic, and profession. Source: Anthropic

Over 7 Months, What People Use Claude Code For Has Changed

The research sorts each session into whichever of nine work modes fits best. Four of them directly write or maintain code (building things, fixing things, testing, orchestrating other agents); the rest are operating software, figuring out how a system works, planning before acting, and non-code work like data analysis and documentation. Over 7 months, this mix has shifted.

The clearest shift: the share of sessions spent fixing broken code fell from 33% to 19%, nearly halved. The freed-up share flowed into work around the code.

Operating software (deploying, configuring, running pipelines, monitoring systems) rose from 14% to 21%; documentation and data analysis combined roughly doubled from about 10% to 20%. People are increasingly using Claude Code across the full end-to-end scenario, not just the coding stretch.

The tasks themselves are also worth more. The research benchmarks each session against freelance-market pricing to estimate value; the typical session's estimated value rose about 25%–27% over the 7 months, with gains across nearly every category of work.

These prices are rough estimates, meant only to compare relative changes across tasks and over time — not to be read as real dollar amounts.

Original Figure 4: share of sessions by work mode, October 2025 to April 2026. Bug fixes fell from 33% to 19%, while ops, data analysis, and documentation rose in tandem. Source: Anthropic

What These Numbers Can Tell Us So Far

Let's list what this data can actually support — sticking to what the yardsticks measured, without extrapolating.

First, among sessions that produced code, success rates across every industry are converging on software practitioners' — coding background matters less and less for coding success. Second, how well someone uses it depends more on their understanding of the problem itself, regardless of their field. Third — and this is a point the report keeps hammering — the bulk of the payoff comes from "good-enough proficiency": the jump in success rate from novice to intermediate dwarfs the small gain from intermediate to expert.

The staircase below charts "verified success rate rising with expertise" — steep at first, flattening later. That's exactly the shape of the returns in this data.

A few boundaries worth keeping in mind: the research can't see real-world outcomes — whether the code written in a session ended up used or discarded, for instance. The non-interactive usage excluded here (headless and API batch) is a substantial chunk, and figuring out how to measure it is a priority for next steps. And every classification depends on an AI model reading the session transcript — large-scale verification is inherently hard, and Claude Code sessions are long and complex enough that human annotation is difficult to treat as ground truth.

As models, users, and the division of labor between them keep evolving, this picture will keep getting updated. The researchers say the signals worth watching going forward include whether the returns to expertise start to decline, and whether the share of successful sessions from non-software professions keeps growing.

Turning These Findings Into What You Do Tomorrow

The original report ends here — it's pure data analysis and offers no how-to advice. But the three signals it uses to measure "expertise," read in reverse, amount to a checklist for using Claude Code more smoothly. The points below are reverse-engineered from the research's characteristics, for your reference.

The research splits every decision in a session into two categories: "what to do" (setting direction, choosing the path, what counts as done) and "how to do it" (which file to change, what code to write, which command to run). Who calls the shots becomes clear once you run the numbers.

A session runs about 4 rounds of back-and-forth. For every instruction the user gives, Claude runs about 10 actions on its own (reading files, editing code, running commands) on average, sometimes more than 100. The division of labor is stable — but the real question is: what kind of person makes this division of labor produce good results?

"Expert" in this research isn't about job title or whether you can code — it's purely about how well you understand the task at hand. A senior engineer touching Rust for the first time is still a novice; an accountant who's never written code is an expert at this task as long as they can spell out the reconciliation rules and catch the month-end edge cases Claude misses.

By this standard: the more someone understands, the more likely the session succeeds, and experts get Claude to do more per instruction (novices get about 5 actions and 600 words; experts get about 12 actions and 3,200 words). But the way success rate climbs has a shape — steep at first, flat later.

Stack "verified success rate" into five steps by expertise tier: XiaoHu climbs from novice to expert, and the ground rises higher underfoot each time (a higher share of sessions succeed) — but each step up adds only a little more. The bulk of the payoff sits in the "novice to good-enough" stretch, not in "good-enough to top-tier." (The middle three tiers are illustrative interpolation; the actual measurements only report 15% for novices and 28–33% for intermediate-and-above.)

"15% vs. 33% success rate" is too abstract. Reframe it as running 100 sessions each and counting how many actually get done, and it clicks. "Done" here is the strictest yardstick — verified success: not just judged a success, but backed by hard evidence — code actually committed, tests actually passing, or the user explicitly saying it's done.

Even more surprising: profession barely matters. Among sessions that produced code, the success rates of the dataset's 10 largest professions all sit within 7 percentage points of software engineers, with management roles even slightly ahead. Over 7 months, the share of sessions spent fixing bugs fell from 33% to 19%, and the freed-up effort flowed into ops, documentation, and data analysis — the end-to-end work. Task value also rose about 25–27% (benchmarked against freelance pricing — read this as relative change only, not real dollar figures).