Compounding Decisions

Three months into an AI-assisted rewrite, an engineering lead pulls up a diff and notices something odd: half the codebase validates incoming payment data by throwing on the first bad field, and half retries with a default and logs a warning. Nobody remembers deciding this. Git blame turns up eleven different sessions, four different engineers, and one AI agent, each making the same kind of small call — how strict should this check be — in isolation, weeks apart, each choice locally reasonable and none of them coordinated with any other. There was no meeting where the team picked “fail loud” or “fail soft.” There were eleven small meetings that never happened, and the codebase now behaves as if both decisions were made at once, because in a sense they were.

This is not a story about carelessness. Every one of those eleven calls was defensible on its own terms — a developer or an agent looking at one file, one function, one moment, choosing the locally sensible thing. The problem is what happens to defensible small decisions once enough of them accumulate: they compound. Small decisions compound the same way small debts and small optimizations do, for better or worse, and a codebase is simply the ledger where that compounding gets recorded, whether or not anyone intended to keep the books.

What technical debt actually meant

The oldest and most widely misused name for this phenomenon is technical debt, and it is worth getting Ward Cunningham’s original claim right, because the popular version has drifted from it. In a short 1992 OOPSLA experience report on a portfolio-management system called WyCash, Cunningham wrote: “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.” The debt in that formulation is not messy code, and it is not corner-cutting for speed. Cunningham has said as much directly, in his own later clarification of the metaphor: he is “never in favor of writing code poorly,” only in favor of “writing code to reflect your current understanding of a problem even if that understanding is partial.” The debt is the gap between what the code currently encodes and what the team currently understands about the problem — a gap every real project opens on day one, because nobody understands a problem completely before they start building against it.

A compounding mechanic, not a one-time cost

What made the metaphor stick was not the framing device but the mechanic underneath it: debt compounds. One session’s shortcut is a rounding error. The same kind of shortcut, taken repeatedly — by the same engineer under the same pressure, by different engineers who never compare notes, or, now, by an agent applying the same locally reasonable pattern across dozens of files in an afternoon — stops being a rounding error and becomes the codebase’s actual, if unwritten, architecture. Martin Fowler’s later refinement, the technical debt quadrant, sorts debt by whether it was taken on deliberately or inadvertently, prudently or recklessly. The distinction matters for where to assign blame. It does not change the compounding math: debt taken on carefully and debt taken on carelessly both accrue interest, because interest is a property of the debt’s persistence, not of the intent behind it.

None of this required AI to happen. A 2011 longitudinal case study of a commercial software system found that its architecture drifted from its documented design during the very first phase of implementation — not through one large deviation, but through an accumulation of small ones, some of which the team’s own architectural-conformance tooling failed to surface. Software architecture research has had a name for the accumulated-small-decisions failure mode, architectural drift, distinct from active decay or “erosion” though the literature does not always agree cleanly on the boundary between the two, for at least two decades. What changes with AI-assisted development is not the mechanic. It is the rate.

The rate changed, not the shape

An engineering team choosing how to validate a field, which retry policy to use, or whether a function needs a null check made that kind of decision a handful of times a week, gated by however many people were writing code and however fast they could type. An AI agent makes decisions of that shape continuously, across every file it touches, at whatever pace its harness allows — and that pace has been climbing. GitHub’s 2025 Octoverse data recorded nearly a billion commits pushed to the platform in a single year, describing the trend as a structural shift in the pace of iteration rather than a temporary spike. Scale that by however much of an average session’s output is the agent, not the human, making the call, and the compounding clock that used to tick a few times a week is now ticking dozens of times a session.

Faster compounding cuts both ways, and it is worth resisting the urge to treat AI-driven consistency as automatically good news. A team whose agent applies one well-reasoned validation pattern everywhere gets the benefit of that reasoning applied everywhere, for free, at a speed no manual review process could match — real leverage. A team whose agent applies one subtly wrong pattern everywhere gets exactly the same leverage working against it, and the review processes built for a world where a bad pattern spread at the pace of a person typing now have to catch it at the pace of an agent editing forty files in an afternoon. A 2026 study measuring coding-agent impact on real repositories found the expected shape of that trade-off: measurable velocity gains alongside a corresponding rise in code complexity and static-analysis warning counts — evidence for an emerging speed-versus-maintainability tension rather than a settled result. A separate 2026 practitioner account from inside a firm running agents at scale names the resulting failure directly as architectural drift — agents “making locally sensible but globally inconsistent decisions” — as one of a short list of ways coherence breaks down once agents, not only humans, are making the small calls.

Consistent and inconsistent are both failure modes

It helps to separate two ways this compounding actually goes wrong, because they need different fixes and get conflated constantly. The first is compounding consistently: the same wrong pattern, applied everywhere, by a team or an agent that never questioned it because it was never wrong loudly enough, in any one instance, to get caught. This is classic technical debt at agent speed — the gap between the code and the team’s actual current understanding, propagated uniformly before anyone notices the understanding has moved on. The second is compounding inconsistently: not one wrong pattern everywhere, but several different, individually defensible patterns, none of them wrong on their own, scattered across a codebase because nothing forced the choices to agree with each other.

This Library’s chapter on Conflict Resolution names the sharpest version of that second failure — a decision conflict, where two agents independently reach incompatible design decisions for what was supposed to be the same problem. Decision conflict is not a separate phenomenon from the compounding this chapter describes. It is what compounding looks like when the decisions being compounded were never actually the same decision to begin with, only two agents’ different, reasonable-sounding answers to a question nobody had settled once.

Where to intervene

Donella Meadows’ work on where to intervene in a system offers a useful ranking for why that third row outperforms patching the first two after the fact. Meadows places parameters — the individual numbers and small local choices a system produces — near the bottom of her list of leverage points, and the rules governing a system considerably higher: “power over the rules is real power.” Fixing one wrong validation check, or arbitrating one decision conflict after it has already landed, is an intervention at the parameter level: it corrects an instance without changing what produces the next instance. A written standing decision — Volume III’s Constitution Pattern, the CLAUDE.md or AGENTS.md file every session inherits before it makes its first local call — is an intervention at the level of the rule that generates decisions, not at the level of any single decision. It does not eliminate judgment calls. It shrinks the set of judgment calls a session has to make from scratch, which is exactly where the compounding math starts: a decision made once, in a standing document, does not compound at all, because there is only one instance of it to compound.

Parameters are dead last on my list of powerful interventions. Diddling with the details, arranging the deck chairs on the Titanic.

Donella Meadows, on why fixing individual instances rarely fixes the system producing them

This is not a complete fix, and it is worth being honest about why. A constitution can state that errors fail loudly without settling every place a new kind of error might show up months later — the document raises the floor, it does not anticipate every future decision. And a standing rule is only as good as whether anything downstream actually checks new work against it; an unenforced constitution decays exactly like an unrepaid debt, quietly, in the specs and sessions where nobody happened to reread it. The honest version of “write it down once” is “write it down once, and keep something in the loop that notices when new work has drifted from it,” which is closer to an ongoing review discipline than a one-time document-writing exercise. It is also worth being precise about a nearby term this Library has already coined: Context Debt names something narrower still — a single session’s accumulated stale or irrelevant context — and it is not this chapter’s subject. A session can be free of Context Debt and still contribute one more inconsistent decision to a structure nobody is tracking; the two debts compound on different clocks.

What to check on Monday

1. Pick one repeated pattern in your codebase right now — a validation approach, a retry policy, an error-handling idiom — and find out how many independent decisions produced it. If the answer is more than one, that is compounding, not a plan.
2. Before the next AI-assisted session starts, check whether the standing decision it needs already lives somewhere the session will actually read by default — not somewhere a person has to remember to paste in.
3. Treat a decision conflict caught in review as data, not just a merge to resolve: it means a standing rule was missing, and merging past it without writing that rule down guarantees the next conflict.
4. Do not wait for a pattern to fail loudly to notice it compounded. Sample repeated patterns across sessions periodically, the way logs get sampled — this specific failure mode is defined by never getting noisy enough to trip an alert on its own.