From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI
Margaret-Anne Storey · pdf · 2026-07-28 Reader 🖥️
theoretical · expository/conceptual-framework paper (arXiv preprint) — Introduces a named framework (the 'triple debt model') via a mix of a single illustrative anecdote (an entrepreneurship-course team), synthesis of prior literature (Naur, Cunningham, Kruchten, Hutchins, Wegner, Kahneman, Shaw & Nave), and citations of the author's own concurrent/forthcoming empirical work (Starr & Storey 2026; Miller et al. 2026; Alakmeh et al. 2026). It is not itself an empirical study — no new data is collected or analyzed here — and the author explicitly flags three questions as unresolved ('Points for Debate') rather than argued to a conclusion, which is unusually honest epistemic hygiene for a framework-introduction paper. This is the primary source that a chain of derivative pieces already in this corpus (Osmani's 'The Intent Debt', likely Bilić Arar's 'two kinds of debt', Fowler's Fragments Feb 13, the 'five studies' extraction) cite or paraphrase without the corpus previously having ingested the original.
Structure
| Part | Role |
|---|---|
| Opening vignette | narrative hook |
| Introduction of the triple debt model + 'Hidden Cost of AI-Generated Code' | thesis statement |
| 'What is a Software System, Really?' | ontology |
| Technical Debt: The Well-Known Layer | baseline/contrast case |
| Cognitive Debt: The Invisible Layer | core definitional section |
| Intent Debt: The Forgotten Layer | core definitional section |
| Three Layers of Software System Health | synthesis |
| How AI Is Shifting the Balance | mechanism statement |
| Implications for Practice | prescription |
| Points for Debate | explicit unresolved-questions section |
| Conclusion + Acknowledgments + References | closing + provenance |
Key terms
- Triple debt model
A framework positing three interacting, independently-varying types of software debt -- technical (code), cognitive (people), intent (artifacts) -- each mapping to one of three layers a software system 'really' consists of. - Cognitive debt Cognitive Debt
A team-level, project-level property: the accumulated erosion of shared understanding (Naur's 'theory of the system') across a team over time -- not an individual's confusion, and not reducible to the state of the code. Explicitly distinguished from Kosmyna et al.'s use of the same term for measurable individual neural-engagement reduction, and from Alakmeh et al.'s 'comprehension debt' (the code-vs-understanding gap) -- Storey's usage is specifically the team-level, longitudinal dimension. - Intent debt Intent Debt
The absence or erosion of explicit, externalized rationale, goals, and constraints that guide how a system evolves -- lives in artifacts (or their absence), not in code or in people's heads. Distinguished from mere 'missing documentation': it specifically concerns whether goals/constraints/rationale are captured anywhere a human or an AI agent can consult, and is framed as the layer that is hardest to recover once lost ('intent is best captured at the moment key decisions are made... recovering it later can be difficult and sometimes impossible'). - Cognitive surrender Cognitive Surrender
(Attributed to Shaw & Nave 2026) Adopting AI outputs with minimal scrutiny, bypassing both intuition and deliberate reasoning (System 1/System 2, after Kahneman). Distinguished sharply from cognitive offloading (a rational, strategic delegation of a discrete task to a tool, e.g. a linter) -- surrender can be intentional but corrodes critical engagement, and it inflates the surrendering developer's confidence even when the AI's output is wrong. - Theory of the system (Naur 1985) Proxy Validity (Construct Validity of Measurement Proxies)
The dynamic, distributed mental model that developers, architects, and other stakeholders hold of how a system works and can be reasoned about -- explicitly not something any single individual needs to hold in full; what matters is that sufficient shared understanding exists across the team. - Executable intent
BDD specifications and tests deliberately designed to capture purpose rather than merely verify current behavior (citing Wynne 2017 -- the Cucumber Book); these artifacts can be executed, and their failure signals that the system has drifted from its intent, as distinct from ordinary regression tests that only encode prior behavior without capturing why.
Propositions
- explicitestablishedSoftware debt is best understood as three interacting types mapped onto three layers of a software system -- technical debt (code and structure), cognitive debt (shared understanding across people), and intent debt (externalized goals/constraints/rationale in artifacts) -- and system health requires attention to all three, not just the layer that is easiest to measure.conf: highsupportsThe Intent Debt · p1 — This is the primary source Osmani's p1 paraphrases almost verbatim ('three independent loci -- code, heads, artifacts'); confirms Osmani's citation is faithful to Storey's own framing.extends ←Coherence, Connections, and… Spacetime Crystals · p8 — Faull's SSRN claim that AI decision systems lose rationales and let organizational intent drift is intent debt (Storey's term: absence of externalized rationale/goals/constraints) observed specifically in AI-driven organizational and API decisions, extending the concept beyond software artifacts.supports ←Technical Debt Quadrant · p3 — Fowler's reckless/prudent x deliberate/inadvertent quadrant is the canonical elaboration of exactly the 'technical debt (code and structure)' layer that Storey's triple-debt model treats as one of three interacting loci — this piece supplies the detailed internal structure of that one layer.supports ←How do software development teams manage technical debt? - An empirical study · p8 — The finding that TD prevention is cheap, well-understood, and still neglected because it competes with visible feature work is the human-era precedent for Storey's claim that cognitive/intent debt (not technical debt) become the binding constraints once code-level debt is partly automated away -- the competing-priorities dynamic was already present before AI, just applied to a different debt layer.
- explicitdevelopedGenerative AI is simultaneously reducing technical debt (via automated refactoring, AI-assisted review, and test generation) while accelerating the accumulation of cognitive and intent debt, because AI generates code faster than teams build genuine understanding of it or externalize the rationale behind decisions.conf: highextends ←Who cleans up after the vibe-coding party? · p9 — Stenberg's first-hand account that AI is 'much better at finding problems than fixing them' -- and that maintaining code, not writing it, is the real challenge -- is a concrete, named-source instantiation of Storey's abstract claim that AI shrinks technical debt (writing) while accelerating cognitive/intent debt (understanding and maintaining).
- explicitCognitive debt is a team-level/project-level property, not an individual one -- it resides in accumulated gaps in shared understanding and awareness across a team, so a codebase can have low technical debt and still be deeply problematic if the team no longer understands it or if it no longer reflects the system's intended purpose.conf: high
- explicitCognitive surrender -- adopting AI outputs with minimal scrutiny, bypassing System 1/System 2 reasoning -- is the psychological mechanism driving cognitive debt accumulation, and it is more dangerous than ordinary cognitive offloading because it also inflates developers' confidence even when the AI's output is wrong, which is precisely why cognitive debt stays invisible until it is too late.conf: high
- explicitIntent is best captured at the moment key decisions are made because recovering it later can be difficult and sometimes impossible -- unlike technical debt, which the paper treats as always addressable later, however costly.conf: mediumextendsTBM 430: Incubate, Compound, Refinance, Liquidate · p2 — TBM 430 frames technical debt purely as a financing choice at the code/portfolio level, with reversibility a function of portfolio quadrant. Storey's tri-layer model extends this by adding two further loci (people, artifacts) where the financing metaphor breaks down -- intent debt, unlike financial-style technical debt, can become genuinely irrecoverable rather than merely costly to service.
- explicitThe three debts causally interact and reinforce each other: intent debt causes cognitive debt (undocumented purpose prevents accurate mental models), cognitive debt causes technical debt (poor understanding leads to poor implementation choices), and technical debt amplifies cognitive debt (messy code is harder to reason about) -- grounded in distributed cognition theory (Hutchins 1995), which treats cognitive processes as properties of systems of people and artifacts together.conf: high
- explicitCognitive debt can be diagnosed through five visible signals even though it is not directly visible in code: resistance to change, unexpected results from changes, slow/unpredictable onboarding, loss of transactive memory (who knows what), and low bus factor.conf: high
- explicitIntent debt can be diagnosed through three patterns: behavior drift from stakeholder expectations (often discovered only at testing or in production incidents), AI agents requiring excessive clarification or producing technically-correct-but-off-target solutions, and gradual loss of articulated non-functional constraints (performance, privacy, accessibility) known only to a few people.conf: high
- explicitcontestedCognitive debt is partially repairable, not purely a one-way accumulation -- system walkthroughs, retrospectives/post-mortems, deliberate onboarding/offboarding communication, and (newly, because code generation is now cheap) reimplementing a feature with different tests or design specifically to rebuild understanding are all offered as active repair practices, not just prevention.conf: highcontradictsAI coding creates two kinds of debt. You're only measuring one · p10 — Bilić Arar's article (whose cognitive-debt definition closely follows Storey's) claims cognitive debt 'has no repayment mechanism... the only lever is prevention, not repair.' Storey's own paper explicitly lists repair practices for cognitive debt (walkthroughs, retrospectives, and especially cheap AI-assisted reimplementation to rebuild understanding), directly challenging the stronger irreversibility claim -- this is the same tension this corpus's extract-ai-coding-two-kinds-debt#g4 gap already flagged against the Osmani extractions, now traced to its origin.
- explicitExecutable intent artifacts -- BDD specifications and tests designed to capture purpose rather than merely verify current behavior -- are a distinct practice from ordinary testing, because they can be executed and their failure specifically signals drift from intent, whereas conventional tests only encode prior behavior and will pass a clean refactor that quietly changes depended-upon behavior.conf: mediumsupportsThe Intent Debt · p29 — Osmani's p29 speculates 'tests can encode intent -- they don't, but they could' as an underdeveloped fourth paydown lever he hints at without developing. Storey's paper explicitly develops exactly this practice ('Executable intent': BDD specs/tests capturing purpose, distinct from tests that only encode prior behavior) -- the primary source already contains the lever Osmani's piece gestures at but leaves undeveloped.
- implicitdevelopedShared understanding should be treated as a first-class deliverable of software development -- something teams invest in explicitly, with tooling, time allocation, and design principles -- rather than something that happens as a side effect of writing code.conf: highrefines ←AI Demands More Engineering Discipline, Not Less · p7 — Majors doesn't deny that shared understanding matters — she relocates where it must live: not fragile 'meat brains' but encoded into production/systems, since 'the knowledge in our heads is unavailable to AI until we encode it into the system.' This refines rather than flatly contradicts the shared-understanding-as-first-class-deliverable claim.
- explicitThe paper deliberately declines to resolve whether documenting intent is worth the effort, whether AI can substitute for the human work of building understanding, and whether some level of cognitive/intent debt is an acceptable strategic choice rather than always a risk -- flagging all three as live, unsettled disputes rather than arguing them to a conclusion.conf: high
Arguments
- AI is reducing technical debt (via automated refactoring/review/test-generation) while removing the friction that used to force developers to build understanding as they wrote code.
- The three debts causally reinforce each other (intent -> cognitive -> technical -> cognitive), so neglecting any one undermines efforts on the others.
- Cognitive and intent debt are harder to detect than technical debt (no rich tooling ecosystem exists for them yet) and, per the paper's own claim, intent debt can become unrecoverable once lost.
- Organizations will not naturally reallocate investment toward understanding and intent capture unless explicitly told to, because delivery-speed pressure defaults attention to the most visible, most measurable debt (technical).
- The practices proposed (walkthroughs, ADRs, executable intent, retrospectives) are sufficient countermeasures if adopted -- the paper does not test this, and does not address the organizational-incentive question of whether teams under throughput pressure will actually adopt costly practices whose payoff is diffuse and delayed.
- From 'AI removes friction that built understanding' + 'the three debts reinforce each other' to 'attention must be proactive across all three layers, not reactive to the one that shows up first' (technical debt, being visible, would otherwise absorb all the attention).
Narratives
- An entrepreneurship course Storey taught: student teams built software products over a semester; by week eight one team hit a wall where simple changes broke things unexpectedly and progress stalled. The team initially blamed technical debt (messy code, shortcuts), but on inspection no one could explain why design decisions had been made or how parts of the system were supposed to interoperate -- their shared 'theory of the system' had fragmented and they had never written down the rationale behind decisions. They had accumulated cognitive and intent debt faster than technical debt, and it paralyzed them.
→ Opens the paper and is explicitly framed as not an isolated case (cross-referenced to Willison 2026); it is the paper's sole concrete illustrative case and is the empirical seed from which the whole triple-debt taxonomy is generalized.
Questions addressed
- ✅ What is the 'triple debt model' and how do its three debts differ?
Technical debt lives in code and limits how systems can change; cognitive debt lives in people and limits how teams can reason about change; intent debt lives in artifacts and limits whether the system still reflects what was meant to be built. - ✅ How does cognitive surrender differ from ordinary cognitive offloading?
Offloading is a rational, strategic delegation of a discrete task to a tool; surrender is adopting AI output with minimal scrutiny, bypassing reasoning altogether, and it inflates confidence even when the AI is wrong. - ⭕ Should teams invest in documenting intent, given the cost?
Explicitly left as an open 'Point for Debate' -- the paper states some practitioners consider it not worth the effort, others consider it critical, and calls the debate 'far from settled.' - ⭕ Can AI reliably help make implicit/tacit knowledge explicit (i.e. can it pay down intent debt for you)?
Left open; the paper notes some practitioners propose this while others argue the value of documentation lies precisely in the human understanding gained while producing it, which AI-generated documentation would bypass. - ⭕ Is the three-layer taxonomy (technical/cognitive/intent) exhaustive, or are there other candidate debt categories (e.g. process debt, dependency debt, data debt, organizational debt)?
Not addressed anywhere in the paper -- the three layers are asserted as 'a software system... exists across three distinct layers' without discussion of alternative or additional candidate categories.
Gaps
- incompleteThe paper never argues that the three-layer taxonomy is exhaustive, nor does it engage candidate additional debt categories (process debt, dependency debt, data debt, organizational debt) that this corpus's own downstream reading of Osmani's derivative article already flagged as missing. This confirms the omission originates in the primary source itself, not merely in secondary treatments of it.
Read next: Avgeriou & Kruchten's broader technical-debt-classification literature; this corpus's organizational-debt concept and extract-tbm-430 (portfolio economics) for a competing single-axis treatment of 'debt' that might subsume or reframe some of these. - incompleteThe paper lists qualitative diagnostic signals for both cognitive debt (five signals) and intent debt (three patterns) but proposes no quantitative measurement instrument or threshold -- 'Monitor the three layers in tandem' suggests onboarding-time tracking and knowledge-concentration metrics only in passing, without operationalizing any of them.
Read next: DORA/SPACE-style measurement-framework literature; this corpus's own osmani-intent-debt#g2 gap raised the identical measurement-thinness problem for Osmani's derivative treatment -- it turns out the primary source is no more quantified. - illogicalThe claim that intent debt, once lost, can be 'difficult and sometimes impossible' to recover is contrasted with technical debt as something that 'can be addressed later' -- treating technical-debt reversibility as a near-universal property. This corpus's own portfolio-economics treatment of debt (TBM 430) argues reversibility is quadrant-dependent, not intrinsic to the debt type -- a liquidated, over-coupled legacy asset can be just as practically unrecoverable as lost intent.
Read next: extract-tbm-430-incubate-compound-refinance-liquidate (the value/carrying-cost portfolio framing) directly complicates this asymmetry claim. - uninformedThe paper's four practice recommendations are entirely team/individual-practice level (walkthroughs, ADRs, executable intent, monitoring) and never engage organizational incentive structures -- e.g. whether managers who measure throughput or visible agent activity will actually reward the diffuse, delayed payoff of externalization work over shipping speed. Kjetil's systems-thinking (Meadows) lens would flag this as an intervention at a low-leverage 'parameter' level (adopt this practice) rather than the higher-leverage 'rule' or 'goal' level (what does the organization actually reward).
Read next: Donella Meadows' leverage-points framework; this corpus's own osmani-intent-debt#g1 gap, which raised the identical individual-discipline-vs-organizational-incentive blind spot for Osmani's derivative piece and now applies equally to the primary source it draws on.
Closes gaps elsewhere
- The Intent Debt · g2 — Storey's paper provides substantially more diagnostic detail than Osmani's derivative treatment: five named signals for cognitive debt (resistance to change, unexpected results, slow onboarding, loss of transactive memory, low bus factor) and three for intent debt (behavior drift, AI agents struggling despite technically correct output, loss of articulated constraints). This partially closes the diagnostic-thinness gap Osmani's g2 raised, though it remains qualitative rather than a proposed metric or instrument -- see this document's own gaps for the remaining quantification shortfall.
- The Intent Debt · g5 — Storey's paper explicitly names and develops 'executable intent' (BDD specifications and tests designed to capture purpose, not just verify behavior) as a practice, plus Architecture Decision Records and Domain-Driven Design -- exactly the fourth paydown lever (intent-specifying tests / specification-by-example) Osmani's g5 flagged as implied but undeveloped in his derivative piece.
- The Intent Debt · g6 — Read directly, Storey's arXiv paper does not address taxonomy exhaustiveness or engage alternative debt categories (process, dependency, data, organizational debt) at all -- confirming that this gap originates in the primary source itself, not merely in Osmani's secondary treatment of it. The gap is not resolved, but the open question 'does Storey address this?' is now answered (no), and is recorded as this document's own g1.
Related documents
- TBM 430: Incubate, Compound, Refinance, Liquidate
- AI coding creates two kinds of debt. You're only measuring one
- The Intent Debt
- Agentic Code Review
- Cognitive Surrender
- Five studies that are changing how I think about AI in software engineering
- Fragments: February 4
- TBM 437: AI and the Recontextualization Tax
- How do software development teams manage technical debt? - An empirical study
- What 60 Years of Data Reveals About How Men and Women Experience Leadership