Why using AI feels faster when it isn't
METR’s randomised controlled trial found that experienced developers took 19% longer with AI. The same developers believed they had been 20% faster. A 39-point gap.
Where does that gap come from? Watch three clocks at once.
Why using AI *feels* faster
Two developers run the same 12 tasks side by side. Only the one on the right uses AI. Watch all three clocks.
Far right: to feel "20% faster than without AI" at the current δ, you would have to believe that writing it yourself would have taken 1.00× as long. The higher δ goes, the bigger this number gets — meaning the more honestly you count waiting time, the more you have to inflate the counterfactual before it feels faster
What is happening
The perceived clock does not count waiting
While the AI generates for two minutes, the developer is looking at something else — Slack, or the next piece of design. That time does not register as “time I spent on the task,” so the perceived clock stays still while the real one runs.
That is the δ slider. Set it to 0% and waiting time is not counted at all.
The perceived clock does not count discarded retries either
A cycle where the AI’s output was unusable and thrown away tends to become a non-event. People judge by the code that survived — “the AI wrote this for me” — so the failures leading up to it fall out of the ledger.
Raise q, the retry rate. The measured clock stretches; the perceived clock barely moves.
And the review factor ρ decides whether it is faster at all
AI drives the time spent writing close to zero. In exchange, time spent reading and correcting goes up. That is ρ.
The better you know the codebase, the higher ρ climbs, because bringing the output up to your own standard costs more. It is no accident that METR’s subjects were experienced developers working on their own repositories.
Conclusion: it is not an illusion — the two clocks measure different things
The perceived clock is not lying. It is measuring something else.
- Measured clock: counts waiting and retries, all of it
- Perceived clock: counts only the time you were actively moving your hands
AI reduces hands-on time and increases waiting and correcting time. So it feels faster and measures slower. Both are true at once.
There is a practical consequence. Where ρ is low — code you do not know well, throwaway scripts, routine work — AI genuinely is faster. Where ρ is high — the code you know best — it is slowest. Move the slider and you can see exactly where the line falls.
Facts and sources
The study
- METR randomised controlled trial (16 experienced open-source developers, 246 tasks) METR blog / arXiv:2507.09089 / data and code
- Their later revision of the experimental design: Changing our Developer Productivity Experiment Design
Assumptions this model makes (not facts)
- Time to write a prompt: 4 minutes. Time waiting for generation: 2 minutes
- Task durations are log-normal with a median of 120 minutes
- ρ (review factor), q (retry rate) and δ (share of waiting time that is perceived) are all adjustable
METR reports only the outcome — 19% slower, perceived as 20% faster. The three parameters above were introduced by this model and do not appear in the paper.