AIDiveManagers beat developers at AI coding
Anthropic had a classifier grade 400,000 Claude Code sessions, one by one, to find out who actually succeeds with a coding agent. The group with the best verified success rate is not the software engineers. It is the managers. The ten biggest occupation groups in the study all land within seven points of the developers, which means people who do not write code are shipping code that works at almost the same rate as people who do it for a living.
If you have ever told yourself these tools are not for you because you cannot code, this study says the exact opposite. Knowing how to code no longer separates the people who succeed from the people who fail, and the study says precisely what does.
What Anthropic actually measured
Three definitions change how you should read every number in the study. First, the sample: 400,000 interactive sessions from 235,000 people, recorded between October 2025 and April 2026. Claude Code is Anthropic's coding agent living in a terminal: you write what you want in plain language, and it reads your files, writes the code, and runs the commands on its own.
Nobody at Anthropic read those conversations manually. A classifier built on one of their own models graded every session automatically, and its grades were checked against telemetry, meaning the commits, the code changes, and the test results. On sessions that modify code, the classifier and the telemetry agree more than 90 percent of the time.
Second, success. The study tracks two kinds, and the difference carries everything that follows. A judged success means the classifier believes the stated goal was reached. A verified success is harder: it needs proof, such as tests that pass, a commit, or the user explicitly confirming the result. Verified success is the high bar behind every number below, and it is a demanding one, because plenty of useful sessions end without formal proof.
Third, expertise itself. The classifier never looks at your job title or your resume. It reads your behavior inside the session and grades it on a five-level scale from novice to expert, using only three signals: how precise your instructions are, what you ask the agent to verify, and whether either of you corrects the other. Your level measures your grip on the problem in that session, so the same person can be an expert on their trade in the morning and a novice on a new subject that night.
The five levels, from novice to expert
A novice is recognizable in one sentence: generic instructions with no domain knowledge folded in. An expert writes prompts loaded with context, and the same agent responds with far more autonomous work. An action here is one concrete move by the agent, like reading a file, writing a function, or running a command.
| Metric | Novice | Expert |
|---|---|---|
| Agent actions per prompt | ~5 | ~12 |
| Words of delivered work per prompt | ~600 | ~3,200 |
| Verified success rate | 15% | 28 to 33% (intermediate and up) |
| Abandon rate when a session goes wrong | 19% | 5 to 7% (all non-novices) |
| Troubled sessions converted to verified success | 4% | 15% |
That is five times the delivered work from the same tool on the same subscription. The only variable that changed is the person at the keyboard.
The detail that matters most: almost all of the gain happens between novice and intermediate, and the gap between intermediate and expert is modest. You do not need to become an expert to double your success rate. You need to stop being a novice.
The most brutal gap shows up when a session goes wrong. When the agent spirals into errors and breaking tests, novices abandon 19 percent of the time, against 5 to 7 percent for everyone else. Among the people who hang on, novices convert only 4 percent of those troubled sessions into verified successes, while experts convert 15 percent. That is almost four times as many sessions saved, purely because the person understands the problem well enough to redirect the agent instead of watching it sink. The difference between levels does not show when everything works. It shows at the first hiccup.
Why knowing how to code no longer matters
Domain expertise, in Anthropic's terms, is understanding the problem you are trying to solve, all the way down. On sessions that produce code, the occupational gap is small and stable:
| Group | Verified success | Partial success |
|---|---|---|
| Software occupations | 34% | 89% |
| All other occupations | 29% | 88% |
Five points of difference, a gap that neither widened nor narrowed across the study's seven months while both groups kept improving. On partial success, where the goal was at least partly reached, the two groups tie.
The study also shows where domain expertise acts. In a typical session, the human makes about 70 percent of the planning decisions (what to build) but only 20 percent of the execution decisions (how to write it). The split is already there: you decide the what, and the agent handles the how. A manager who knows exactly what their product should do is holding the lever that counts, even without writing a single line of what the agent produces. That is why managers end up at the top of the ranking.
Usage over the seven observed months confirms the center of gravity is moving:
| Task type | Start of study | End of study |
|---|---|---|
| Debugging | 33% of sessions | 19% |
| Running software | 14% | 21% |
| Data analysis and document writing | baseline | nearly doubled |
People are not just using the agent to repair code anymore; they are using it to run their work. Over the same period, the estimated value of the average task handed to the agent grew 27 percent.
Autonomy reframes your role the same way. A typical session holds only about four exchanges between the human and the agent, and each prompt triggers around ten actions on average. At the extreme, a single prompt sometimes sets off more than one hundred actions: one instruction, and the agent works alone for the equivalent of an afternoon. What you bring fits in a few sentences per session, which is exactly why their precision weighs so much. When you only speak four times, every sentence counts.
The same task, prompted like a novice and like an expert
We replayed the difference on a task everyone understands: adding a contact form to a small website.
The novice version is the prompt half of us still type: nine words, no context, no criteria. The agent does not know where the site lives, what the form collects, or where the messages go, so it makes every one of those decisions for you, and you discover its choices at the end. On our run, it dropped the form on the homepage, invented a phone field nobody asked for, and wired submissions to an email address that does not exist. None of that is a bug. The agent filled the holes in the request with guesses, and every guess was a chance to be wrong. That is the measured novice pattern: few actions, a short result, and roughly one chance in seven of a verified success.
The expert version handles the same task without a single line of code in the prompt. It says where to act (the about page), what to build (three precise fields), what to build with (the send route that already exists), and above all how to prove it is done (run the tests and show the form in the browser). Not one piece of that information requires knowing how to code. It requires knowing your site, your need, and your standard, which is your domain. The agent takes it from there: it reads the page, adds the form, wires the route, writes the validation, and runs the tests. That is the study's 12-action chain, triggered by the precision of the prompt, not by the technical talent of its author.
Writing the expert prompt took about thirty seconds more than the novice one, and those thirty seconds removed every opportunity the agent had to guess. The whole demonstration fits in one sentence: the same tool gets five times more productive when the request carries the domain.
Three habits that move you up a level
The first habit is giving the context only you know, before the agent guesses it wrong. The classifier calls this instruction precision. Every request should say where to act, with what, and what finished looks like. Three sentences are enough, and it works for any job, not just code: a marketing prompt with the audience, the constraints, and the finish line checks the same three blocks. If you cannot fill one of the blocks, that is the signal the fuzziness sits on your side, not the agent's, and it is worth clearing up before you launch the session.
The second habit is demanding proof at the end, the classifier's second signal. End your prompts with a checkable finish condition: run the tests, show me the result, check the page loads. An agent you ask for no proof will hand you unverifiable work, and the study shows that is exactly what separates a judged success from a verified one. That proof also protects you, because it lets you sign off on the work without knowing how to read the code behind it.
The third habit is staying in the loop when things start breaking. Reread what the agent returns, correct it when it is wrong, and do not close the session at the first failure. Novices accept output passively and abandon about four times more often than everyone else the moment it jams, yet this is precisely where the level pays off. Explaining the problem again in your own words and pointing at what does not match your expectation is correcting the agent, the classifier's third signal. The shape of a good correction: what is happening, what was expected, where to look. Still not a line of code, just an honest description of the gap.
The three habits fit on a sticky note: give your context, demand proof, stay in the loop. None requires learning to code, and together they cover the spread between 15 and 30 percent success.
What the study doesn't say
Even for experts, verified success caps out between 28 and 33 percent. Two sessions out of three end without solid proof the goal was reached, at best with a partial success, which does climb above 90 percent. Moving up a level doubles your odds; it does not make the agent infallible.
The managers' ranking deserves its own caution. Anthropic notes a measurement bias is possible, because verified success also counts explicit user confirmations, and clearly confirming that work is validated is a manager's reflex. On top of that, the study measures Claude Code sessions, a terminal tool whose audience is already more motivated than average, so nothing guarantees the same numbers hold in ChatGPT or any other tool. Keep the general slope, not the decimals: precision pays, proof pays, and nobody clears a third of certainty.
Your level is not a label
Should you jump in if you cannot code? The study answers by group. If you know your trade inside out (your domain, your customers, what a good result means), then yes. You are bringing exactly the half of the decisions that counts, the planning half. But if you are walking into a subject you do not understand yet, the agent will not fill that void; it will stuff it with guesses, like the contact form landing on the wrong page.
The takeaway fits in one decision: stop treating your lack of code as a handicap, and start treating your knowledge of the problem as your real capital. The classifier does not grade who you are; it grades how you work inside the session, and that can change as early as your next one. Write the request with your context in it, end it with the proof you demand, and when it jams, rephrase instead of closing. If you cannot code, you start with the same odds as everyone else. The study just proved it on 400,000 sessions.
