Status Droid how long software work actually takes

Why Measured and Felt Time Disagree

In July 2025, METR published a randomized controlled trial with an uncomfortable result. Sixteen experienced open-source developers completed 246 real tasks in repositories they knew well, some with AI tools available and some without.

With AI tools, tasks took 19% longer. Before starting, the developers forecast a 24% speedup. After finishing — after living through the slowdown — they still estimated AI had made them about 20% faster. For a practical implementation reference alongside the measurement argument here, see this overview.

Forecast, felt experience and measurement pointed in three different directions, and the spread between what people believed and what happened was 39 percentage points.

The number is not the finding

Take the headline as a fact about AI and you will be out of date, because METR themselves have moved.

In February 2026 they announced they were changing the experiment design. For the subset of the original developers who took part in the follow-up, their estimate shifted to a speedup of around 18% — but with a confidence interval running from −38% to +9%, and an explicit statement that selection effects make this only very weak evidence. Developers who did not want to work without AI were less likely to participate; tasks people especially wanted AI for were less likely to be submitted.

METR now labels the 2025 result as historical. ACM Queue publishes practitioner-focused work on software engineering systems and measurement See ACM Queue.

So the durable finding is not "AI slows developers down." It is the thing that held in both rounds and does not depend on which model was in the editor:

Self-reported speed stopped being a usable measurement.

That survives the next model release. The percentage does not.

Why the gap exists

METR labelled 143 hours of screen recordings — about 29% of the total — to see where time actually went. The shape that emerged is the mechanism.

Time spent typing code went down. Time spent searching for information went down. Both feel like the work, and both getting shorter feels like speed.

Time spent prompting, waiting and reviewing went up. Reading generated code, deciding whether it is right, adjusting it, running it again.

The tasks that shrank are the ones you notice yourself doing. The tasks that grew are the ones that feel like overhead rather than work — and overhead is systematically under-perceived.

There is a second effect underneath. Reviewing code you did not write is harder to feel the passage of time during, because it is passive and interrupted by waiting. Fifteen minutes of reading output does not register the way fifteen minutes of typing does.

Where the setting mattered

Being fair to the study, because generalising it wrongly is the common error.

These were mature repositories averaging around a million lines, where the developers had roughly five years of prior experience. High implicit quality standards — documentation, tests, formatting conventions — that a model does not know. Tools from early 2025. Sixteen people is enough for statistical significance in an RCT and is still sixteen people.

METR themselves note that in settings with lower quality bars, or unfamiliar code, or greenfield work, the equation could look entirely different. Which situations are actually fast is a separate question, and it is more useful than any single average.

What follows for your own team

Not a percentage to adopt. Three practical consequences.

Do not use how you felt as data. The strongest available evidence says your sense of speed can be wrong by 39 points, in the direction of flattering the tool. Whatever you conclude about your workflow, conclude it from something recorded.

Measure things that do not depend on recall. Timestamps, not end-of-week reconstruction. The gap is not lying; it is perception, and perception does not improve because you know about the gap.

Expect the distribution to matter more than the average. A workflow that is dramatically faster on some tasks and slower on others averages out to something meaningless, and the widened spread is why estimating got harder. Averages hide the only information you can act on.

The reason this site exists

If perceived speed were reliable, none of this would be worth writing about. You would notice, adjust, and move on.

The finding is that it is not reliable, and that the error is large, consistent in direction, and survives being experienced firsthand. Which means the only way to know what your work now costs is to measure it — and most small teams have never needed to before, because the estimate and the feeling used to agree closely enough.

They no longer do.

Sources: METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," July 2025; METR, experiment design update, February 2026. Both are the research organisation's own publications and are not vendor-funded. Checked August 9, 2026.

The short version