Anthropic put a number on the thing everyone argues about at standup: across 100,000 real Claude conversations, the median task got done in 84% less time than a human professional would have needed alone. Round it off and you get the figure that's been pasted into slide decks ever since — AI makes you roughly 80% faster.
I keep seeing that number quoted as a promise about your sprint velocity. It isn't. The study is careful about what it measured, and the whole game is in the gap between "84% faster per task" and "your team ships 84% more" — which is where all the interesting engineering lives.
What the study actually counted
The method is worth understanding before you trust the headline. Anthropic took 100,000 anonymized Claude.ai transcripts and, for each one, had the model estimate two things: how long the task would take a human professional without AI, and how long it took with Claude. Those tasks were mapped onto the O*NET occupational taxonomy and aggregated.
The results:
- Median time saving: 84%, ranging from 20% (checking diagnostic images) to 95% (compiling information).
- Average un-assisted task length: 1.4 hours.
- Median implied labor cost per task: $54.
Two things to hold onto. First, this is a per-task estimate. Second, it's an estimate made by the model itself, not a stopwatch on shipped work. The authors validated it: estimates were self-consistent across reworded prompts (r = 0.89–0.93), and against 1,000 software tasks with tracked times Claude's ranking correlated at ρ = 0.44 — near the developers' own ρ = 0.50, with a known bias toward underestimating long tasks and overestimating short ones. So 84% is a defensible central estimate of time to a good first output. It is not a measurement of a finished, reviewed, merged deliverable.
From 84% per task to 1.8% for the economy
The headline economic number is much smaller, and it does far more work. Aggregating with Hulten's theorem — weighting each task's speedup by the share of a worker's time it consumes and that occupation's share of the US wage bill — the paper lands at 1.8% of additional annual labor-productivity growth, assuming universal AI adoption over a decade. (Software developers alone account for 19% of that total.) Apply the 0.64 labor income share and it implies a total-factor-productivity bump of a bit over a point.
That's the optimistic read, and the authors say so plainly. Price in task reliability — the fact that a first draft usually isn't a finished thing — and the same analysis roughly halves the estimate, from 1.8 down to about 1.0 point. Why the two numbers diverge is the most useful idea in the paper, and it's an old one.
Amdahl's Law is the tax you keep forgetting
A per-task speedup only touches the slice of your day spent on that task. This is Amdahl's Law, dragged out of 1960s parallel computing and applied to your workday:
def overall_speedup(task_fraction, task_speedup):
# Only the accelerated slice of the day gets faster.
sequential = 1 - task_fraction
return 1 / (sequential + task_fraction / task_speedup)
# An 84% time cut on a task == ~6x speedup on that task.
# But writing code is only ~30% of a developer's day.
print(overall_speedup(0.30, 6.25)) # -> 1.34 (about 34% faster overall)
Writing and testing code is only 25–35% of a developer's day. The rest is reading tickets, gathering context, waiting on review, writing docs, and coordinating across teams. Make the coding slice six times faster and the whole day moves by about a third — not 84%. That's why independent 2026 estimates keep converging on system-level gains closer to 10%, even while task-level speedups stay enormous.
And the bottleneck doesn't vanish; it relocates:
Growth may be constrained not by what we are good at but rather by what is essential and yet hard to improve.
At Anthropic itself, human code review became the new constraint once AI was writing code at scale.
The work the transcript never sees
There's a second leak, and it's bigger. The transcript ends the moment Claude answers — it never records the 40 minutes you then spend verifying the output, chasing the bug it introduced, or realizing the approach was wrong. The paper explicitly excludes this refinement work, and points at randomized trials that measured what happens when you do count it: results landing at 56%, 40%, 26%, and 14% time saved, plus one that found negative savings on end-to-end software features.
The sharpest data point isn't in Anthropic's paper at all. In a 2025 METR randomized controlled trial, experienced open-source developers working in mature repositories were 19% slower with AI tools. They believed they had been 20% faster. That 39-point gap between felt and measured productivity is the whole reason self-reported speedups — including your own gut sense that AI "obviously" saves you hours — are close to worthless as evidence.
Now hold that next to the GitHub Copilot experiment, where developers wrote an HTTP server from scratch 55% faster. Both results are real. A greenfield, self-contained task in a controlled setting: a huge win. A real feature in a codebase you first have to understand: often a wash. The variable was never the model. It's how much of the work is the part AI is actually good at.
Measure your own slice, not the vibe
The move isn't to trust 80%, and it definitely isn't to trust the feeling. It's to measure the slice:
- Estimate your real
task_fraction. What share of your week is genuinely the generatable part — net-new code, boilerplate, first drafts? Be honest; it's smaller than it feels.
- Time the whole loop. Include verification and rework, not just time-to-first-answer. That's the only number that ties out to shipped work.
- Watch the moved bottleneck. If AI doubled your PR output but review is now backed up two days, your system got slower.
Then plug your real fraction into the snippet. The uncomfortable part: if coding is 30% of your day, your overall speedup is capped at 1 / (1 - 0.30) = 1.43x no matter how good the model gets — even an infinitely fast model can't touch the other 70%. Getting past that ceiling isn't a better autocomplete. It's handing AI a larger, more reliable share of the day — the reviewing, the context-gathering, the coordination — which is precisely the work these studies show it's worst at today.
The 84% is real. It's just answering a different question than the one on your roadmap.
Sources: Estimating AI productivity gains — Anthropic, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot — arXiv