Cognitive Debt: The Bill Nobody Is Tracking

In 1997, an American Airlines captain named Warren VanderBurgh gave a lecture to fellow pilots about a habit he'd started noticing in the cockpit. He called it "children of the magenta line" — after the magenta-colored course line that flight computers draw across the display. His pilots weren't flying anymore. They were managing the line.

The skill didn't vanish in one flight. It thinned out slowly, until the automation was the only thing standing between competence and confusion. In 2009, when Air France 447's airspeed sensors iced over and the autopilot handed a perfectly good airliner back to a startled crew, that thinning turned fatal.

Software engineering has its own magenta line now. It has a name, too: cognitive debt.

What it actually is

The term has two origins, and they sharpen different halves of the problem.

MIT Media Lab researchers got there first, in a 2025 study that put people in EEG caps and had them write essays — some with ChatGPT, some with a search engine, some with nothing at all. The brain-only group showed the strongest, most distributed neural connectivity. The LLM group showed the weakest. The uncomfortable part came later: when LLM users were asked to write unaided, the under-engagement didn't reset. They stayed disconnected from work they had nominally written, and many couldn't accurately quote their own essays back.

Software engineering researcher Margaret-Anne Storey picked up the same term for a team-level problem. She defines it as "the accumulated gap between a system's evolving structure and a team's shared understanding of how and why that system works and can be changed over time."

Her one-line version is the part worth remembering:

Technical debt lives in the code. Cognitive debt lives in people.

That distinction matters more than it first sounds. Technical debt is visible and fixable — it shows up as smells, as failing tests, as the file everyone complains about, and you pay it down by refactoring. Cognitive debt shows up nowhere. The codebase can be clean, well-tested, and green across every dashboard while the people responsible for it quietly lose the ability to explain why it works. You cannot refactor your way out of it, because the thing that's missing was never written down.

The evidence stopped being anecdotal

For a while this was a plausible-sounding worry told in anecdotes. That changed in January 2026, when Anthropic published a controlled study that anyone shipping code with AI assistance should read.

Fifty-two engineers were asked to learn Trio, a Python async library none of them knew. Half had AI assistance, half didn't. Everyone then sat a comprehension quiz.

The AI group averaged 50%. The hand-coding group averaged 67% — nearly two letter grades higher, statistically significant, with debugging questions showing the widest gap of all.

The AI group finished about two minutes faster. That difference didn't reach significance. So: no real speed win, and a measurable comprehension loss.

But the headline number is the least interesting thing in that paper. Not everyone in the AI group did badly. The researchers sorted participants into six distinct usage patterns. Three of them — wholesale delegation, progressive reliance, and iterative debugging without understanding — averaged under 40%. The other three — generating code then asking follow-up questions, requesting explanations alongside the code, and asking purely conceptual questions while fixing errors independently — averaged 65% or higher, holding their own against the group that had no AI at all.

Same tool. Same task. A spread of more than twenty-five points, explained entirely by how people used it.

The researchers' own summary of why: cognitive effort — "and even getting painfully stuck" — seems to be load-bearing for building mastery. The AI removed the productive struggle, and the struggle was the learning.

That reframes the whole conversation. Cognitive debt isn't a tax on using AI. It's a tax on using AI passively.

The third kind of debt

Storey extended this in a March 2026 paper, From Technical Debt to Cognitive and Intent Debt, which proposes a Triple Debt Model: technical debt in the code, cognitive debt in the people, and a third category she calls intent debt — "the absence or erosion of explicit rationale, goals, and constraints that guide how humans and agents evolve the system."

Intent debt is the one AI workflows generate almost by construction. The reasoning behind a decision — why this approach, what was ruled out, which constraint forced the awkward bit — lives in a prompt, in a chat window, in someone's short-term memory. Then the session closes. The code survives; the rationale doesn't. Six months later the code is still running and nobody can tell you why it looks like that.

The split is useful because each debt needs a different repayment. You refactor technical debt. You rebuild cognitive debt through actual engagement. Intent debt you can only prevent, by writing the reasoning down while you still have it.

What people are converging on

I don't have a framework for this, and I'd be suspicious of anyone selling one this early. But reading across Storey's work, the Anthropic study, and practitioner write-ups from VirtusLab and DX, the same handful of practices keep surfacing independently — which is usually a sign they're worth something.

Interrogate, don't delegate. The highest-leverage habit in the Anthropic data costs almost nothing: ask why, not just what. "Explain the approach before you write it." "Why this structure over the alternative?" That single behavioural difference is most of the gap between the sub-40% patterns and the 65%+ ones.

Write the intent down while it's still in your head. A one-line commit message or comment explaining why is cheap at the moment of generation and nearly impossible to reconstruct later. This is the only real defence against intent debt.

Make "can you explain this?" a review question. Most review asks whether the code works. Add whether someone other than the author can account for it. VirtusLab's suggestion of deliberately rotating reviewers — so the person reviewing isn't the person (or session) that generated it — forces an independent mental model to actually form.

Treat unexplainable code as a signal, like a flaky test. DX and Storey both point at the same symptoms, none of which appear on a velocity dashboard: hesitation to touch certain files, defaulting to "ask whoever wrote it," debugging friction, longer onboarding, review burden climbing while output climbs faster.

Track retained understanding, not just what shipped. Every team measures throughput. Almost nobody measures whether the team could rebuild what it just shipped. That asymmetry is the whole mechanism — you optimise the number that goes up and never see the one going down.

None of this is anti-AI. The highest scorers in the Anthropic study used AI heavily. They just used it as something to think with rather than something to think instead of.

Where this goes next

Here's the part I keep chewing on. Most engineering organisations are structurally built to reward the thing that produces cognitive debt — shipping velocity — and structurally blind to the thing that prevents it. There's no dashboard for "can this team still explain its own system." So the debt accumulates underneath teams that look, by every number anyone is watching, like they're having their best quarter ever.

The bill arrives the way it always does with debt: not gradually, but all at once, on the night something breaks and the channel goes quiet.

I don't think anyone has the clean answer yet, and I'd rather argue about it in the open than pretend the list above is one. So — where is this actually showing up for you? My guess is onboarding and incident response feel it first, long before anyone names it. But I'd rather hear the specific, messy version from people living it.