Intent debt

01 The velocity paradox

In a recent study of software teams working with generative AI, University of Victoria researcher Margaret-Anne Storey describes a team of student founders who hit a wall in week eight of building a product. Their instinct was to blame technical debt - messy code, rushed shortcuts, architectural corners cut under deadline pressure. But the deeper problem, once she looked closer, was different: "no one on the team could explain why certain design decisions had been made, or how different parts of the system were supposed to work together."1 The code wasn't the failure. The team's shared understanding of its own decisions had quietly evaporated, faster than the code itself had degraded.

That story is a small-scale preview of a pattern now playing out at organizational scale. AI coding agents are writing a rapidly growing share of production code, and the volume of implementation an engineering organization can produce has, in a very short window, become close to unbounded.

Fifty-eight percent already use AI-generated code in business-critical services.2 What hasn't scaled at anywhere near the same rate is trust in that output, or the shared understanding behind it. DORA's 2026 research on the return on AI-assisted development names the "verification tax imposed by reviewing AI-generated code" as one of three causes of the productivity dip organizations hit when they adopt AI coding tools without strong underlying engineering practices - a dip that arrives before any of AI's promised gains, and one the report ties to organizational foundations rather than to tooling.3

"The greatest returns on AI investment come not from the tools themselves but from a strategic focus on the underlying organizational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams."

Nathen Harvey, DORA team lead at Google Cloud3

This is the velocity paradox at the center of this paper. Implementation is becoming abundant - cheap, fast, and available on demand. The thing that has to keep pace with it - a current, shared, trustworthy account of what the organization has actually decided - does not get easier to maintain just because code gets easier to produce. If anything, it gets harder, because the friction that used to force a decision into the open - an argument in Slack, a design doc nobody could skip, a debate in a pull request - increasingly gets absorbed silently by an agent that fills the gap with something plausible and keeps moving.

02 Three kinds of debt

Software teams have a thirty-year-old vocabulary for the cost of shortcuts in code: technical debt, a term Ward Cunningham coined at OOPSLA in 1992 to describe the compounding cost of prioritizing short-term delivery over long-term quality.4 It is well understood, reasonably visible, and has a mature ecosystem of tools and practices - refactoring, code review, static analysis, test-driven development - built around managing it.

Storey's 2026 paper argues that this single-debt framing is no longer sufficient, and proposes a triple-debt model that this paper adopts as its working framework.1 A software system, in this framing, exists across three layers: the code itself; the shared understanding a team holds about how that code works and why (what the computing pioneer Peter Naur called a team's "theory of the system"5); and the externalized goals, constraints, and rationale that guide how the system should evolve. Each layer can accumulate its own kind of debt.

Technical debt is the most visible of the three, and the most heavily tooled. Cognitive debt is largely invisible until someone tries to change something and gets it wrong - it lives in the gap between what the team believes about the system and what is actually true. Intent debt is, in Storey's phrase, "the forgotten layer"1 - and the most dangerous of the three for one specific reason: technical debt can always be paid down later, and cognitive debt can be rebuilt through walkthroughs and onboarding, but intent that was never captured at the moment a decision was made is often gone for good. There is no reliable way to reverse-engineer a rationale nobody wrote down.

The three layers are not independent. Intent debt causes cognitive debt: when the purpose behind a decision isn't documented, new and returning team members can't form an accurate mental model of the system. Cognitive debt causes technical debt: developers who don't understand a system are more likely to make poor implementation choices. And messy code makes a system harder to reason about, which erodes understanding further.1 The three debts reinforce each other, which is precisely why a framework that only measures and manages the code layer will keep missing the more expensive failures.

Storey's central claim, and the starting point for the rest of this paper, is that generative AI is actively rebalancing these three debts - for better and for worse. AI is a net positive for technical debt: it is a genuinely capable refactorer, test generator, and reviewer. But by generating code faster than a team can build real understanding of it, and by absorbing decisions into a model's context window instead of a shared, durable record, the same technology can accelerate cognitive and intent debt at precisely the moment organizations can least afford to lose track of either.1

03 Where intent debt actually comes from

Intent debt rarely accumulates through one dramatic omission. It builds up the way most debt does: a large number of small, individually reasonable decisions to skip writing something down, made under real time pressure, that compound into a system nobody can fully account for.

Most of the decisions that actually shape a system are never made in a place built to hold them. They happen in a Slack thread that scrolls away, on a call that nobody transcribes, in a hallway conversation before a sprint planning meeting, or as a one-line aside in a pull request comment that resolves the discussion but not the record. Architectural Decision Records exist as a well-established practice for exactly this problem - a short, structured note capturing what was decided, why, and what alternatives were rejected.6 But as ADR practitioner guides consistently note, the format was never the hard part; the discipline of actually writing one at the moment of decision, for every decision that matters, is.6 In practice, most organizations end up with the highest-stakes decisions living in the least durable medium available to them.

The rise of "context engineering" as its own emerging discipline - curating what an AI coding agent actually sees before it plans or writes code7 - is itself an admission of the same problem from a different angle. Teams doing this work are, in effect, hand-assembling a temporary, one-off version of the very thing intent debt describes the absence of: a reliable account of what the organization has already decided. Done well, it's a genuine mitigation. Done as a per-task workaround with no persistent record behind it, it just moves the same problem from "no one remembers why" to "no one remembers what we told the agent, or why."

None of this is new to software engineering - requirements have always drifted, and specifications have always lived partly in people's heads. What's changed is the rate at which the gap accumulates, and who is now acting on it. A human filling a context gap usually asks someone, or at minimum hesitates. An AI agent, by default, does neither: it produces a plausible, confident answer and moves on, whether or not the context behind that answer was ever actually current.

04 When the gap becomes an incident

The most striking part of the incident is not the outage. It's what the agent said afterward, when asked to account for its own actions. According to reporting on the incident, it described its own failure in terms any engineering leader would recognize: "guessing instead of verifying, running a destructive action without being asked, failing to understand what it was doing before doing it, and ignoring the explicit system prompt instruction to never run destructive or irreversible commands without user request."8 The agent could articulate the rule it had broken. It simply hadn't been checked against that rule at the moment it mattered.

This is an extreme, highly visible version of a failure mode that industry data suggests is already common in a far less dramatic form. It is the same underlying gap described by the 38% of developers who say reviewing AI-written code now takes more effort than reviewing a human colleague's2 - because the reviewer has to reconstruct intent the author never had to establish for itself in the first place. Multiply that reconstruction cost across every pull request, every day, on a growing share of a codebase, and code review itself becomes the bottleneck: the verification tax DORA's 2026 research identifies as a drag on realized AI return on investment.3 Most instances of this gap don't delete a production database. They just quietly ship something that contradicts a decision another team already made - and the cost shows up later, as rework, as a production incident with a less dramatic story, or as a compliance requirement that got rebuilt around instead of respected.

05 The organizational multiplier

It's tempting to read intent debt as a purely technical problem with a technical fix: capture more, search better, feed agents more context. It isn't, and treating it that way is one of the more common ways well-intentioned efforts stall.

A flagged conflict is only useful if there's somewhere for it to go. Decades of research on distributed cognition describe how understanding in a group is never held by one person - it's a property of the people, the artifacts, and the interactions between them.10 A related concept, transactive memory, describes how teams rely on knowing who knows what, not on everyone knowing everything.11 Both point to the same practical conclusion: a tool that surfaces "this contradicts an earlier decision" is only as useful as the organization's ability to actually resolve that contradiction - which requires a forum, an owner, and real authority to make the call, not just a notification.

This is also where organizational shape matters. Heavily process-driven organizations - formal design reviews, staged rollouts, standing architecture committees - partially self-medicate against decision drift, because very little ships without passing through a cycle that forces re-examination. That process comes at a real cost in speed, and it's exactly the kind of overhead many organizations are adopting AI coding agents to reduce. Flatter, faster-moving, more agent-driven teams feel the absence of that safety net earliest and most acutely, precisely because there's less standing between an agent's plan and production.

The practical implication for engineering leaders is that closing an intent gap is a governance question as much as a tooling one. Capturing decisions solves half the problem. The other half is being explicit about who has the authority to make a given class of decision, who can supersede it, and what happens when a legitimate disagreement surfaces - before an agent, or a new hire, runs into that ambiguity at 2am.

06 A practical framework for closing the intent gap

None of the practices below require a particular vendor or platform. They're a synthesis of what the research reviewed in this paper, and the broader engineering literature on architectural decision-making, consistently points to as the difference between organizations that keep intent debt manageable and organizations that let it compound.

1. Capture intent at the moment of decision, not after.

   The highest-fidelity moment to record a decision is the moment it's made, while the rationale and the rejected alternatives are still fresh - not in a retroactive documentation sprint weeks later. Treat the decision record as a byproduct of the discussion itself, not a separate chore competing for time against the next sprint. Executable, intent-first artifacts - behavior-driven specifications that fail visibly when the system drifts from what they describe12 - are one of the more durable ways to do this, because they get exercised automatically rather than relying on someone remembering to re-read a document.

2. Make "current" a first-class question, not an assumption.

   A record that only tells you a decision was made once is close to as unreliable as no record at all, because it can't tell you whether that decision still holds. The harder and more valuable question isn't "can I find a related decision" - most search and retrieval tools can already do that reasonably well. It's "which of several related, possibly conflicting decisions is actually the one still in force." That requires treating decisions as having an explicit lifecycle - proposed, active, superseded, disputed, expired - rather than as a flat, undifferentiated archive.

3. Put a human in the loop on authority, not just on review.

   AI is genuinely useful for proposing that a conversation or a thread contains a decision worth recording, and even for drafting the first version of it. Promoting that proposal to organizational truth - something other people and agents will now build on - should still require a person with real authority over that domain to confirm it. This isn't a trust exercise; it's what keeps the record itself trustworthy enough that people actually rely on it instead of quietly going around it.

4. Check new work against current intent before it ships - and again independently after.

   Passing tests tells you the code does what it does. It doesn't tell you that what it does is still what the organization wants. Checking a plan, or a pull request, against the current, authoritative decision record - not just against the codebase it will merge into - catches a category of problem that testing and code review, on their own, are not designed to catch.

Underneath all four practices is a mindset shift more than a process one: treat understanding - of why a system is the way it is - as a first-class deliverable, the same way working code and test coverage already are. Storey's paper makes a pointed warning here worth repeating: it's tempting to use AI to generate documentation as well as code, producing polished explanations of what a system does without the team ever building genuine understanding of it. That substitutes the appearance of understanding for the real thing, and it makes the resulting cognitive debt harder to detect, not easier - because it looks, from the outside, like the problem has already been solved.1

07 A self-assessment for engineering leaders

The questions below are diagnostic, not rhetorical - they're worth answering honestly, in specifics, rather than in general impressions. A pattern of vague or uncertain answers is itself the signal.

• Can you name the last three significant architectural or process decisions your organization made - where each is written down, and whether it's still current?
• If an engineer, or an AI agent, were about to implement something that contradicts a decision made six months ago, would anyone catch it before it shipped - or only after?
• What share of your team's code review time is now spent reconstructing intent the author - human or AI - never had to establish in the first place?
• If your three most experienced engineers left tomorrow, how much of "why things are the way they are" leaves with them?
• Has anyone on your team already tried to build an internal tool for this - a wiki, an internal search layer, a "second brain"? What did it actually solve, and where did it stop?
• For your most contested, recurring category of decision, do you have a clear, agreed answer to "who actually has the authority to decide this" - or does it get re-litigated every time?
• As AI-assisted coding grows as a share of your codebase, is your review and governance process growing with it - or is it the same process sized for a smaller, slower-moving system?

08 Closing perspective

As AI agents take on more of the "how" of software engineering, the organizations that keep their edge are unlikely to be the ones that ship the largest volume of code. They're more likely to be the ones that keep the clearest, most current record of "why" - and treat maintaining that record with the same discipline they've already learned to apply to code quality. Technical debt taught the industry that shortcuts in the code layer compound if left unmanaged. Intent debt is the same lesson, one layer up, arriving faster than the first one did.