The Productivity Mirage

“It is not enough to be industrious; so are the ants. What are you industrious about?” — Henry David Thoreau

You close an AI session feeling fast. Big diff, green tests, a dozen things done that would have swallowed the afternoon. Then a quieter question turns up: did any of it stick? A week from now, are you further along, or did you just move more?

Moving and getting further are not the same thing, and AI has pried them apart.

Two arguments matter here. One is the 2025 fight over whether AI makes engineers faster. The other is decades of learning theory about what a tool does to the person using it. Together they answer a question neither settles alone: of everything the AI will take off your hands, what should you let it take?

BLUF: Bottom line up front

• Don’t trust the feeling of a fast session. It tracks fluency, not distance covered. That feeling is the tool’s main product.
• Triage what you hand over. Freeze pure friction: boilerplate, config trivia. Guard the difficulty that builds skill: the design you’re working out, the bug you’re reasoning through.
• Gate on one question: do I want to still be able to do this without the tool a year from now? Yes, keep the rep or scaffold it. No, automate and freeze — but know which kind of no you mean.
• Whatever you freeze, make the AI try to kill it first. Not “pressure-test this”, which just gets you a nod. Say “argue this is wrong, or already known”, and keep it only if the attack fails.
• Test residue with residue. Every so often, do a protected thing without the tool and find out whether you still can.

The output is real. That’s the trap.

The code runs, the tests pass, the task is done. This isn’t slop in a nice coat, and calling it that loses the argument with anyone who has actually used the tools.

That’s what makes it a mirage, not a lie. A mirage isn’t a false thing. It’s a real thing in the wrong place. Water, just over there. The throughput is real. It just isn’t always where progress is.

Two ledgers

The split is older than the panic. In 1991, Salomon, Perkins and Globerson cut the gains from a thinking tool in two: the effects with the tool, meaning how well you perform while it’s in your hands, and the effects of it, the “cognitive residue” left behind once you set it down.

Two ledgers, and they don’t move together. Your output with the tool in hand has never been higher. The residue is the open question. Felt speed reads the first ledger while you hope it tells you something about the second.

The feeling can’t tell them apart

In 2025, METR ran a randomized controlled trial: sixteen experienced open-source developers, working real issues in their own repositories, with and without early-2025 AI tools. They finished 19% slower with the AI, and believed they had been about 20% faster (arXiv 2507.09089).

Take the number with a lot of salt. Sixteen people, their own repos, tools already a generation stale, and some of them did speed up. The 19% is fragile; don’t build on it.

Build on what survives all of that: the direction. Experienced developers, working on code they knew, got the sign wrong. Whether the AI slowed them down is arguable. Whether their sense of speed could have told them is not. The feeling was real. It just wasn’t a measurement.

Two reasons the feeling misleads you

Two different things are getting mashed together.

The first is a lag. Solow, 1987: you can see the computer age everywhere but in the productivity statistics. Brynjolfsson, Rock and Syverson later gave the lag a shape, the Productivity J-Curve (NBER 25148). It’s a macroeconomic pattern, but the shape carries down. A new tool pays off only after the unglamorous work of restructuring around it. The numbers dip before they climb. So this week’s output is a poor read on whether you’re compounding. Not because the number lies, but because it’s early.

The second is worse, because it isn’t a lag. It’s a miscalibration.

Robert Bjork’s work on desirable difficulties found that the conditions making learning feel slow and effortful are often the ones that make it stick. Fluency, the smooth feeling, is an illusion of competence, not competence.

Now hold that against what an AI does. It strips the friction, and the felt difficulty with it. Read charitably, that smoothness is the tool optimised toward responses people rate highly, and people rate fluent answers highly. Fluent was never the same as right.

So the smoother a session feels, the more likely it took some skill-forming difficulty with it. METR caught that fluency fooling the felt sense of speed. The same fluency fools the felt sense of learning.

The good feeling isn’t a side effect. It’s the tool doing its job, running straight down the effects-with ledger while saying nothing about the effects of.

The part the advice gets wrong

This is where the usual fix turns on itself. Mine included.

The standard advice: capture what you learn each session and freeze it into something reusable, a rule or a check or a skill, so it fires on its own next time.

But freezing a thing means automating it. Automating it strips the difficulty. And without the difficulty, no residue forms.

A third asset shows up here. Salomon’s two were both about you: your throughput now, your residue later. Freezing adds an artifact. A saved rule is real, durable capability living in the codebase or the toolchain, and it compounds whether or not you do. That’s a real gain. The trap is reading a fat artifact, or a fast session, as if it were your residue. The standard advice compounds the artifact and goes quiet on the person.

So the question isn’t “freeze or don’t.” It’s whether freezing this also spends your residue.

Not all difficulty is the same

Learning theory drew this line decades ago. Borrow Sweller’s cognitive load theory and separate the load that teaches you nothing from the load that forms skill. Boilerplate, config trivia, the argument order of an API you’ll never hold in your head — that was never building residue. Automate it. The artifact gains and you lose almost nothing. The line isn’t fixed, though: what counts as extraneous depends on you and your goal, not on the task alone.

The rest is the difficulty that forms skill. Working out the design. Reasoning through why the bug happens. Holding the problem in your head until it cracks. Offload that and the artifact still compounds, but your residue doesn’t. This is Bainbridge’s Ironies of Automation (1983): automate the operator’s work and you erode the skill they’ll need on the day the automation is wrong, which is the day it matters most.

The gate

An obvious objection: telling friction from skill-forming difficulty takes judgment, and the argument so far says your judgment is unreliable. But the unreliable part was one specific thing: how fast you felt, in the moment. The gate runs on a different call, cheaper and forward-looking. Do I want to still be able to do this without the tool a year from now?

That question doesn’t depend on how fast you felt. If yes, the difficulty is worth keeping, so keep the rep or scaffold it instead of handing it over whole — have the AI ask you the questions, or fade its help. If no, automate and freeze, but be honest about which “no” it is. Sometimes it’s “pure friction, it never taught me anything.” Sometimes it’s “real skill, and I’m choosing not to carry it.” You can’t keep everything. Just make it a decision instead of a default. It isn’t a clean binary and the label isn’t permanent, because the same task can cross the line as your goals shift.

Freezing has its own failure mode. “Pressure-test this” is a leading question, and a fluency-maximiser validates whatever you hand it. The sharper you are, the better you rationalise the agreement. Flip it round: make it argue the note is wrong or already known, and return a verdict — keep, merge, or drop. It earns “keep” only when its best attempt to break it fails. A second model helps a little, since it’s unlikely to share the first one’s exact blind spot, but what does the work is making it argue against you, not the second model.

The loop, then, is triage, not capture. Freeze the friction hard. Protect the skill-forming difficulty by keeping the rep or scaffolding it. And whatever you do freeze, make the AI try to kill it first.

What replaces the feeling

When I ran that test on myself, the result was milder than I feared. Writing up a system I’d built, I couldn’t reconstruct the symptoms and setup behind one of my own decisions. The story I first told myself was the wrong one, and it took digging up the raw material before the real one surfaced. But once the context was back, so was the call, immediately. What had drained wasn’t the ability. It was the context. Restore the context and the skill is still there, sometimes sharper. And the times I’ve gone back to a “why did I do this?” decision, I’ve mostly landed on the same fix, or a better one.

You can’t run this on the feeling; that was the whole problem. Counting your frozen rules doesn’t rescue it either: a longer list just swaps one bad measure for another. The honest test of residue is residue. Every so often, do a protected thing without the tool and find out whether you still can. It won’t be clean: you won’t fully tell rust from a skill you never had. So treat it as a smell test, not a metric. But a smell test you’ll actually run beats a measurement you won’t, and it points straight at the ledger that was quietly emptying while the others looked fine.

The word productivity was always the tell. It measures what you produce and never what you become. The mirage was never that the work was fake. It’s that motion this real can feel exactly like progress.

---

How sure I am: The learning-theory and productivity research is prior art, cited below. The friction/desirable-difficulty gate, the three-asset framing, and testing residue with residue are my synthesis and a wager, not a measured result. The “run it on myself” passage is exactly that: one person, no control.

Sources

• Salomon, Perkins & Globerson, Partners in Cognition (1991) — the effects with a tool versus the effects of it (“cognitive residue”); the two-ledgers spine of the piece.
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025), arXiv:2507.09089 — 16 experienced developers came out 19% slower yet believed they were ~20% faster; the felt-speed calibration gap.
• Robert Solow (1987) — “you can see the computer age everywhere but in the productivity statistics”; the lag is old news.
• Brynjolfsson, Rock & Syverson, The Productivity J-Curve (2018), NBER 25148 — a real tool’s payoff shows up late, so this week’s output is a poor read on whether you’re compounding.
• Robert Bjork — desirable difficulties — the conditions that make learning feel slow and effortful often make it stick; fluency is an illusion of competence, not competence.
• John Sweller — cognitive load theory — extraneous load, safe to automate, versus germane load, the skill-forming difficulty to protect; the friction/difficulty gate.
• Lisanne Bainbridge, Ironies of Automation (1983) — automating the operator’s work erodes the skill they need on the day the automation is wrong.
• Baldur Bjarnason, The LLMentalist Effect (2023), softwarecrisis.dev — subjective validation (the Forer effect) applied to LLMs: a fluency-maximiser validates whatever you hand it, and the sharper you are the better you rationalise the agreement. Mechanism only; the essay’s “avoid LLMs entirely” maximalism is not adopted.