Triple Debt – Technical Debt was the smallest issue you had

Software teams are discovering an uncomfortable reality: the more they lean on generative and agentic AI to ship features faster, the less they feel they truly understand their own systems, and the harder it becomes to reason about failures, architectural changes, or long‑term evolution.¹ ¹⁶ For decades, technical debt has been the dominant metaphor for the cost of cutting corners in code, capturing how messy architecture, duplication, and quick fixes silently tax productivity until teams finally have to stop and refactor.⁹

Today, however, code has become dramatically cheaper to produce, AI assistants can propose sweeping refactorings in minutes, and we increasingly treat source code as an expendable artifact rather than a carefully hand‑crafted asset.⁴ ¹³ In this environment, the most dangerous debt no longer lives only in the code; it lives in people and in the knowledge artifacts they fail to create. Recent work in software engineering research and practice has proposed a Triple Debt Model, foregrounding cognitive debt, the erosion of shared understanding across a team, and intent debt, the absence of explicit rationale for design decisions, alongside traditional technical debt.¹ ³ ¹⁶ Cognitive debt accumulates when AI‑generated changes outpace the team’s ability to update their mental models, while intent debt grows when systems are built under vague prompts like “just make it work” without recording what “working” was supposed to mean, what constraints mattered, or why particular trade‑offs were chosen.¹ ² ¹⁶ The result is a disturbing but increasingly common experience for many engineers: the codebase may compile, tests may pass, and AI tools may happily edit files, yet no one can confidently explain how the system hangs together or why it looks the way it does.¹⁵ ¹⁶ This article explores that shift in detail, weaving personal, lived developer pain with emerging scientific concepts, and argues that naming cognitive and intent debt is more than vocabulary play; it is a necessary step toward designing practices, tools, and cultures that protect teams’ ability to understand, evolve, and safely automate their systems in an era of cheap code generation.¹ ¹² ¹⁶

From Technical Debt To A Triple Debt World

For most of modern software engineering history, technical debt has been the default lens through which we talk about the long‑term costs of expedient decisions. Ward Cunningham’s original metaphor likened imperfect code to financial debt: you take shortcuts now to move faster, but you pay interest later in the form of reduced productivity, increased bugs, and the need to spend time refactoring.⁹ Over time, the metaphor expanded to encompass architectural complexity, duplication, code smells, poor test coverage, and other structural issues that make a codebase harder to change.⁹ Technical debt became a powerful communication tool, helping engineers explain to managers why refactoring mattered and why delivering features without investment in quality was a short‑term gain but a long‑term risk.⁹ This thinking was grounded in an era where code was expensive to write, refactoring was manual and time‑consuming, and tooling for automated improvement was relatively limited.

In the last few years, however, generative AI has dramatically shifted the economics of code creation. Tools ranging from autocomplete systems to full coding agents can produce fully functioning modules, integration tests, and even architectural scaffolding in minutes, often in response to informal natural language prompts.⁷ ¹² ¹³ Developers now regularly paste error messages into chat interfaces and receive plausible fixes, or ask an AI assistant to “simplify this legacy function” and get back a refactored version that compiles and passes tests.¹³ In some contexts, entire pull requests are drafted by AI, with humans only lightly reviewing for obvious mistakes before merging.¹⁴ ¹⁶ The consequence is that technical debt, at least in its traditional sense of messy or suboptimal implementation details, is increasingly tractable: the same tools that created the mess can often help clean it up, proposing many small refactorings that humans can review and accept.⁴ ¹³

This is not to say that technical debt has vanished. AI can generate code that looks tidy on the surface yet hides subtle design flaws, performance bottlenecks, or maintainability issues that are hard to detect automatically.⁴ AI‑generated code can also introduce its own form of debt, such as overly generic abstractions, unnecessary complexity, or dependence on opaque libraries that the team does not fully understand.⁴ ¹² However, the cost of addressing these issues is lower than it used to be, because AI can assist in locating and restructuring problematic code patterns, suggest more idiomatic designs, and even write missing tests.⁴ ¹³ It is now conceivable, at least in principle, for teams to treat code as a malleable surface, one they can reshape with the help of AI as requirements change, rather than a brittle structure whose defects are expensive to correct.

What becomes more pressing in this environment is not the state of the code itself but the state of the team’s understanding of that code and their ability to recall why it was written in a particular way. This is the shift that the Triple Debt Model tries to capture.¹ ¹⁶ In this model, technical debt is one axis, describing the implementation‑level issues in the code. Cognitive debt is a second axis, describing the erosion of the shared mental model of the system within the team. Intent debt is a third axis, describing the lack of externalized rationale, goals, and constraints that explain why the system is the way it is.¹ ³ ¹⁶ The insight is that generative AI accelerates the accumulation of cognitive and intent debt more than technical debt, because it allows software to evolve much faster than humans can mentally track, and it often does so without the discipline of explicit design documentation or careful decision logging.¹ ¹⁶

The resulting tension can feel strange if you grew up professionally in a world where the main source of pain was ugly code. You may look at a modern AI‑assisted codebase and see reasonably structured classes, clean naming, and decent test coverage, yet feel deeply uneasy because you have no solid mental grip on the system as a whole.¹⁵ ¹⁶ You may remember a time when you could hold an entire service in your head, explaining its invariants and failure modes, and compare it with today, where even small changes feel perilous because you are not sure how they ripple across AI‑modified code paths.¹⁵ In this context, the Triple Debt Model is not just theoretical; it provides language for what many teams are already experiencing in practice, namely that their problems have migrated from the visible artifacts of code to the invisible artifacts of shared understanding and documented intent.¹ ¹⁶

Cognitive Debt: When The Shared Theory Evaporates

To understand cognitive debt, it helps to start with the notion of a shared mental model. In team cognition research, a shared mental model refers to the common internal representation of knowledge that team members hold about tasks, equipment, and each other’s roles. When teams share accurate and aligned mental models, they coordinate more smoothly, anticipate each other’s actions, and adapt to surprises more effectively.⁵ ¹⁰ In software teams, a shared mental model typically includes an understanding of core domain concepts, key architectural components, dependencies between services, invariants, and typical failure modes. It is what allows a handful of engineers to diagnose a complex production incident at 3 a.m. by mentally simulating how requests flow through the system and where latent bugs might reside.

Cognitive debt builds up when the system changes faster than the team’s mental model can keep pace, or when knowledge is trapped in a few individuals’ heads and not distributed across the team.¹ ¹⁶ It is closely related to, but distinct from, cognitive load. Cognitive load describes how mentally demanding a task feels in the moment, such as reading a dense function or debugging a tricky issue, whereas cognitive debt describes the long‑term accumulation of gaps and misalignments in understanding across a project.⁶ ¹⁶ One way to visualize cognitive debt is to imagine a gap between the actual complexity of the system and the amount of that complexity that is reflected in an accurate shared mental model within the team.¹ ¹⁶ As the system grows and changes, if the team does not invest in updating that shared model through reviews, documentation, and knowledge sharing, the gap widens. Eventually, the team may reach a point where their internal “theory of the system” no longer corresponds with reality, and they can no longer reason safely about changes.¹⁵ ¹⁶

Peter Naur’s classic idea that a program is more than its source code is deeply relevant here. Naur argued that a program is a theory that lives in the minds of developers, capturing what the program does, how intentions are implemented, and how it can be changed. This theory does not reside solely in any one developer or document; it is distributed across people, emergent from conversations, experiences, and artifacts.¹⁶ Cognitive debt, in this sense, is what happens when the distributed theory collapses. Teams lose track of why certain invariants exist, what constraints are critical, or how data flows through the system. They may still be able to patch local bugs, but they no longer have a coherent mental representation of the global behavior of the software.¹⁵ ¹⁶

Generative AI intensifies cognitive debt in several ways. First, it increases the rate of change. AI can propose entire pull requests or comprehensive refactorings that would have taken humans days or weeks, and these changes can be merged after only superficial review.¹³ ¹⁴ ¹⁶ When this happens repeatedly, the system’s behavior may shift substantially without a corresponding update to the team’s mental model, leaving developers with an outdated or partial theory of how things work.¹ ¹⁶ Second, AI can produce code that is syntactically and structurally clean, giving a false sense of security. Developers may skim the changes, see well‑named methods and formatted code, and assume they understand it, when in reality key interactions, assumptions, or failure modes are not obvious at a glance.⁴ ¹² Third, AI can participate in a form of knowledge inflation: it creates code and comments that appear authoritative, but the team has not gone through the cognitive work required to internalize what that code actually does. The comprehension gap widens, even as the artifact looks professional.

Empirical and anecdotal evidence is starting to surface around this phenomenon. Practitioners report experiences where AI‑assisted development helped them clean up legacy code quickly, but after a series of AI‑driven changes, they felt they had “lost the plot” of how their system worked.¹³ ¹⁵ ¹⁶ In some cases, teams realized that their main bottleneck was not messy code but the lack of confident understanding of core flows, data models, and integration points.¹⁵ ¹⁶ Simon Willison, reflecting on his own projects, noted that as he added more AI‑generated features, he no longer had a firm mental model of what his tools could do and how they worked, making every new feature decision harder to reason about.¹⁵ These accounts align with the research framing of cognitive debt as a project‑level property that captures erosion of understanding across time, not just momentary confusion.¹ ¹⁶

The lived experience of cognitive debt is often subtle until it suddenly is not. Engineers may begin to feel slower when making changes, spending more time tracing through code, checking assumptions, or adding extra logging “just in case.” They may become more hesitant to approve refactors, fearing hidden side effects in areas they no longer fully grasp.¹⁶ Production incidents become more challenging to diagnose, because the mental shortcuts the team once had—such as “this class is the only place that touches that table”—no longer hold after multiple AI‑driven edits.¹ ¹⁶ Over time, velocity and confidence decline, even if the visible code quality looks stable or even improved. What has degraded is not the artifact but the shared mental model behind it.

Intent Debt: When The “Why” Goes Missing

If cognitive debt concerns the erosion of understanding, intent debt concerns the erosion or absence of rationale.¹ ² ¹⁶ Intent debt lives in artifacts: specifications, design documents, architecture decision records, ADRs, inline comments, commit messages, pull request descriptions, and other places where teams record why they made certain choices.² ¹¹ ¹⁶ When those artifacts are missing, outdated, or too vague, the system’s evolution is guided by an incomplete or inaccurate understanding of its original goals and constraints. Intent debt is therefore not about code being wrong; it is about nobody being able to say whether the code is still aligned with what the system was meant to do.² ¹⁶

Addy Osmani describes intent debt as the absence or erosion of externalized rationale, goals, and constraints that explain why the system is the way it is.² The key word is externalized. It is not enough for a developer to have a reason in their head; the rationale must be written down somewhere that a teammate, a future self, or an AI agent can read and rely upon.² Without such externalization, we end up in situations where a configuration value, a timeout, or a particular data model exists for reasons no one remembers. AI tools can infer plausible stories from the code—such as guessing that a 300ms debounce was chosen for UX reasons—but these stories remain guesses, not guaranteed truths.² When those guesses solidify into confident explanations, without grounding in documented intent, they can be more dangerous than silence.

Generative AI magnifies intent debt by making it easier to create systems without clear design processes. A developer can now ask an AI agent to “build a microservice that exposes this endpoint and stores this data in a database,” and receive a fully functioning implementation.⁷ ¹³ ¹⁴ The prompt may encode a vague intent, such as “make it fast and secure,” but few teams systematically capture what “fast” or “secure” meant in context, what trade‑offs were acceptable, or what constraints were non‑negotiable.² ¹⁶ When the system later fails under load or exhibits unexpected behavior, there is no reliable record explaining why the architecture looks the way it does or which requirements shaped earlier decisions.¹ ² Human developers lack a definitive guide to original intent; AI agents, which rely on textual artifacts for context, have even less grounding.

Intent debt is particularly pernicious because it is the one form of debt that AI cannot pay down for you.² AI can refactor code to reduce technical debt and can help explain code to reduce cognitive debt, but it cannot invent true intent. It can propose rationales, but those rationales are inherently speculative. Osmani stresses that an agent can infer a plausible rationale from code in the same way a developer can guess why a previous engineer did something, but a guess about intent is not the intent.² The model does not know whether a magic number was the result of performance tuning, a UX decision, or a random choice never revisited.² In fact, its confidence in the guess can be harmful: when an agent presents an invented rationale with authoritative tone, teams may mistake it for the actual design intent and make decisions based on fiction.

Research on intent debt overlaps with long‑standing ideas in architecture documentation. Architecture decision records, ADRs, were introduced precisely to capture important architectural decisions along with their context and consequences.¹¹ ADRs are lightweight documents that record what decision was made, what options were considered, and why a particular option was selected.¹¹ They are an effective antidote to intent debt because they make the “why” explicit at the moment the decision is made, when costs are lowest.² ¹¹ However, in AI‑accelerated workflows, decisions are often more emergent and less consciously deliberated. A developer might accept an AI‑generated structure without fully thinking through its implications, and thus may not recognize that a conscious architectural decision worthy of an ADR has just been made.¹ ¹⁴ ¹⁶

In practice, intent debt manifests as paralysis during change. When a team is asked to modify or extend a system with high intent debt, they quickly find themselves unable to answer basic questions. Why was this particular database chosen? Why are we caching responses for this endpoint but not that one? Why is this background job scheduled every five minutes instead of every hour?¹ ² ¹⁶ Without documented rationale, any change feels risky because it might violate a hidden constraint or expectation. Developers may default to copying existing patterns without understanding them, further entrenching unknown decisions. Or they may make aggressive changes, only to discover later that they inadvertently broke critical nonfunctional requirements, such as latency guarantees or compliance constraints, that were never clearly recorded.¹ ² ¹⁶

Intent debt also impairs collaboration with AI agents. Agentic engineering approaches envision systems where AI agents autonomously review pull requests, perform refactorings, or maintain portions of a codebase.¹ ⁸ ¹⁴ For such agents to act safely, they need access not just to code but to the underlying intent: conventions like “we never call this internal API directly,” constraints such as “this data must never leave the EU,” and goals like “we prioritize accessibility over micro‑optimizations in this module.”² ⁸ ¹⁶ Intent files such as AGENTS.md, which describe team conventions, rationales, and constraints, have been proposed as a mechanism to give agents an intent ledger rather than mere configuration.² Without such artifacts, agents operate in a vacuum, optimizing for local properties such as correctness or performance while missing broader system‑level goals.

The cumulative impact of intent debt is that teams find themselves unable to answer the question, “Does this system still do what we meant it to do?”¹ ² ¹⁶ The system may be functional, even high‑performing, but its alignment with original or evolving goals is opaque. At that point, the system’s evolution is a drift rather than a guided trajectory. Decisions are made reactively, based on immediate needs or AI recommendations, rather than anchored in a clearly articulated intent. In the long run, such drift can be more damaging than classic technical debt, because it undermines the very notion of strategy in software design.

How AI Assistance Changes The Skill And Risk Landscape

The rise of generative AI in software engineering does not occur in isolation; it reshapes human skill development, risk profiles, and organizational practices. A recent empirical study on AI assistance and coding skills found that AI tools can substantially improve short‑term productivity and code quality, but they also create tension around skill formation.¹² When developers rely heavily on AI to generate solutions, they may have less opportunity to practice core skills such as debugging, architecture reasoning, and deep comprehension, which are essential for catching errors and reasoning about complex systems.¹² The authors highlight that as coding becomes more automated, humans still need to retain the ability to critically evaluate AI outputs, understand underlying principles, and intervene when AI produces wrong or harmful code.¹² This perspective dovetails with the notion of cognitive debt: relying on AI without investing in understanding can erode the team’s ability to reason about its own software over time.

Another line of research examines how developers actually use AI agents in practice. Studies of coding agents deployed in real teams reveal that while agents can help automate routine tasks such as code review or refactoring, they often struggle to understand the broader implications of changes or to handle existing bad code gracefully.¹⁴ Developers report cases where agents are “overly generative,” adding new code on top of flawed existing implementations rather than refactoring them properly, and failing to detect when their changes conflict with hidden assumptions.¹⁴ These agents operate mostly at the level of local correctness and structural patterns, not at the level of system‑wide intent or shared mental models. That limitation is not merely a tooling issue; it is a symptom of missing cognitive and intent scaffolding that agents could consume.

Practitioner literature complements these findings by highlighting the hidden costs of AI‑generated code. An article from AWS emphasizes that when AI generates code, the shortcuts it takes are often invisible to humans.⁴ Developers reviewing AI‑produced pull requests may see code that compiles and passes tests but does not realize that performance compromises, security oversights, or future maintainability problems have been introduced.⁴ The problem is not just technical debt in the narrow sense but the fact that humans may not even recognize that debt at review time, because they lack the understanding or documented intent needed to evaluate deeper impacts.⁴ In turn, this gap feeds cognitive debt: every merged change introduces behavior that the team nominally “owns” but does not fully comprehend.

At the same time, practitioners experimenting with AI‑assisted refactoring report strong benefits when tools are used deliberately and with human oversight.¹³ One developer describes using an AI assistant to simplify complex legacy code by asking it to destructure inputs, extract utility functions, and unnest conditionals with early returns.¹³ The assistant handled the mechanical transformations quickly, allowing the developer to focus on higher‑level design decisions.¹³ In these scenarios, AI acts as a force multiplier rather than a replacement for human understanding. The developer remains responsible for the cognitive and intent layers: deciding what simplifications are appropriate, ensuring that invariants are preserved, and updating documentation to reflect new structures.¹³ This pattern suggests that AI’s impact on cognitive and intent debt depends strongly on how teams integrate AI into their workflows.

From a personal standpoint, many developers find themselves oscillating between exhilaration and dread. On the one hand, AI tools can feel magical: they rescue you from tedious boilerplate, help you decipher unfamiliar libraries, and conjure entire sample applications from brief prompts.¹² ¹³ On the other hand, there is an unsettling feeling that you are relinquishing some of your own understanding. When you accept an AI rewrite of a complex function that you have only skimmed, you may feel a slight cognitive dissonance: it works now, but do you truly know why?¹⁵ ¹⁶ After a few such iterations, it is easy to wake up months later and realize that the core behavior of a system you nominally own has drifted beyond your mental reach. That realization can be demoralizing, especially for engineers who take pride in deeply understanding their craft.

The cumulative effect of these trends is a shift in what constitutes responsible engineering. Historically, investing in code quality and architectural soundness was sufficient to manage technical debt. Today, responsible engineering also requires deliberate management of cognitive and intent debt. Teams must ask not only “Is this code correct and clean?” but also “Do we understand this code?” and “Do we know why it was written this way?”¹ ² ¹⁶ AI tools can help answer the first question but are largely powerless against the latter two unless we supply them with appropriate artifacts. That dependency on human‑created knowledge structures reframes AI not as an autonomous savior but as a collaborator that relies heavily on human‑produced context.

The Pain Of “Not Knowing How My Own Codebase Works”

One of the reasons cognitive and intent debt resonate with practitioners is that they give a name to a specific, increasingly common pain: the feeling that you no longer understand your own codebase.¹⁵ ¹⁶ This feeling can creep up gradually. Early in a project, you may enjoy a clear mental picture of the core modules, data flows, and constraints. You can answer questions like “What happens when this flag is set?” or “Where are we validating this input?” almost instinctively. Code reviews feel like a natural extension of your existing knowledge, and production incidents, while stressful, are at least tractable because you can trace through the system with confidence.¹⁰ ¹⁶

As AI‑assisted changes accumulate, this clarity can erode. You may find yourself reviewing pull requests that touch modules you do not recognize or introduce patterns that you did not design.¹⁴ ¹⁶ You skim the diff, relying on syntactic cleanliness and test coverage as proxies for correctness, and click “approve” because the change appears reasonable.⁴ ¹³ Weeks later, when you try to modify that area again, you realize you have only a superficial grasp of how it works. You re‑read the code, perhaps with help from an AI explanation, but it feels foreign. The code is yours in the sense that it lives in your repository and passes your tests, yet it is alien in the sense that you do not fully inhabit its logic.¹⁵ ¹⁶

This alienation is not merely aesthetic. It has practical consequences for risk perception and decision‑making. When you do not understand parts of your system, you naturally become more risk‑averse about changing them. Even simple modifications feel dangerous, because you cannot reliably predict side effects or interactions with other components.¹ ¹⁶ Over time, these areas can become “no‑go zones,” where only a few brave or desperate engineers dare tread. Ironically, these zones may not coincide with regions of high technical debt; they may be areas of clean but cognitively opaque code produced by AI.⁴ ¹⁶ In other parts of the system, you may over‑trust AI suggestions, assuming that if the tool proposes a refactor, it must have considered the implications, when in fact it has no access to the hidden intent behind the design.² ¹⁴

The emotional texture of this experience is worth acknowledging. Many engineers derive a sense of mastery and satisfaction from building systems they understand deeply. Losing that understanding can feel like a loss of professional identity. It can trigger imposter syndrome, as you wonder whether you are “falling behind” or unable to keep up with the accelerated pace of AI‑driven development.¹² ¹⁵ At the same time, it can lead to frustration with organizational practices that treat understanding as optional and prioritize short‑term velocity over long‑term cognitive health.¹ ¹⁶ Naming cognitive and intent debt provides a way to surface these concerns in a scientifically grounded manner rather than as vague unease.

From a scientific perspective, this pain can be framed as the collapse of shared mental models. Team cognition research shows that when shared mental models are degraded or misaligned, coordination suffers, errors increase, and adaptive performance declines.⁵ ¹⁰ In software teams, a degraded shared mental model means that different engineers hold conflicting beliefs about how the system behaves, leading to misunderstandings in design discussions, code reviews, and incident response.¹⁰ ¹⁶ For example, one engineer may believe a particular invariant is always enforced upstream, while another believes it is enforced locally, resulting in gaps that AI‑generated changes can inadvertently exploit. Cognitive debt quantifies this degradation as a form of cost that grows over time; intent debt quantifies the missing artifacts that could have anchored a shared mental model more robustly.¹ ² ¹⁶

Recognizing this pain as a systematic phenomenon rather than an individual failing is crucial. It is not that individual engineers have become careless or less intelligent; it is that the development environment has changed in ways that outpace traditional practices for maintaining understanding and rationale. AI tools accelerate change and obscure decisions, while organizational incentives often reward shipping features over documentation or reflection.⁷ ¹² ¹⁶ Cognitive and intent debt offer a vocabulary to push back, allowing engineers to argue that investing in understanding and intent is not indulgent but necessary risk management in an AI‑accelerated world.¹ ² ¹⁶

Mitigating Cognitive And Intent Debt In Practice

If cognitive and intent debt are real and growing, the natural question is what to do about them. The emerging literature and practitioner advice converge on a few broad strategies, even if specific implementations vary across teams. Central to almost all approaches is the idea that humans must consciously create and maintain artifacts that AI can read but cannot generate faithfully on its own.¹ ² ¹¹ ¹⁶ These artifacts carry the intent and support the distributed theory of the system, functioning as anchors against drift.

One foundational practice is to establish explicit cognitive debt mitigation strategies. For example, teams can require that at least one human on the team fully understands each AI‑generated change before it ships, rather than allowing blind merges.¹⁶ This might mean slowing down certain reviews, but the trade‑off is a deliberate investment in maintaining a robust mental model. Teams can also document not just what changed in a pull request but why, capturing the rationale behind accepting an AI suggestion.² ¹⁶ Regular checkpoints, such as dedicated code review sessions, architecture retrospectives, or knowledge‑sharing meetings, can serve as opportunities to rebuild shared understanding, especially after periods of intense AI‑driven change.¹⁰ ¹⁶

Intent debt can be mitigated by deliberately externalizing rationale wherever decisions are made. Architecture decision records provide a structured template for doing so at the architectural level, but similar practices can be applied at smaller scales, such as recording why a particular configuration, timeout, or data model was chosen.² ¹¹ ¹⁶ Osmani advocates for treating AGENTS.md or similar intent files as ledgers of team conventions and constraints, explaining not just what the code is but what the team means by it.² Lightweight decision logs, recorded near the moment of choice, are “pure intent‑debt paydown,” because they preserve the reasoning that would otherwise vanish into hazy memory.² Importantly, generative AI can assist in drafting these artifacts, but humans must supply the content and review it for fidelity to actual intent.² ¹⁶

Some teams are experimenting with tests that capture intent rather than just correctness. For instance, they may write tests that encode performance expectations, security constraints, or invariants that reflect design decisions.¹⁶ By doing so, they create executable artifacts that represent parts of the system’s theory. AI assistants can then use these tests as guardrails when proposing changes, ensuring that new code respects not only functional behavior but also higher‑level intent.¹² ¹⁶ Design documents can be updated continuously, with AI helping to detect inconsistencies between documentation and code, but human architects ensuring that evolving intent is correctly reflected.¹ ⁷ ¹⁶

Another important dimension is treating prototypes and AI‑generated experiments as disposable unless and until their intent is made explicit.¹⁶ It is tempting to ship AI‑generated prototypes directly to production because they “work,” but doing so often embeds large amounts of intent debt, as the prototypes were created under exploratory, loosely defined goals.¹⁶ A more sustainable practice is to treat such prototypes as learning tools, then deliberately re‑architect or rewrite them with clearer intent once requirements solidify. AI can help in the mechanical rewriting; humans must supply the intent and ensure the new system aligns with it.¹³ ¹⁶

On the cognitive side, some teams are exploring tools that support cognitive tracking, dependency visualization, and explanation.¹⁶ AI can be harnessed to generate dependency graphs, flow diagrams, or natural language explanations of complex code paths, which developers can use to rebuild their mental models.⁷ ¹³ ¹⁶ Yet, there is a distinction between passive explanation and active understanding. True mitigation of cognitive debt requires not only reading AI‑generated explanations but engaging with them critically, asking questions, and verifying them against system behavior.¹² ¹⁵ Teams can foster cultures where asking “Why does this work?” is valued as much as asking “Does this work?”, encouraging deeper cognitive investment even in the presence of seemingly effortless AI assistance.¹⁶

Ultimately, mitigating cognitive and intent debt involves a combination of technical practices, human habits, and organizational incentives. Technically, we can adopt ADRs, intent files, and targeted documentation. Humanly, we can commit to understanding AI‑generated changes and to recording our rationale. Organizationally, we can adjust metrics and expectations to reward understanding and resilience rather than pure feature counts.¹ ² ¹⁶ None of these steps eliminate the allure of cheap code generation, but they can balance it with safeguards that preserve the team’s ability to reason about and guide their system over time.

The Future Of Software Engineering In A Debt‑Rich World

Looking ahead, it is increasingly clear that software engineering is entering a debt‑rich world, where technical, cognitive, and intent debt coexist and interact. The Triple Debt Model offers a conceptual framework for navigating this world, but practical tools and processes are still evolving.¹ ¹⁶ As generative and agentic AI become more capable, we may see systems where agents not only write code but also propose updates to documentation, tests, and intent artifacts. However, their effectiveness will hinge on the quality and completeness of the human‑created knowledge structures they consume.² ⁸ ¹⁶

One promising direction is the development of AI‑assisted cognitive and intent dashboards. Such tools could track metrics related to code churn, documentation coverage, and decision logging, and infer where cognitive and intent debt are likely accumulating.¹ ¹⁶ For example, they might flag modules that have undergone extensive AI‑generated changes without corresponding updates to design documents or ADRs, or highlight areas where tests fail to capture important nonfunctional constraints.¹⁶ While these inferences would be imperfect, they could provide early warning signs, prompting teams to invest in understanding and intent before debt becomes crippling.

Another frontier lies in educational practices. As AI becomes embedded in everyday development, training new engineers will require teaching not only coding skills but also debt management skills. Novices will need to learn how to collaborate with AI responsibly, including when to accept AI suggestions, how to verify them, and how to document the intent behind adopting them.¹² ¹⁶ Educational programs may integrate exercises that explicitly explore cognitive and intent debt, such as having students navigate AI‑modified codebases with missing documentation, then reflect on the pain points and propose mitigation strategies. Such training could normalize debt concepts as part of software literacy rather than niche concerns.

There is also a broader philosophical question about what it means to “understand” a system in an era of complex, AI‑modified software. Historically, understanding implied the ability to mentally simulate the system’s behavior in significant detail. In the future, understanding may rely more on being able to interrogate and compose explanatory tools, relying on structured artifacts, visualizations, and AI‑generated narratives to navigate complexity.⁷ ¹² ¹⁵ Even so, cognitive debt remains relevant because these tools themselves require coherent underlying theories and intents to function properly. If the system’s design is inherently ad hoc and undocumented, no amount of explanation tooling can fully compensate.

From a personal vantage point, the future may involve a continuous balancing act. As engineers, we will likely continue to embrace AI where it reduces drudgery and accelerates routine tasks. Few of us will miss hand‑writing boilerplate or tedious scaffolding when an assistant can do it reliably.¹² ¹³ At the same time, we may become more mindful of situations where accepting AI‑generated code without deep engagement feels wrong, where the risk of accumulating cognitive and intent debt outweighs the immediate productivity gain. Learning to sense those moments and respond appropriately could become one of the signature skills of the modern software engineer.

In the end, the story of cognitive and intent debt is not a story of AI as villain. It is a story of acceleration without proportionate investment in understanding and rationale. Generative AI exposes longstanding weaknesses in our documentation habits and shared understanding practices, forcing us to confront debts that were always present but now grow faster.¹ ¹⁶ By naming these debts and studying them scientifically, the software engineering community has taken an important step toward designing the next generation of practices and tools. The challenge ahead is to integrate these insights into everyday life: into pull request templates, sprint rituals, onboarding materials, and team cultures. Only then can we reap the benefits of AI‑accelerated development without quietly eroding the very cognitive foundations that make software engineering a disciplined craft rather than a chaotic act of faith.

Conclusion

The rise of generative and agentic AI has transformed the landscape of software development, making code dramatically cheaper to generate and refactor while introducing new, less visible forms of risk. Traditional technical debt, rooted in messy code and flawed architecture, remains important but is increasingly tractable with AI assistance. Far more insidious are cognitive debt, the erosion of a team’s shared mental model of the system, and intent debt, the absence or decay of explicit rationale for design decisions. These debts, articulated in recent research and practitioner discussions, give precise names to the growing developer pain of “not knowing how my own codebase works anymore.”¹ ² ¹⁵ ¹⁶

Cognitive debt accumulates when AI‑driven changes outpace human understanding, leaving teams with outdated or fragmented theories of how their software behaves. Intent debt accumulates when systems are built and modified under informal prompts like “just make it work,” without recording goals, constraints, and trade‑offs in accessible artifacts. AI can help pay down technical debt and, to some extent, support comprehension, but it cannot reliably reconstruct true intent. In a world where agents operate without access to human‑authored rationales, both humans and machines are at risk of being paralyzed when systems fail, unable to reason confidently about causes or remedies.

Mitigating these new debts requires deliberate effort. Teams must adopt practices that prioritize understanding and intent alongside correctness and speed. This includes requiring human comprehension of AI‑generated changes, capturing decisions in ADRs and intent files, writing tests that encode design constraints, and creating regular rituals to rebuild shared mental models. AI can assist in drafting documentation, generating explanations, and visualizing dependencies, but humans must remain responsible for supplying authentic intent and for engaging deeply with the evolving theory of the system.

Crucially, recognizing cognitive and intent debt does more than introduce new jargon; it reframes how we think about quality and responsibility in software engineering. It acknowledges that the most dangerous debt may no longer live solely in the code but in the gap between code and understanding, between behavior and rationale. As AI continues to accelerate change, the capacity of teams to maintain a coherent shared theory of their systems and a clear record of why those systems look as they do will determine whether AI is a lever for sustainable progress or a driver of brittle, opaque complexity.

For engineers grappling with the unsettling feeling that their codebase has become alien, these concepts offer both validation and a path forward. The feeling has a scientific name; the risks are real but manageable. By foregrounding cognitive and intent debt, we can begin to design tools, cultures, and workflows that ensure the shared theory is not dead, but actively cultivated—even in an era where code is easy, and understanding is the scarce resource that truly matters.¹ ² ¹⁶