What is cognitive debt?
Engineering culture and software practice
Cognitive debt is the understanding a person or team does not build because a tool did the thinking for them, which has to be repaid later when something goes wrong and nobody knows how the thing works. Two senses circulate: a specific one from a June 2025 MIT Media Lab preprint by Kosmyna and colleagues that measured brain activity during AI-assisted essay writing, and a looser organisational sense by analogy with technical debt. This article uses the organisational sense and flags the study's limits.
What this means
When a tool does a piece of thinking for you, you get the result without the understanding that normally comes with doing it yourself. Most of the time that is a fine trade. Nobody wants to grind long division by hand. Cognitive debt names the case where the understanding you skipped turns out to matter, and you have to pay it back, usually at a bad moment, when the tool's output fails and you cannot tell why.
The phrase has two senses in circulation, and they are not the same claim. The narrow one comes from a neuroscience preprint that measured what happened in people's brains and memories when they wrote essays with an AI assistant. The broader one is organisational and older in spirit: it borrows the shape of technical debt to describe understanding a team never formed. This article uses the organisational sense, because that is the one a leader can act on, while being honest about what the study did and did not show.
The reason it has a name is that the cost is invisible until it lands. A team can ship faster for months and only discover, when a system breaks or a key person leaves, that no one actually understands how the thing works.
Why it matters
Cognitive debt is the quiet risk inside a productivity story. A team adopts AI tools, output goes up, everyone is pleased, and the understanding that used to be a by-product of doing the work simply does not accumulate. The bill arrives later: an incident nobody can diagnose, a reviewer who approved code they did not understand, a new joiner onboarding into a system largely written by a tool with no human who can explain it.
It is not confined to engineering. The same effect shows up in analysis, drafting, research and advice, wherever a person can accept fluent output without engaging with the reasoning behind it. In each case the immediate work looks done while the capability to check, defend or change it never forms.
For a leader, the practical stakes are about resilience and accountability. If your organisation cannot explain its own decisions, its own code or its own analysis, it is exposed the moment anything goes wrong or anyone leaves. The question is not whether to use the tools; it is how to keep the understanding that the organisation actually needs, and to notice which understanding is load-bearing and which can safely be delegated.
How it works
Where the term came from
The phrase entered wide use through a preprint posted to arXiv on 10 June 2025 by Nataliya Kosmyna, Eugene Hauptmann, Ye Tong Yuan, Jessica Situ, Xian-Hao Liao, Ashly Vivian Beresnitzky, Iris Braunstein and Pattie Maes of the MIT Media Lab, titled "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task". Fifty-four participants wrote essays in three groups, one using a large language model, one using a search engine and one using no tools, with electroencephalography used to measure brain activity. The paper reported that the model group showed the weakest brain connectivity and severe deficits in memory and ownership, with eighty-three per cent unable to quote from essays they had just written.
As of September 2026 the paper remains a preprint. The authors themselves state it had not been peer reviewed when posted and ask that its conclusions be treated as preliminary. A commentary posted to arXiv in January 2026 by Milos Stankovic and colleagues at the University of Vienna and Technische Universitaet Dresden praised the dataset but argued several results could be read more conservatively. So the specific study should be cited as suggestive, not settled.
The looser organisational sense predates and now runs alongside the study. It borrows the metaphor of technical debt to name understanding that was never built, and it appears in practitioner writing, including Osmani's use of the related phrase comprehension debt, and in analyst material such as the Thoughtworks Technology Radar, which in 2026 urged teams to manage cognitive debt so developers still understand the systems they build. This article uses that organisational sense.
The organisational mechanism
The mechanism is simple. Understanding is normally a by-product of doing the work: you learn a system by building it, an argument by writing it, a dataset by analysing it. When a tool does the doing, the by-product does not form. The debt accrues silently because nothing looks wrong while the tool keeps producing acceptable output. It comes due when the output is wrong, when the context changes, or when the one person who did understand moves on and it turns out the understanding lived only with them or, worse, with no one.
The counter-argument, taken seriously
The honest objection is that every tool from the compiler onward has removed some understanding, and that this is usually a gain. No modern engineer knows the machine code their program becomes, and that is fine. Abstraction is how progress works. The useful question is therefore not "does the tool remove understanding" but "does it remove understanding this organisation actually needs". Cognitive debt is only a problem where the skipped understanding is load-bearing, meaning someone will need it to check, defend, fix or change the work.
Telling load-bearing understanding from the safely delegated kind
Load-bearing understanding is the kind you will need when things go wrong or when you must justify a decision: how a payment flow handles failure, why an analysis reached its conclusion, what a contract clause commits you to. Safely delegated understanding is the routine, low-stakes, easily rebuilt kind. There is genuine evidence that the distinction matters: in an Anthropic randomised trial reported in early 2026, fifty-two mostly junior engineers learning an unfamiliar Python library scored about seventeen percentage points lower on a comprehension quiz when they used AI assistance, with the widest gap on debugging, the very skill needed to oversee AI output. That study, too, is one small experiment measuring immediate comprehension, so treat it as a signal rather than proof.
How experienced teams handle it
They build repayment into the work rather than hoping understanding turns up. They ask people to explain the system back in their own words, review some work without the tool present, and keep a written record of why decisions were made, not just what was produced. They treat deliberate practice as still necessary even when the tool is always available, drawing on the long research tradition on expertise, notably the work of Anders Ericsson, while noting that even that literature has been debated and partially challenged in replication.
Examples
A software team of eight ships features quickly for two quarters using coding agents. Then a subtle fault appears in production and no one can trace it, because no living person built or fully read the affected part. The speed was real; so was the debt, and it came due all at once during an incident.
A council department uses an assistant to draft responses to a public consultation and to summarise the replies. The summaries read well and the work goes fast. When a resident challenges a conclusion, the officer cannot explain how it was reached, because the reasoning was never theirs. The understanding needed to defend the decision was load-bearing and had not been formed.
A professional services firm lets junior analysts lean on AI to produce client models. The models look polished, but in a review the analysts cannot say why a figure moves when an input changes. The firm responds not by banning the tool but by requiring each analyst to explain the model back without it, which surfaces exactly where understanding is missing before it reaches a client.
Common misunderstandings
The first misconception is that cognitive debt is a proven neurological effect. The widely cited MIT Media Lab study is a preprint that, as of September 2026, has not been peer reviewed; it had fifty-four participants, only eighteen of whom completed the final session, in a single essay-writing setting. Its own authors call it preliminary. Treat it as suggestive, not as established science.
The second is that any use of AI creates cognitive debt. It does not. Debt only accrues where the skipped understanding is load-bearing. Delegating routine, low-stakes thinking is ordinary tool use and usually a gain, exactly as with the compiler.
The third draws the line against technical debt, the closest existing idea and the metaphor this borrows from. Cognitive debt is not technical debt. Unlike technical debt, which is deferred design cost sitting in the code itself, cognitive debt is understanding that was never formed in people. You can have clean code that no one comprehends, and messy code that a team understands well; the two debts are distinct.
The fourth is that cognitive debt is the same as the bus factor. It is not. The bus factor is about knowledge concentrated in one person who might leave. Cognitive debt is about understanding that no one built in the first place. A team can have a healthy bus factor on paper and still owe deep cognitive debt if the knowledge lives only in the tool.
The fifth is that the fix is to stop using AI. The workable remedy is to repay deliberately: explain work back, review without the tool sometimes, and record decisions, so understanding forms where it is actually needed.
Risks and boundaries
This is a recent term whose meaning is still moving, and this article was written in September 2026. The two senses, the narrow neuroscience one and the broader organisational one, are genuinely different claims, and much popular coverage blurs them. The folklore currently outruns the evidence: the headline study is an unreviewed preprint with a small sample and an artificial setting, its final and most-quoted stage involved only eighteen people, and a January 2026 commentary argues its results deserve a more cautious reading. The supporting Anthropic trial is likewise small and measures only immediate comprehension.
The term is misapplied when it is used to oppose all AI adoption, or to dress up a general worry about laziness in scientific language. It does not cover ordinary skill fade, and it is not a claim that abstraction is bad. The live debate is whether the effect is durable and general or an artefact of specific studies, and the honest position as of September 2026 is that the organisational pattern is real and familiar while the specific neurological claims remain unproven.
What to do next
First, decide which understanding is load-bearing for your organisation. Map the handful of systems, decisions and analyses where someone will genuinely need to check, defend, fix or change the work, and protect the understanding there. Everything else can be delegated with a clear conscience.
Second, make repayment a normal habit, not a punishment. Ask people to explain their work back in plain language, have some work reviewed without the tool in the room, and keep a short written record of why key decisions were made. These cost little and reveal missing understanding early.
Third, protect the learning of junior people. The evidence, thin as it is, points to the biggest risk falling on those still forming their skills. Design their use of AI so they build comprehension, for instance by asking the tool to explain rather than only to produce.
Fourth, treat speed and understanding as separate measures. A rising output number tells you nothing about whether the organisation can still explain itself. Ask explicitly whether anyone can account for the work, not just whether it shipped.
Fifth, resist both hype and panic. Do not present the preprint as settled science, and do not ban the tools. The defensible move is to keep the understanding you need while letting the tools do the rest.
FAQs
Where does the term cognitive debt come from?
It entered wide use through a June 2025 MIT Media Lab preprint by Kosmyna and colleagues on AI-assisted essay writing. A looser organisational sense, by analogy with technical debt, predates it and runs alongside.
Has the MIT study been peer reviewed?
As of September 2026, no. It remains a preprint, its authors call its conclusions preliminary, and a January 2026 commentary argued some results should be read more conservatively.
How is cognitive debt different from technical debt?
Technical debt is deferred design cost sitting in the code. Cognitive debt is understanding that was never formed in people. You can have clean code nobody understands, and messy code a team understands well.
Is it different from the bus factor?
Yes. The bus factor is knowledge concentrated in one person who might leave. Cognitive debt is understanding no one built in the first place, so it can exist even where the bus factor looks healthy.
Does using AI always create cognitive debt?
No. It only accrues where the skipped understanding is load-bearing, meaning someone will need it to check, defend, fix or change the work. Routine, low-stakes delegation is ordinary tool use.
What does repaying cognitive debt look like?
Explaining work back in your own words, reviewing some work without the tool, and recording why decisions were made, so understanding forms where the organisation actually needs it.
Is there any hard evidence it harms real work?
The evidence is early and thin. An Anthropic trial in early 2026 found AI-assisted learners scored about seventeen points lower on comprehension, but it was small and measured only immediate recall. Treat it as a signal.