Why it feels faster than it measures

The finding worth sitting with

In the METR trial, the participants were slower by about 19% and believed afterwards that they had been faster by about 20%. These were experienced engineers, working on their own repositories, who had just lived through every minute of it. The gap is roughly forty percentage points, in the direction of flattering the tool, in people with every reason and every opportunity to notice.

If they could not tell, your impression is not evidence either. That is uncomfortable and it is the point of this lesson. What follows is the mechanism, because knowing why the illusion happens is the only way to work around it.

Five mechanisms, all of them ordinary

Waiting is not remembered as work. Forty minutes of typing registers as forty minutes of effort. Forty minutes of prompt, wait, skim, reject, re-prompt registers as much less, because effort is intermittent and each cycle is short. Elapsed time is identical. Remembered exertion is not, and people estimate duration from remembered exertion.

Struggle is the thing that gets filed as cost. The memory of the afternoon lost to a stack trace is vivid and expensive. Its absence reads directly as speed. But not being stuck is not the same as being finished, and the tasks where you were never stuck may still have taken longer end to end.

Debug time is charged to the wrong account. The two hours spent on Thursday tracing a double charge does not get filed under Tuesday’s generated retry decorator. It gets filed under billing bug. Every accounting system, formal or mental, that separates production from consequences will overstate production.

The wins are memorable and the losses are boring. When it works, it works spectacularly: a 200-line module in ninety seconds. When it fails, it fails as a slow drip: a wrong assumption you argue with for twenty minutes, a subtly wrong import, an approach you abandon. Availability bias does the rest. Ask anyone for an example and you will get the spectacular win, because that is what is retrievable.

The demo is not the feature. The first 80% arrives immediately and looks like the whole thing. Completion is estimated from what is visible, and what is visible is disproportionately the easy part. This one distorts estimates as well as impressions, and it gets its own treatment later in the course.

What actually to do about it

Stop trying to feel more accurately. It does not work; that is what the trial shows.

Measure elapsed clock time on real tasks, to the right end point. Not “until the code was written”: until it was merged, green in CI, and deployed. Most of the divergence between feeling and reality lives after the code was written, so a measurement that stops there is measuring the wrong segment on purpose.

Randomise per task, not per week. If you do assisted work on Mondays and unassisted work on Fridays, you have measured Mondays. Flip a coin per task. It feels absurd and it is the whole of the method.

Follow the change for thirty days. Count anything that came back: a follow-up commit, a reverted deploy, a bug report, an incident. Speed without this is not a result.

Write your prediction down first. Before the fortnight, write what you expect and what result would change your behaviour. Comparing the prediction with the outcome is the cheapest calibration exercise available, and it is the exact thing the METR participants could not do retrospectively.

The counterpoint, stated properly

Here is where a lot of writing on this subject goes wrong. It treats the perception gap as proof that the felt benefit is fake. It is not.

Lower cognitive load has real value that a stopwatch does not capture. Fatigue is a genuine constraint on a working day, and a tool that leaves you with more attention at 4pm has produced something, even if the morning’s tasks took the same time. So has a tool that makes you willing to write the boring migration script on Friday afternoon rather than postponing it to a Monday that never comes. Work you would not otherwise have done at all does not show up as a speed-up on any task, and it can be the largest effect in practice.

The honest position is two-sided. Your impression of speed is unreliable and should not be the basis of a decision about how a team works. Your impression of strain is much more reliable, because you are the only instrument for it, and it measures something that matters.

Keep both. Distrust the first, record the second, and let the clock settle the argument about time.