What separates someone who gets the most out of a coding assistant from someone who gets stuck on the very first problem? Anthropic analyzed roughly 400,000 sessions with Claude Code, and the answer was surprising. It is not the ability to write code. It is knowledge of the field in which the person works.
The researchers tracked sessions from roughly 235,000 people between October 2025 and April 2026. They used a privacy-preserving tool, so no one read the individual transcripts. They focused on three things: what work was being done with the assistant, who was doing it, and whether it was successful.
You decide what, the assistant figures out how
Let us start with how this kind of collaboration actually works. The researchers divided every decision in a session into two types. Planning means deciding what should be done, which approach to take, and when the work is complete. Execution concerns the details: which files to change, what code to write, and which commands to run. And this revealed a clear division of labor. On average, people make around 70 percent of the planning decisions, but only about 20 percent of the execution decisions. The person says what they want to build, and the assistant figures out how to do it.
How much does Claude do between two prompts? A typical session has around four exchanges. Each human prompt triggers an average of about ten assistant actions, sometimes more than a hundred. During each of them, Claude reads files, edits code, runs commands, and produces an average of 2,400 words of output. The more control a person retains over execution, the less the assistant does on its own. Conversely, when the person also entrusts it with planning, the number of actions soars.
An accountant who has never written Python can be an expert
The researchers did not assess expertise based on job title or a person's general abilities. They measured expertise in relation to a specific task. What does that mean in practice? An experienced engineer asking about Rust for the first time is a Rust beginner. Conversely, an accountant who has never touched Python but tells Claude exactly which rules a reconciliation script must follow and shows an example that would cause it to fail during the monthly close is an expert in that task.
A classifier identified expertise using three signals: how precisely the person formulates their instructions, what they ask the assistant to verify, and whether the person tends to correct the AI or the AI tends to correct the person.
The main difference between beginners and experts appeared in the output. In beginner sessions, one prompt triggers about five actions and around 600 words. For experts, there are more than twice as many actions and five times as much output, or roughly 3,200 words. The more a person knows about the field, the more high-quality work they get from the assistant.
The work changed over seven months
The mix of tasks for which people use Claude Code shifted noticeably over the period studied. The most significant change was in fixing broken code. Its share fell from 33 to 19 percent. Instead, work surrounding code increased. Software operations, meaning deployment, configuration, and execution, rose from 14 to 21 percent. Document writing and data analysis roughly doubled, from about 10 to 20 percent of sessions.
And it was not just about volume. The tasks themselves became more valuable. The researchers estimated their value by comparing them with job listings on the freelance market. By this measure, the value of an average session rose by 27 percent between October and April. Building, operating, and fixing all became roughly a third more expensive or more. The authors acknowledge that these estimates are rough, so they are better suited to comparing tasks with one another than to providing exact amounts.
Beginners give up, experts get back on track
Those who bring domain knowledge are more successful. This holds across all the measures of success the researchers used. Sessions rated as beginner-level met the strictest threshold, known as verified success, in 15 percent of cases. They achieved at least partial success in 77 percent. Sessions from advanced users and above achieved verified success in 28 to 33 percent of cases and partial success in 91 to 92 percent.
What is interesting is where that jump occurs. Most of the gain comes from moving from beginner to advanced. The difference between advanced users and experts is only modest. A solid understanding of the field is therefore enough; complete specialization adds only a little more.
This is most apparent when something goes wrong. Among sessions that encountered a problem, the verified success rate rose from 4 percent for beginners to 15 percent for experts. Then there is the other side. If a person gave up on the project without writing a single line of code, the researchers call it an abandoned session. Among beginners, 19 percent of problematic sessions ended this way. For everyone else, it was only 5 to 7 percent. Less experienced people simply give up when they struggle. An experienced person knows how to guide the assistant back in the right direction.
Profession matters less than you might expect
But what if the success simply comes down to programmers being programmers? The data does not provide much support for that assumption.
People in software-related fields achieved verified success in roughly 30 percent of sessions. People in other professions did so in 26 percent. In sessions where at least one line of code was produced, the figures were 34 and 29 percent. A five-point difference is small, and over seven months it neither widened nor narrowed, even though success rates rose for both groups.
And now for the best part. Among sessions producing code, each of the ten largest professions in the data came within seven points of software engineers. People in management roles achieved the highest verified success rate, slightly ahead of engineers. This may be because management skills transfer to directing an assistant. The ability to assign a task clearly and explain what you expect from it is simply useful, whether you are talking to a person or a program.
What the study still cannot measure
The authors are cautious about the conclusions. They themselves write that these are preliminary findings. They cannot see whether anyone ultimately used the code written during a session or whether it ended up in the trash. The analysis also excluded all non-interactive work, meaning a great deal of automated execution in which Claude works without a person at the keyboard. And all assessments depend on how the model interprets the session transcript, which is difficult to verify at scale.
The study was written by Zoe Hitzig, Maxim Massenkoff, Eva Lyubich, Shaoyi Zhang, Ryan Heller, and Peter McCrory from Anthropic's research team.
