At a CTO Craft dinner in Toronto last week, a roomful of engineering leaders landed on a phrase that has been doing the rounds since: cognitive debt is the new technical debt. The line, reported by ShiftMag's Ivan Brezak Brkan, came from one participant describing a pattern the whole table recognised. Teams are shipping features at a pace that was impossible two years ago, and inheriting a maintenance load to match. Code that was already hard to understand is harder, because the people writing it are not being careful, they are being fast. Internal tools meant to last a fortnight are now load-bearing because someone shipped them with three prompts.

The phrase is not original to that dinner, and that is worth knowing before you reach for it.

The pitch, stated fairly

The pitch is tidy. Technical debt is the cost you defer when you write code quickly and pay it back later in refactoring. Cognitive debt is the same trade applied to understanding: lean on the model to think for you now, lose the capacity to think later. The phrase got its scientific veneer last June from an MIT Media Lab preprint, "Your Brain on ChatGPT", which wired up 54 people writing essays under EEG caps and found that the group using a chatbot showed the weakest brain connectivity and produced the most homogeneous prose. The authors called it the accumulation of cognitive debt. The headline wrote itself: AI is making us dumber.

What I can verify is narrower than that headline, and the study's own authors said so. The paper is a preprint, not peer reviewed. The samples are small, eighteen per group in the main sessions and nine per group in the session everyone quotes. It measured essay writing, not engineering. A formal Comment has since catalogued reporting inconsistencies and reproducibility gaps. And the authors asked journalists outright not to say AI "makes us dumber", because they never used that vocabulary. So the science under the buzzword is thin, and the buzzword itself came from one tired CTO over dinner. If you wanted to wave the whole thing away as consultancy folklore, you would have the receipts.

The debt is real. The framing is wrong.

Here is where I part company with both the boosters and the debunkers. The brain-scan framing is a distraction, and it is doing the concept a disservice. Cognitive debt, as the CTOs actually described it, is not a story about individual neurons going slack. It is a story about organisations losing the thread of their own systems. That problem is decades old. Peter Naur described it in 1985.

Naur's "Programming as Theory Building" argued that the real artifact of software work is the theory in the programmers' heads, not the source code itself: why the system is shaped the way it is, which trade-offs were made, what breaks if you pull a given thread. The code is a lossy representation of that theory. Lose the people who hold it and you have a program nobody truly understands, even though every line sits right there in the repo. Naur's term for a team in that state was that its theory had died. Forty years on, that is a precise description of what the Toronto room was worried about.

What AI changes is the speed, and one consequence is worth sitting with. Technical debt and cognitive debt can now move in opposite directions. A model can hand you cleaner code than you would have written, well structured, conventionally named, lint-clean, low on every technical-debt metric you track. And you can hold no theory of it at all, because you did not build it and you skimmed the diff. The codebase looks healthier on every dashboard you own while the understanding behind it quietly goes to zero. There is no linter for the second thing. That is why it reads as a new problem when it is an old one, freshly unbundled from the messy code it used to travel with.

The objection a senior engineer would raise

The strongest counter is the one experienced engineers reach for first: abstraction always meant not understanding the layer below. You do not understand your compiler, your kernel, the silicon under it, and you ship perfectly good software anyway. Why is generated code any different?

Because a compiler is a contract. It is specified, deterministic and stable; the same input yields the same output, and you can build a reliable theory on top of an abstraction that behaves itself. Generated code that lands in your own repository has none of those properties. It is not reproducible, it carries no interface boundary, and it sits there indistinguishable from code a human reasoned about line by line. You are not abstracting over it. You inherit it, unread, as though it were your own work. The compiler analogy fails at exactly the point that matters.

The fairer challenge comes from the people who push these tools hardest. Sean Goedecke, an engineer at GitHub, argues that working with AI agents is theory building done well. He spins off parallel agents, rejects roughly 80% of what they produce on sight because it does not match his mental model, reviews the plausible remainder closely, and lets maybe a tenth through. On that account the model accelerates implementation while the human keeps the theory. He is right, and he is the existence proof that cognitive debt is optional.

But look at what his discipline costs: a detailed mental model maintained by hand, and the judgement to throw away four-fifths of the output. That is precisely the enablement the Toronto room said adoption had outrun. Goedecke demonstrates the debt can be refused. He does not demonstrate that anyone at scale is refusing it. The survey one CTO described found 90% of engineers wanting to use AI and the organisation scrambling to answer what that meant for performance reviews and promotion. Enthusiasm arrived years before the working practices that make it safe.

It shows up on the org chart, not the brain scan

The dinner's two sharpest moments were both organisational. The first was a structural fix: a "technical health team", engineers whose job is to delete and refactor, treated as equal in worth to the ones shipping features. That is a company trying to put understanding back on the balance sheet, and the participants were honest that selling it to a business wired for velocity is the hard part. The second was bleaker. One leader said her company has a single point of failure on Anthropic, and that the marketing and finance staff now building on Claude have no idea what sits underneath. If inference goes down, she said, they will call engineering, and engineering will not understand the generated systems either.

That is cognitive debt as a company-wide liability rather than a personal failing, and it stays invisible until the day a vendor hiccups. The brain-scan version asks whether your developers can still think. The version that will actually cost money asks whether anyone in the building still holds the theory of the systems you depend on, and whether you have any way of knowing before it is tested.

The bet

So here is the bet. The number worth watching over the next year is not how much of a company's code AI writes; every vendor will quote that one to you. The real signal is whether organisations start funding theory maintenance as a named line item: refactor-and-delete teams, explicit ownership of the why and not just the what, documentation that someone is actually paid to keep current. Firms that do are treating cognitive debt as real. Firms that do not will learn about it the way you always learn about debt, all at once and at the worst possible time: an outage nobody on the roster can trace, or a model provider going dark and stranding the people who built on it without once looking underneath.

If we reach mid-2027 and the AI-heavy shops are shipping cleanly with no understanding crisis, no new health-team roles and no vendor-outage horror stories, then cognitive debt was a dinner-party anxiety dressed in an EEG cap, and I will say so. I do not think that is the way to bet. The theory still has to live somewhere, and right now fewer people are volunteerin