Someone challenges your team right now to produce the reasoning behind last quarter’s biggest architecture call, not the decision itself, the actual reasoning, and I want you to be honest with yourself about how long that would take. For most EA boards, the honest answer is “we’d have to ask around and hope the right person still works here.” That gap is where a familiar meeting keeps happening: someone proposes a change, a senior architect objects that “we already decided against this,” and nobody in the room can produce anything more than a memory of the outcome. So the board burns forty-five minutes re-litigating a call that was already made, usually for the same reasons, and lands in roughly the same place anyway. Multiply that across a portfolio of hundreds of systems and a few years of turnover, and you’ve got a governance function that spends a meaningful chunk of its time re-discovering its own history.
That’s the real cost of skipping Architecture Decision Records. Not “documentation debt” in the abstract, but repeated debate, decisions nobody can defend under audit, and architects who inherit constraints with no idea which ones are load-bearing and which ones are just inertia somebody never bothered to question.
Decision debt is measured, and it’s bigger than most boards want to admit
Technical debt gets treated as a code problem, but a large share of it is decision debt: choices made under real constraints that nobody recorded, so nobody downstream can tell if the constraint still applies. Deloitte’s 2026 Global Technology Leadership Study puts technical debt at 21% to 40% of total IT spend, based on a survey of over 660 technology leaders. Some of that is genuinely obsolete code, sure. But a meaningful slice of it is systems nobody wants to touch because the person who understood the tradeoffs left three reorgs ago, and the only record of “why” is a Slack thread that expired or a design doc nobody can find anymore.
An ADR doesn’t erase that debt. What it does is convert an oral tradition into an artifact: what constraint forced the call, what options were on the table, what got decided, and what the team accepted by deciding it that way. That’s the whole discipline, and it’s less than it sounds like. A few sentences, captured at the moment of the decision, are worth more than a perfect retrospective wiki page written six months later by someone trying to reconstruct it from memory.
AI coding agents just made this a lot more expensive to skip
I used to think this was mostly an audit argument, something you’d trot out for a compliance review and otherwise let slide. It isn’t anymore. Sonar’s 2026 State of Code Developer Survey found that 96% of developers don’t fully trust that AI-generated code is functionally correct, yet only 48% say they always verify it before committing. 88% report at least one negative impact from AI on their technical debt, most commonly code that looks correct but isn’t reliable.
An AI coding agent has no access to the reasoning behind a constraint unless that reasoning is written down somewhere it can actually read. It doesn’t know a service was deliberately kept synchronous because the downstream system can’t handle async retries, or that a “redundant” data store exists because a prior outage taught the team not to trust a single source of truth. Left to its own judgment, an agent optimizing for clean code will refactor that constraint away, confidently, no hesitation, and the review that’s supposed to catch it depends entirely on a human remembering why it was there in the first place. ADRs are the mechanism that survives that gap. They’re the one artifact that puts the “why” somewhere a reviewer, or an agent, can find before the second one does something expensive.
The pushback I hear most is that ADRs add ceremony to already slow delivery, and I get why people say it. In practice, the cost stays low if you treat the record as the exit condition of a decision, not a separate documentation task bolted on afterward. The same discipline I’ve written about for Architecture Review Board exceptions, every exception time-boxed, every one attributable to a name, applies here directly: no decision leaves the room without a record, and no record ships without an owner and a review date. That’s not extra process. That’s the process actually being done, which is a different thing than the process existing on paper.
Where this breaks down is when the record lives somewhere nobody checks, a wiki page, a design doc buried in a shared drive, a comment on a ticket that gets closed and forgotten along with it. I run ADRs through LeanIX as the system of record specifically so decisions stay attached to the components and capabilities they constrain, instead of floating in a document store disconnected from the architecture itself. When a new architect, human or otherwise, looks at a system, the decision history ought to be reachable from the artifact, not from institutional memory that walks out the door with whoever holds it.
Set the rule now and the payoff shows up fast: no significant architecture decision is final until it’s recorded, where “significant” means anything that would cost real time to re-litigate or real risk to get wrong twice. Do that consistently for one quarter and your next portfolio review looks different. Fewer repeated debates, faster onboarding for anyone new to a system, an actual paper trail the next time an auditor or an AI agent asks “why is it built this way.” That’s a governance control with a low fixed cost and a high avoided cost. I’d treat it as one.