After Reading Anthropic’s 400K Claude Code Session Report, I’m More Certain of One Thing

After reading Anthropic’s new report on Claude Code, I’m more certain of one thing:

What AI coding truly changes isn’t just “who can write code.”

What it’s changing is this: as long as you deeply understand your own problem, you have a chance to push technical work — which previously had to be handed off to engineers — to a verifiable, deliverable state.

But conversely, it hasn’t made “professional judgment” unimportant.

Quite the opposite. The most interesting conclusion in the report is: the better you understand the problem, the more you can make Claude do more, more complex, and more valuable work.

This report analyzed roughly 400,000 interactive Claude Code sessions between October 2025 and April 2026, covering about 235,000 users. It doesn’t look at demos or benchmarks — it looks at real usage: how people and agents actually divide work, which tasks are more likely to succeed, and who gets more value from the tool.

I think there are 5 points especially worth unpacking.

First, the real division of labor isn’t “AI thinks for you,” but “humans decide what, AI handles how.”

There’s one critical data point in the report:

In a typical Claude Code session, humans make about 70% of the planning decisions — deciding what to do, which direction to take, and what counts as done.

Claude handles about 80% of the execution decisions — which files to modify, what code to write, what commands to run, and how to specifically implement things.

This aligns very closely with my recent experience using coding agents.

The truly effective way to work isn’t throwing a vague wish at AI:

“Build me a page.”

Instead, it’s defining the task clearly first:

What problem does this page solve? Which files can be modified? Which files are off-limits? What screenshots, tests, command results prove it’s really done? If it fails, how do I preserve the scene and continue fixing?

You realize AI doesn’t make humans unnecessary.

Rather, human work shifts from “hand-writing every line of code” to “defining tasks, judging results, and controlling boundaries.”

This is probably the most core skill shift caused by AI coding.

Second, Claude Code’s use cases are shifting from “fixing code” to “operating software and completing workflows.”

The report categorizes Claude Code sessions into 9 work modes.

About 56% of sessions are still directly writing code, fixing code, testing, or orchestrating code; but a large portion is no longer just about writing code itself.

For example, operating software — deployment, configuration, running pipelines, monitoring systems — accounts for 17%.

Planning/exploring is about 14%.

Analyzing data and writing documentation also account for 13%.

More importantly, from October 2025 to April 2026 (7 months), the task structure changed significantly:

The share of “fixing broken code” sessions dropped from 33% to 19%.

Operating software rose from 14% to 21%.

Writing and data analysis went from about 10% to 20%.

What does this mean?

Tools like Claude Code are evolving from “code repairmen” into a more general-purpose work execution system.

It doesn’t just help you write functions.

It starts participating in deployment, configuration, data analysis, documentation, communication materials — all the surrounding aspects of technical work.

So now when I look at tools like Codex, Claude Code, Cursor, I increasingly ask not just:

“Who writes better code?”

I want to know:

Can it understand context? Can it reliably modify files? Can it run its own verification? Can it bring back failure logs? Can it distill experience into rules for next time?

The next phase of AI coding competition probably won’t be about single code output, but about workflow.

Third, experts aren’t the fastest to be replaced — they’re the ones who can amplify the tool the most.

One of the most counterintuitive and important conclusions in this report is that domain expertise still has sustained returns.

The report says Claude judges a user’s expertise on the current task from novice to expert based on the session.

This expertise isn’t about job title, education, or even “whether you’re a programmer.”

It’s more like: can you accurately describe the problem? Do you know what to ask Claude to verify? Can you pull it back when Claude deviates?

Here’s an example from the report:

A senior engineer asking a Rust question for the first time might still be a novice in Rust.

But an accountant who has never written Python, if they can clearly tell Claude what rules the month-end reconciliation script must follow and can catch edge cases — they are an expert on that task.

This definition is crucial.

It separates “can you write code” from “do you understand the problem.”

The report found that expert users trigger longer action chains per prompt.

In a typical novice session, each prompt leads to about 5 Claude actions and 600 words of output.

In an expert session, the action chain is more than double — about 12 actions, outputting roughly 3200 words.

That is, the better you understand the problem, the more you can get AI to do.

Not because they’re better at writing prompts, but because they know where to steer the AI.

Fourth, “whether you’re a programmer” may matter less than “do you understand the domain.”

There’s another interesting comparison in the report:

For software-related occupations, the overall verified success rate is about 30%.

For other occupations, it’s about 26%.

If we only look at sessions that generate code, software-related occupations are 34%, others 29%.

There’s a gap, but not as big as many might imagine.

In sessions that generate code, among the top ten largest occupation categories in the sample, the success rate gap between each category and software engineers is within 7 percentage points.

What does this mean?

AI coding is making “coding background” less decisive.

A person who understands finance, law, design, or business processes — as long as they can articulate the problem clearly — has a chance to get an agent to complete technical work that was previously difficult for them.

But this doesn’t mean expertise is unimportant.

It just shifts the importance of expertise from “can you write code” to “can you define problems, judge results, and spot deviations.”

That’s why I increasingly believe that many people’s future competitiveness won’t hinge on “whether they can invoke AI,” but on:

Do you have clear enough domain judgment to make AI do the right thing?

Fifth, success isn’t “looks like it’s done” — it’s supported by verifiable evidence.

The report’s definition of success is also worth noting.

It doesn’t simply ask users “are you satisfied.” Instead, it uses a transcript classifier to determine whether the session completed the goal, and also checks for hard verifiable signals.

For example:

Is there a matching git commit or PR? Did tests pass? Did the user explicitly confirm the result?

In other words, verified success isn’t “AI explained confidently,” but “there’s evidence it actually succeeded.”

This point is very important for our daily use of AI in coding.

Often, the most dangerous thing about AI isn’t that it writes wrong code.

It’s that it writes wrong code and still explains it very smoothly.

So now when I assign tasks to coding agents, I increasingly prefer to write acceptance criteria first:

What’s the goal? What’s the scope? What evidence proves completion? What side effects are not allowed? How to roll back on failure?

If a task has no verification method, I won’t trust the agent to run it for long.

The report also had a macro conclusion:

The estimated economic value of tasks in Claude Code rose over the 7 months.

The report estimates task value using a method similar to freelance job postings, emphasizing not to take the numbers as absolute values, but to look at trends.

From October 2025 to April 2026, the estimated value per average session rose about 27%.

Values for building, operating, and fixing tasks all increased by about one-third or more.

This suggests that what agentic coding does is becoming more complex, more complete, and closer to real work delivery.

My biggest takeaway after reading:

AI coding isn’t turning everyone into software engineers.

It’s more like taking “technical implementation ability” out of a few professions and distributing it to those who truly understand the problem.

If you’re in finance, you might be able to automate reconciliation yourself.

If you’re in law, you might be able to build your own contract clause checking script.

If you’re in design, operations, research, or management, you might also turn repetitive processes in your field into a runnable, verifiable, reusable system.

But the prerequisite isn’t how much code you can write.

The prerequisite is that you really understand that problem.

You know where errors are likely. You know what results count as correct. You know which boundaries you can’t cross. You know how to pull AI back when it goes astray.

That’s also why I don’t believe “prompt techniques” will be a long-term moat.

The long-term moat is more likely:

Domain judgment. Task decomposition ability. Acceptance criteria. Understanding of workflows. And the ability to distill one experience into rules for next time.

One sentence summary of this report:

AI coding lowers the bar for “writing code” and raises the value of “defining problems.”

So next, I want to keep running an experiment:

Not just chasing new tools.

But for every AI coding task, I break it down into:

• What exactly do I want it to accomplish
• What boundaries did I set
• How does it verify results
• Where did it misunderstand me
• Which experience can be distilled into a rule for next time

If this experiment works, the way ordinary people use AI won’t be “chatting with a model” anymore.

It’ll be building their own work system.

This might be the most noteworthy aspect of the Agent Economy.

Report source: https://www.anthropic.com/research/claude-code-expertise