Cognitive Debt: The Hidden Cost of Shipping AI-Generated Code You Don't Understand

September 7, 2026 AI Engineering 14 min read

#AI#Cognitive Debt#Technical Debt#Agentic AI#Software Engineering#Claude Code#Engineering Management#Developer Experience

For twenty years the industry has had a name for the price of going fast: technical debt. Rushed design choices pile up in the codebase, and one day every change costs twice what it should. We built linters, static analyzers, dependency scanners, and refactoring sprints to pay it down. The debt lived in the code, so we attacked the code.

Margaret-Anne Storey, Professor of Computer Science at the University of Victoria and one of the most cited researchers on developer experience and productivity, argues that generative and agentic AI have quietly moved the problem somewhere our tools cannot see. In her February 2026 post, How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt, she makes the case that the debt now accumulates in developers' minds rather than in the repository. That framing matches what I see every week running AI-first teams, so this post walks through her argument in detail, adds the context around where the term came from, and then gets practical about what it means for teams using Claude Code, Cursor, and similar agents in production.

Technical debt versus cognitive debt

Storey defines technical debt the conventional way: the accumulation of design or implementation choices that later make software harder and more costly to understand, modify, or extend. The definition nods at human understanding, but the framing puts the problem inside the artifact. Debt is something the code has. You can point at it, grep for it, and assign a ticket to it.

Cognitive debt is different in kind. In her words, it is the debt compounded from going fast that "lives in the brains of the developers and affects their lived experiences and abilities to go fast or to make changes." The critical point is that an AI agent can produce code that is clean, idiomatic, well tested, and fully functional, and the team can still be deeply in debt. The code is fine. Nobody knows why it is shaped the way it is, what invariants it depends on, or which parts are safe to touch.

Technical debt lives in the code; cognitive debt lives in developers' minds.

Storey grounds the idea in Peter Naur's 1985 essay Programming as Theory Building. Naur argued that a program is not really the source text. The program is the theory of the problem and its solution that lives in the heads of the people who built it. The text is a lossy artifact of that theory. Hand someone the text without the theory and they can keep it running for a while, but they cannot extend it coherently, because they do not know which changes preserve the design and which quietly break it. Naur was describing what happens when a team is replaced by a new team. Agentic AI produces the same situation continuously, inside a team that never changed.

Agentic AI is a machine for producing text without producing theory. That is the whole issue in one sentence.

Where the term came from

Storey did not coin "cognitive debt" from nothing. The phrase started circulating in mid 2025 after the MIT Media Lab's Your Brain on ChatGPT study, which used EEG to compare people writing essays with and without an LLM and reported weaker neural engagement and poorer recall among the LLM-assisted group. The researchers described the effect as accumulating cognitive debt: outsourcing the thinking felt free in the moment and cost something later. The study was small and the methodology drew criticism, but the phrase stuck because it named a feeling a lot of people already had.

Storey's contribution is to move the idea from the individual to the team, and from essays to software systems. The debt is not just that one developer thought less hard. It is that the collective theory of the system, the thing Naur said was the program, fragments and thins out while the system itself keeps growing. Simon Willison picked the post up within a week, DX's engineering newsletter ran a piece calling it the hidden risk in AI-driven development, and an arXiv paper in March 2026 extended the framing to "intent debt." Storey is presenting further work at the ICSE Technical Debt conference in 2026. In under a year the term went from a neuroscience preprint to a software engineering research agenda.

Why AI makes this worse, not just faster

Teams have always shipped code they did not fully understand. Copy-paste from Stack Overflow, inherited legacy modules, the contractor who left. What changes with agents is the ratio. When one developer can direct three agents in parallel and merge a few thousand lines a day, the volume of code entering the system outruns any human's ability to build a theory of it. Understanding used to be a byproduct of writing. You cannot write a function without at least momentarily holding its purpose in your head. Delegating the writing removes that byproduct, and nothing replaces it by default.

Storey draws an explicit parallel to Fred Brooks. The Mythical Man-Month showed that adding people to a late project makes it later, because coordination overhead grows faster than output. Her observation is that "adding more agents to a project may add more coordination overhead, invisible decisions, and thus cognitive load." Each agent makes dozens of small design decisions per task: which data structure, which error handling strategy, whether to mutate or copy, where the retry lives. Almost none of them are surfaced, discussed, or recorded. They just land in the diff. A human colleague making the same decisions would at least mention some of them at standup.

The other reason it is worse is that it is silent. Technical debt eventually announces itself through failing builds, flaky tests, and painful merges. Cognitive debt, as Storey puts it, "tends not to announce itself through failing builds or subtle bugs after deployment, but rather shows up through a silent loss of shared theory." Your dashboards stay green while the team's ability to reason about the system decays. By the time it becomes visible, usually during an incident or a migration, the people who could have explained the design have moved on to three other things.

The warning signs

Because cognitive debt does not show up in metrics, you have to look for it in behavior. Storey lists the symptoms, and every one of them will be familiar to anyone who has led a team through a fast AI adoption:

• Hesitation to change things. Developers avoid touching a module because they fear breaking something they cannot name. The PR sits for days. The workaround gets built beside the thing instead of inside it, which is how you get three billing code paths.
• Tribal knowledge concentrates. One or two people become the only ones who can answer "why does this work like that?" Every question routes through them. If they leave, the theory leaves with them, and the agents that generated the code cannot give it back.
• The system becomes a black box. The team starts talking about the software as if it were a third party. "It does X when you send Y" replaces "we designed it to do X because of Y." Prompting the agent to explain the code becomes the primary way anyone learns about it.
• Nothing is actually broken. This is the dangerous one. Tests pass, the build is green, velocity looks great, and leadership sees no reason to slow down. The debt is invisible right up until the moment it is not.

If you want a single diagnostic, try this in your next planning meeting: pick a non-trivial feature shipped in the last month and ask someone other than its author to explain how it works and why it was built that way. If nobody can, you are carrying debt that no static analyzer will ever find.

A worked example

Here is a scenario I have watched play out, with the details changed. A four-person team adopts an agentic coding tool in Q1. By the end of Q2 their throughput has more than doubled. They ship a reconciliation service that matches payment events against a ledger, complete with retries, idempotency keys, and a 90-percent-plus test suite. Nobody wrote any of it by hand. The engineer who prompted it reviewed the plan, skimmed the diff, and merged when CI went green.

In Q3 a partner changes their event format. The fix looks trivial: parse one extra field. The engineer who owned the original work has moved to another project. The person who picks up the ticket opens the service and finds a retry strategy nobody can justify, an idempotency scheme keyed on a field that is about to change meaning, and a comment that says the nested loop is "fine for now." The tests pass because they test the code that exists, not the intent behind it. Three days of archaeology follow, most of it spent asking an agent to explain code another agent wrote. The change ships late, and the team quietly adds "do not touch reconciliation" to its list of unwritten rules.

Nothing in that story is technical debt in the classic sense. The code was tidy. It was tested. The debt was that the theory of the service never existed in any human head, and when the first real change arrived, it had to be reconstructed from scratch at the worst possible time.

Paying it down

Storey's recommendations are deliberately old-fashioned, and that is the point. The practices that build shared theory were developed long before AI, and they still work. What has changed is that they are no longer optional side effects of writing code. They have to be scheduled on purpose, because the default path now produces zero understanding per line shipped.

One human fully understands every AI-generated change

This is the structural rule Storey puts first, and it is the one I would adopt today if you adopt nothing else. Before an AI-generated change ships, at least one person on the team must be able to explain what it does, why that approach was chosen, and what it would take to modify it. Not "I skimmed the diff and the tests pass." Fully understands. Review is not the same as comprehension, and a green CI run is not the same as review.

In practice this means the person who prompted the agent owns the theory of the result. If the agent produced something you cannot explain, you are not done. Ask it to walk you through the design, challenge the choices, and either internalize the reasoning or make it change the approach to one you would have chosen yourself. The second option is underrated. Agents will happily rewrite a solution into the shape you already understand, and that shape is worth more to your team than a marginally cleverer one nobody holds.

Document the why, not the what

Agents are excellent at describing what changed. That is the cheap part, and a diff already shows it. What evaporates is intent: the constraint that forced the odd data structure, the alternative that was tried and rejected, the assumption about traffic shape. Storey's advice is to record the reasoning behind changes so that the theory survives outside any one head. Architecture decision records, a short "why" paragraph in the PR description, and comments that explain constraints rather than restate code are all cheap insurance.

There is a bonus here for AI-first teams. The same "why" documents that keep humans in the theory are exactly what the next agent needs in its context to make consistent decisions. A well-maintained CLAUDE.md or design doc is simultaneously a cognitive debt payment and a prompt.

Regular checkpoints to rebuild shared understanding

Understanding decays, so it has to be rebuilt on a schedule. Storey suggests code reviews, retrospectives, and knowledge-sharing sessions as explicit checkpoints. The framing I use with teams: every sprint, spend one hour where someone explains a subsystem to the rest of the team without an agent in the loop. If they cannot, that is the retro topic, not a personal failing. The point of the exercise is to find the gaps while they are still cheap.

Slow-down practices: pairing, refactoring, TDD

Pair programming, continuous refactoring, and test-driven development all force a human to hold the theory of the code while it is being shaped. Storey highlights them because they are understanding-building activities disguised as productivity practices. They survive the AI transition well:

• Pairing with an agent while a second human watches and questions is a legitimate form of pairing. The second human's job is to keep asking "why did it do that?"
• TDD means writing the failing test yourself before letting the agent implement it. You own the specification even if you do not own the implementation, and the spec is most of the theory.
• Refactoring AI output into the shape you would have written is how you convert generated text into held theory. It feels like waste. It is the payment.

She also invokes Kent Beck's line: make the hard change easy, then make the easy change. With agents that means investing time up front in making the codebase legible to humans, because the agent will happily work in an illegible one and leave you further behind.

Can you measure it?

Not directly, and anyone selling you a cognitive debt dashboard is selling you a proxy. But there are proxies worth watching, and they are cheap to collect:

• Bus factor per module. How many people can explain each significant subsystem? Ask, do not infer from commit history. Agent-authored commits inflate the apparent number of contributors while the real number of people who understand the code shrinks.
• Time-to-first-confident-change. When a new ticket lands on code shipped in the last quarter, how long before the assignee is willing to make a change without asking someone? Rising numbers on recently written code are a red flag, because new code should be the easiest to understand.
• Explain-back pass rate. In your checkpoint sessions, what fraction of subsystems can be explained by someone other than the original prompter? Track it like you would track test coverage.
• Agent-explains-agent ratio. How often does the team learn about its own code by asking an AI to summarize it? Some of this is fine. When it becomes the primary path, the theory has already left the building.
• Review depth. Lines of AI-generated code merged per minute of human review time. A number that keeps climbing means review has become a formality.

None of these are precise. All of them are better than the green dashboard that tells you nothing is wrong.

What this looks like on an AI-first team

I run teams that use Claude Code heavily, and I want to be direct about the tension: the entire pitch of agentic development is that a human does not have to read every line. Storey's argument is not that you should go back to hand-writing everything. It is that velocity without understanding is not sustainable, and you have to choose deliberately where understanding gets rebuilt. A few concrete rules that have held up for us:

• Plans are read by humans, code is read by humans where it matters. Require the agent to produce a written plan before implementation, and treat the plan review as the primary comprehension checkpoint. Then read the diff in full for anything touching data models, auth, money, or shared infrastructure. Skim the rest with a clear conscience.
• The prompt author owns the theory. Whoever directed the agent is responsible for being able to explain the result in review. No delegating that to "the AI wrote it."
• Every PR description answers "why this way?" One paragraph, written or at least edited by a human. Agents can draft it, but the human has to agree with it, and the reviewer should push back if it only restates the diff.
• Cap parallel agents per person. Brooks applies. Three agents running unattended is three streams of invisible decisions. Two attended agents beat five unattended ones over a quarter, because the attended ones leave theory behind.
• Explain-back sessions. Rotate who presents a recently shipped subsystem. Agents are banned from the room. The goal is not the presentation, it is discovering what nobody understands while the fix is still a conversation.
• Persist context in the repo, not in chat. Agent conversations are where intent gets discussed and then lost. Move the decisions into CLAUDE.md, ADRs, or design docs that the next agent and the next human both read.
• Treat "make it match how I would have written it" as a valid instruction. Convergence toward the team's existing idioms is worth a little cleverness. Familiar code is held code.

The bottom line

Technical debt was a useful metaphor because it made an invisible cost legible to managers. Cognitive debt does the same job for the AI era. The code your agents produce may be perfectly healthy while your team's ability to reason about it quietly collapses. The symptoms are hesitation, hero dependencies, and black-box thinking, and none of them show up on a dashboard.

The fix is not to stop using agents. It is to stop treating understanding as a free byproduct of writing code and start treating it as a deliverable with an owner. One human understands every change. The why gets written down. The team rebuilds shared theory on a schedule. The term went from a neuroscience preprint to a software engineering research agenda in under a year, which tells you how many teams recognized the problem the moment it had a name. The ones that take it seriously now will be the ones still able to move fast in two years.

Further reading

• Margaret-Anne Storey: How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt (February 9, 2026)
• Peter Naur, Programming as Theory Building (1985)
• Fred Brooks, The Mythical Man-Month (1975)
• Simon Willison's commentary on the post
• DX: Cognitive debt, the hidden risk in AI-driven software development
• From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI (arXiv, March 2026)