That is meaningful evidence about how an agentic coding tool is being used. It is not, however, proof that the winning strategy is to hand an agent a vague goal, stop supervising it, or expect a productivity gain. The study is observational, its key labels are model-derived from transcripts, and it cannot tell whether code produced in a session was later deployed, kept, or discarded.
What Anthropic examined
The study covers 398,198 uniformly randomly sampled interactive Claude Code sessions from 234,751 users between October 2025 and April 2026. It includes use through the Claude Code command-line interface, desktop app, and Claude.ai.
Those boundaries matter. It does not represent every coding-agent workflow: third-party IDE and SDK use was excluded, as were sessions with no human turns and Anthropic’s own internal usage. Windows developers who primarily work through an IDE integration, for example, should not assume the patterns precisely match their setup just because the underlying tasks may look similar.
The research also spans more than code generation in the narrow sense. The supplied findings indicate that 56% of sessions involved writing, fixing, testing, or orchestrating code, while 17% involved operating software. That broader mix helps explain why “Claude Code” session data should not be treated as a clean measure of programming speed alone. An agent session can include investigation, environment work, testing, and operational tasks as well as edits.
The central pattern: humans plan, Claude executes
Anthropic’s descriptive measure of decision-making found that users made roughly 70% of planning decisions, while Claude made roughly 80% of execution decisions. In practical terms, the person commonly set the objective, constraints, and direction, while the agent performed many of the intermediate actions.
A typical user prompt triggered about 10 Claude actions. The number changed substantially with the observed division of responsibility:
- Sessions in which users retained more than 80% of execution decisions averaged about eight actions per user turn.
- Sessions in which Claude made more than 80% of planning decisions averaged about 16 actions per user turn.
It would be tempting to turn this into a rule that developers should always delegate more planning and reduce oversight. The data do not establish that. A long-running agent sequence may reflect a well-scoped complex job, but it can also reflect a difficult repository, multiple failed attempts, or a user willing to let the tool explore. More actions are not automatically better code, faster delivery, or lower risk.
The more useful interpretation for Windows developers is that a coding agent can take on a substantial execution role once a task is sufficiently intelligible. That still leaves the human with responsibilities an action count cannot measure: selecting the right task, protecting credentials and production systems, reviewing changes, judging design trade-offs, and deciding whether a proposed solution belongs in the codebase.
“Expertise” is not a job-title ranking
One of the study’s most easily misunderstood findings concerns expertise. Anthropic did not independently test users’ coding ability, identify their job roles, or assign credentials. Its “expertise” measure is task-specific and model-classified from the transcript.
The classification considers factors such as how precise the user’s instructions are, whether the user requests verification, and whether the user or Claude corrects the other. It therefore describes the interaction as recorded in a particular session. It should not be read as evidence that a person is generally a novice or expert programmer.
That distinction is especially important when interpreting the reported gaps. Sessions rated as novice averaged about five Claude actions and approximately 600 words of output per prompt. Expert-rated sessions averaged about 12 actions and 3,200 output words per prompt.
There are several plausible explanations, none of which this research can separate conclusively. More experienced users may bring harder tasks that need more tool activity. They may be more comfortable asking for investigation, testing, and iterative changes. They may provide better constraints from the start. Or the classifier’s identification of precision and verification behavior may naturally align with longer and more elaborate exchanges.
The safest conclusion is not “more experienced developers should micromanage less.” It is that productive agent interaction appears to involve an ongoing ability to specify, inspect, correct, and validate work. Those are practical skills, but the study does not prove a single prompting formula causes them to produce better outcomes.
Success numbers need careful reading
Anthropic reported that classifier-defined verified success rose with apparent expertise. Novice-rated sessions reached verified success 15% of the time, compared with 28% to 33% for intermediate-or-higher groups.
For sessions containing trouble signals, the difference was larger: verified success increased from 4% for novice-rated sessions to 15% for expert-rated sessions. That suggests users who can recognize and respond to trouble may be better positioned to recover an agent workflow.
But “verified success” has a limited technical meaning here. It can include passing tests, a matching commit or pull request, command output that successfully matches an objective, or explicit user confirmation. It is valuable to distinguish such evidence from an unverified answer in a chat window. Yet it is not equivalent to a production-ready or economically useful result.
Anthropic cannot observe what happens after the session. It cannot determine whether the code or artifact was adopted, maintained, deployed, or ultimately discarded. Its classifications also rely on model readings of transcripts that can be long and complex. A successful test run, for example, does not settle whether a change meets business requirements, follows local security policy, or introduces a regression outside the tested path.
For a Windows development team, that limitation has a direct operational consequence: an agent’s apparent completion should remain an input to review, not the end of the engineering process. Existing protections—version control, code review, automated tests, dependency checks, and environment-specific validation—still determine whether output is safe to merge or run.
The “abandoned” figure is narrower than it sounds
The study’s abandonment measure also needs translation before it is used as a measure of user frustration. For troubled sessions, it counts a session as abandoned only if it was judged to have failed and telemetry recorded zero lines of code added.
Under that definition, 19% of novice-rated troubled sessions were abandoned, compared with 5% to 7% for other expertise levels. This is a noteworthy association, but it does not mean 19% of users simply gave up on Claude Code. A developer might leave a session with no code added because the task was exploratory, because the problem was diagnosed but deferred, or because the useful outcome was operational rather than an edit. Conversely, code being added says little on its own about its quality or future use.
The data do support a more restrained observation: when a session was both troubled and classified as failed, novice-rated interactions were more likely to meet this especially strict no-code-added definition than higher-rated groups.
Verification is a habit, not a magic phrase
The report links apparent expertise to instruction precision and requests for verification. That is a sensible signal for engineers, but it should not be overextended into unsupported advice about exact phrasing.
The research does not experimentally show that a generic request to “double-check” is inferior to a targeted request, nor does it establish that asking only for an end goal is superior to detailed guidance. Targeted validation remains a rational engineering practice because it produces concrete evidence: a specified test, expected command result, code review criterion, or reproducible check. But that recommendation comes from the need to manage uncertainty, not from a controlled comparison in this dataset.
A practical workflow for Windows users is therefore to make the desired evidence explicit when the task warrants it. Instead of treating a response as complete because it sounds plausible, define what would count as confirmation in the relevant project: tests passing, the expected files changing, a build result, or a review of the proposed diff. The appropriate level of supervision should scale with the task’s risk. A disposable local experiment is not the same as a change touching customer data, deployment scripts, authentication, or a shared repository.
Why this is not yet a productivity verdict
The study’s workflow patterns should not be converted into a universal claim that agentic coding makes developers faster. A separate randomized study by METR examined 16 experienced open-source developers completing 246 tasks with early-2025 AI tools and found that tool access increased completion time by 19% in that particular setting. The work involved mature repositories, where understanding established conventions and validating changes can be costly.
That does not negate Anthropic’s session analysis, because the studies ask different questions and examine different conditions. Anthropic describes observed interactions in a large set of its own product sessions; METR tested completion time in a controlled setting with a small group of experienced developers and an earlier generation of tools.
The timing and tooling question remains unsettled. METR later said newer data contained raw signs that newer tools might speed work up, but selection effects made the resulting productivity estimate unreliable. In other words, it is possible that agent capability and user practice are changing quickly, but the available evidence still does not justify a precise current claim about average productivity.
Anthropic also reported that its estimated value measure rose 27% from October 2025 to April 2026, while explicitly treating the measure as coarse. That may indicate that the tasks being handled became more consequential by the study’s definition. It does not show a 27% increase in business value, developer output, or software quality.
The practical takeaway for Claude Code users
The strongest lesson from the session data is not to abandon control. It is to use control deliberately. People in these sessions commonly retained planning responsibility while allowing Claude to perform many execution steps, and higher apparent task expertise was associated with more extensive workflows and better classifier-defined outcomes.
For individual developers, the durable skills are likely to be task framing, repository awareness, and verification—not a reflexive choice between tightly scripted prompting and unrestricted autonomy. Give an agent enough context to pursue the intended objective, but keep humans accountable for scope, acceptance criteria, sensitive actions, and final judgment.
For teams, the evidence argues for measuring results in their own environment rather than importing a productivity claim from a broad usage study. Track the outcomes that matter locally: review burden, defects, test coverage, completion time, rework, and whether generated changes survive into maintained software. The value of an agentic workflow will depend on the codebase, the task, the tools available, and the team’s capacity to verify what the agent does.
Anthropic’s dataset is large enough to show that agentic coding is becoming a substantial, multi-step mode of work. It is not large enough—or designed in the right way—to settle whether more delegation causes better code or faster engineering. That distinction is exactly what responsible Claude Code adoption should preserve.