Six months ago, a fintech team I work with shipped an authentication service in three days. Claude generated most of it, the senior engineer who prompted it reviewed and approved, and the service passed all tests. It worked.
Last month, a different team member needed to modify the token refresh logic. She spent four days reading code that took three days to build. The code was not bad. The formatting was clean, the naming was consistent, the tests were comprehensive. She couldn’t modify it because she couldn’t explain why it was structured the way it was. The decisions were invisible, the architecture implicit, and the engineer who prompted the original generation had moved to another team without documenting the reasoning.
The service works, nobody comprehends it, and the codebase is six months old.
The debt that has no name
Traditional technical debt is code you understand but chose to build poorly. You took the shortcut deliberately, you know where it is, and you know what fixing it costs. Comprehension debt is different. It accumulates not in the code but in the organization: in the gap between what a codebase does and what any living team member can explain about why it does it that way.
When AI generates code, the output often looks excellent at the function level. Clean formatting, consistent naming, good structure. A reviewer glancing at an individual method would conclude it is solid work. But the reviewer cannot see what the AI agent considered and rejected, cannot see the architectural alternatives that were implicitly eliminated, cannot trace the chain of reasoning that produced this specific structure over another equally valid one.
Nothing about the code changed between the day it shipped and the day someone needed to modify it. What changed was the team’s relationship to it: the engineer who held the mental model left, the context that existed in someone’s head disappeared, and no artifact preserved it. The debt lives in shared organizational knowledge, not in the codebase itself, and that makes it fundamentally different from technical debt.
Stack Overflow’s 2026 developer survey found that 76 percent of developers using AI coding tools reported generating code they did not fully understand at least some of the time. Not beginners. Experienced developers. Anthropic’s own research (February 2026) showed AI-assisted engineers scored 17 percent lower on post-task comprehension quizzes, with the largest gap in debugging skill.
The generation speed creates an accumulation problem. Every sprint that ships AI-generated code without explicit comprehension checkpoints adds to a codebase where the ratio of “code that exists” to “code someone can explain” drifts further apart. GitClear’s data shows code churn doubled and code cloning quadrupled since AI coding tools became widespread. Carnegie Mellon found complexity rose 25 percent in repos that adopted Cursor, despite velocity gains. The velocity is real. The comprehension gap is also real, and it compounds.
The Triple Debt Model
By May, the pattern had shown up in three separate engagements, and I needed a name for it. I started calling it comprehension debt: code that works but exists outside anyone’s mental model. Shortly afterward, Margaret-Anne Storey and collaborators at the University of Victoria published a framework in ACM Queue that gave academic structure to what practitioners had been discovering empirically.
Her Triple Debt Model argues that technical debt alone is insufficient for reasoning about software health in the AI era. The framework I was building from observation, she was building from research.
The two describe closely related problems at different levels: cognitive debt is the organizational phenomenon; comprehension debt is how practitioners experience it in day-to-day software delivery.
Three debts interact:
Technical debt lives in the code. Architecture shortcuts, code quality compromises, deferred maintenance. This is the debt we know. We have tooling to measure it, processes to address it, and a shared vocabulary for discussing it.
Cognitive debt lives in people. It is the erosion of shared understanding across a team where no one can confidently explain how a system works or predict the impact of a change. Before AI, cognitive debt accumulated slowly, usually when key engineers left or documentation rotted. AI accelerated it dramatically because code now enters the codebase without anyone building the mental model that writing it from scratch would have created.
Intent debt lives in externalized artifacts: the missing specifications, decision records, constraints, and rationale that explain what the system is for and guide how it should evolve. When a developer writes code manually, intent is partially embedded in the commit history, the PR discussions, the design documents. When AI generates code from a prompt, the prompt itself is the only record of intent, and prompts are usually ephemeral.
Storey’s central thesis is that AI accelerates accumulation of all three, and that each debt amplifies the others. Technical debt makes cognitive debt worse because poorly structured code is harder to understand. Cognitive debt makes intent debt worse because teams that don’t understand a system can’t articulate what it should do next. Intent debt makes technical debt worse because without clear specifications, AI generates code that is locally correct but globally incoherent.
The contributors list reads like a who’s who of software engineering thought: Kent Beck, Martin Fowler, Adam Tornhill, Russell Miles, Marian Petre, Mary Shaw, Dave Thomas. The convergence of those voices on a single model suggests the industry recognizes the problem even if it doesn’t yet have the solution.
What this maps to in practice
Existing practices already address parts of the problem. The Triple Debt Model maps cleanly to what teams are already doing, and where the gap remains:
Intent debt has emerging solutions. Intent-first engineering, where you make intent a deliverable before AI generates code, turns the specification into the input, not the afterthought. Mob Elaboration (a structured practice for this) is one version. Architecture Decision Records preserve the reasoning. Enterprise Guardrails Specifications embed constraints into the generation context. These are not theoretical: teams that articulate intent first generate code that other humans can modify later, because the “why” is explicit.
Technical debt has established tooling. Brownfield pre-phases that restructure codebases for AI readability (Code Elevation is one approach) specifically address systems where AI can’t operate effectively because the existing structure is too ambiguous. Tornhill’s work on code health and the broader refactoring literature covers this ground.
Cognitive debt has no equivalent ritual. And that is the unresolved problem.
Architecture reviews help, ADRs help, structured documentation helps. But none of these is a cognitive debt ritual the way Mob Elaboration is an intent debt ritual. We don’t have a repeatable, team-level practice that rebuilds comprehension after AI generates code at scale. Storey proposes “Cognitive Tours and Waypoints” as a direction, but it is upstream and untested.
The speed asymmetry problem
A team that ships AI-generated code for six months without a comprehension practice accumulates cognitive debt that would have taken three years to accumulate under manual development. Two hundred economists, sixteen Nobel Laureates, and researchers from every major AI lab signed a statement last week arguing that AI compresses decades of institutional adaptation into years. They were talking about economies, but the same compression applies at the codebase level. The debt is the same kind, nobody understands how the system works, but the timeline collapsed. The rescue cost did not collapse with it.
The fintech team I opened with is now spending four engineering-months on what they call a “comprehension sprint”: reading their own six-month-old code, writing the documentation that should have existed, recording the architectural decisions that were never made explicitly. Four months of remediation for six months of generation. And their codebase is small.
What we don’t yet know
That remediation cost is the known quantity. What remains unknown is whether the debt can be prevented at scale, or only managed after the fact.
I do not have a tidy framework for rescuing a codebase where cognitive debt has already accumulated at AI speed. The honest answer is that nobody does. The Triple Debt Model names the problem precisely, but it does not solve it.
What we know works for prevention: articulate intent before generation, constrain scope with explicit architecture decisions, and require that the person who prompted the code can explain it to someone who didn’t. These are methodology decisions, not tooling decisions, and they work because they create comprehension as a byproduct of the structured process.
What we don’t know is how to retrofit comprehension onto a codebase that was built without it. Code Elevation addresses technical debt in brownfield systems, but cognitive debt remediation is a different problem entirely because the knowledge doesn’t exist anywhere. You can’t extract understanding from code that was generated without it.
We spent decades learning how to manage technical debt. AI may force us to learn how to manage comprehension debt in a fraction of that time. That cognitive debt ritual, the repeatable practice that rebuilds shared understanding after AI generates code at scale, is what I am working toward. I don’t have it yet. But naming the problem precisely is the first step toward solving it.
Ricardo
