Chapter 4 — The Debt Ledger

"A statistically significant, large, but transient increase in project-level development velocity… a substantial and persistent increase in static analysis warnings and code complexity… major factors driving long-term velocity slowdown."

— He, Miller, Agarwal, Kästner, Vasilescu, MSR '26, arXiv 2511.04427 [A]

4.1 The hardest chapter to write honestly

Chapter 3 ended with an organisation whose merge and revert rates did not budge across twelve months of near-total AI adoption. If quality had collapsed, that is where it would have shown.

So this chapter has an obligation. The literature on AI and code quality is the part of this field most contaminated by motivated reasoning, and a book that has spent three chapters demanding verified figures cannot now reach for the alarming ones.

Begin with the reason the question is hard, because it is not a shortage of data.

Debt is a counterfactual. To claim that a codebase has accumulated debt is to claim that a different codebase — the one that would have existed under different practice — would have been cheaper to change. That codebase does not exist. It cannot be inspected. Every debt measurement is therefore a proxy standing in for an unobservable comparison, and the proxies are all contestable.

Consider what "high complexity" actually asserts. Cyclomatic complexity counts branches. A function with many branches may be badly factored, or it may be correctly handling a domain with many cases. A static-analysis warning may flag a real defect or a false positive that the team has correctly learned to ignore. Duplication may be copy-paste debt or it may be two things that resemble each other today and will diverge tomorrow, which is exactly when premature extraction becomes the more expensive mistake.

None of these proxies is worthless. All of them are arguable. And this is the structural fact that governs the whole chapter:

Taleb's observation about silent evidence is exactly on point, and unusually literal here. The refactoring that did not happen leaves no entry in the version history. There is no commit titled "did not extract the duplicated validation logic." The log records what was done; the ledger's debit column is written in absences.

I raise this before any evidence because it predicts the shape of the literature. Where one side of a ledger is cheap to measure and the other is expensive, the cheap side will be measured more, cited more, and believed more — regardless of which is larger. So expect the debt literature to be thinner, later, more contested, and more vendor-produced than the productivity literature. It is.

4.2 What is actually measured

Four signals, in descending order of evidential strength.

Complexity and static-analysis warnings. The strongest design in the field, and the epigraph of this chapter. He, Miller, Agarwal, Kästner, and Vasilescu ran a difference-in-differences analysis comparing GitHub projects that adopted Cursor against a matched control group of similar non-adopting projects, published at MSR '26 [A]. Difference-in-differences with matched controls is the right tool for exactly this question: it estimates what happened to adopters relative to what would plausibly have happened otherwise. It is the closest anyone has come to constructing the missing counterfactual.

Their finding has three parts, and the third is the one usually dropped:

1. Velocity increased — "statistically significant, large, but transient."
2. Static-analysis warnings and code complexity increased — "substantial and persistent."
3. Those increases were "major factors driving long-term velocity slowdown."

The third clause converts a correlation into a mechanism. It is not merely that debt accumulated alongside a fading speed-up. The accumulated debt is identified as a driver of the fade.

A caveat I am obliged to state: the specific percentages circulating in secondary coverage of this paper — figures around +28% lines added, +30% warnings, +41% complexity, and a repository count of 806 — are not verified here. I retrieved the abstract and the venue; the effect sizes live in the full paper. This book does not print unverified numbers, so the argument above rests on the authors' own characterisations, which are strong enough without them: large but transient against substantial and persistent.

Duplication and the disappearance of refactoring. GitClear's analysis of 211 million changed lines from 2020 to 2024 reports a set of figures that fit together into a single picture [C] 🟡 — vendor research, secondary retrieval, graded accordingly:

And the crossing point: 2024 was the first year on record in which within-commit copy/paste exceeded moved code.

Of these, "moved code" is the one to attend to, because it is the least contestable. Moved code is the mechanical signature of refactoring — lines that changed location rather than content. It fell by roughly six-tenths of its 2021 share. Whatever one thinks of complexity metrics, a codebase in which the proportion of change that is restructuring has dropped by more than half is a codebase where restructuring is happening less. That is close to a direct observation rather than a proxy.

Delivery instability. DORA's 2025 report, ~5,000 respondents, found that AI improved delivery throughput — a reversal from its own 2024 finding — while increasing delivery instability [C]. Its framing of AI as an amplifier that magnifies existing organisational strength and dysfunction is the best-validated organisational claim available in this field. A 2024 DORA figure associating a 25% increase in AI adoption with a 7.2% decline in delivery stability circulates widely 🟡 and should be verified before print.

Defect proxies at scale. The Faros telemetry across 10,000+ developers reports +9% bug counts alongside its velocity figures [D]. Vendor data, weakest grade, and a 9% increase against a 98% increase in merged pull requests is arguably a sublinear defect rate — which is a point for the optimists, and one they rarely make.

4.3 The counter-evidence

Now the other side, and it deserves the same care.

Short-horizon quality proxies did not move in the best-documented enterprise case. In the twelve-month "2×" mandate study of 802 developers, merge rate and revert rate held steady while AI-authored pull requests rose to about 90% of the total and automated review overtook human review [B]. On the measures available, code shipped under machine review without visible penalty.

A controlled experiment found no maintainability penalty. The same enterprise study cites a controlled experiment finding no maintainability penalty when later developers evolve AI-co-developed code — and, in fact, confirming a speed-up when they did so 🔴 (cited within, primary not retrieved). If that result holds and generalises, it attacks the debt thesis at its foundation, because the entire concern is precisely that future changes become more expensive.

The strongest debt evidence is observational. He et al.'s difference-in-differences is a good design, but it is applied to public repositories with self-selected tool adoption. Projects that adopt Cursor may differ from matched controls in ways matching does not capture — appetite for velocity, team composition, growth stage. The authors are careful; the design is still not a randomised trial.

GitClear is a vendor. Its business is code-change analytics. This does not make its figures wrong — the moved-code trend in particular is a mechanical measurement that would be difficult to fake and easy to falsify — but it does mean the framing is chosen by an interested party, and the report editions disagree with each other on churn in ways I documented in sources.md.

And the direction is genuinely unsettled. I cannot honestly write a chapter that says otherwise. What we have is: one good quasi-experimental design finding persistent complexity growth that drives later slowdown; one large vendor dataset finding refactoring collapsing; one survey finding instability rising; one within-developer panel finding fast quality proxies flat; and one controlled experiment reportedly finding no maintainability cost at all.

4.4 The measurement window, again

Most of that apparent conflict dissolves the way Chapter 3's did.

Reverts detect acute failure — something broke and someone noticed within days. Complexity accretion is chronic. A codebase does not revert because a function acquired three extra branches; it becomes, six quarters later, a codebase where every change takes longer, and by then no individual change is blameable.

This gives the honest formulation of what we know:

On acute, short-horizon quality proxies, agent-authored code under automated review shows no measured penalty. On chronic, structural proxies over multi-year windows, the one quasi-experimental study available finds substantial and persistent degradation that it identifies as driving later slowdown. Nobody has measured both, on the same codebase, over a window long enough to settle it.

That is a less satisfying sentence than "AI is destroying your codebase." It is also the true one, and Chapter 27 lists the longitudinal study that would resolve it as an open problem.

4.5 The mechanism

Here is where the chapter stops reporting and starts arguing, and the argument does not depend on any of the contested figures.

Ask why generated code would accumulate structural debt even if every individual change were correct.

Not incorrect. Correct. Every diff passes review, every test goes green, every requirement is satisfied. Does structure still degrade? I think it does, necessarily, and the reason is a cost gradient.

Consider a routine situation: a change needs behaviour that already exists somewhere, slightly differently. There are two correct implementations.

Option A — duplicate and modify. Copy the existing logic, adjust it, use it locally. Correct. Touches one file. Breaks nothing.

Option B — extract and reuse. Pull the shared behaviour into a common abstraction, adapt both call sites. Also correct. Touches several files. Risks every existing caller.

Now price both options for each kind of author.

Three things are doing work here.

The agent's cost of Option B is genuinely higher than a human's, for structural reasons. Extraction requires knowing every call site. That is a repository-wide question answered from partial observation — precisely the hardest thing for an operator working through a bounded context window. Chapter 9's entire argument for graph engineering is that this question is currently answered badly.

The agent's cost of Option A is genuinely lower. No cross-file reasoning, no risk to existing callers, no need to hold the whole dependency structure in view.

And the counter-force is absent. A human maintainer duplicating logic for the third time experiences something. Call it taste, or professional discomfort, or — as the research literature on what agents lack puts it — aesthetic disgust. It is not a rational calculation. It is a felt cost that opposes the cheap option, and it is the mechanism by which human codebases resisted entropy for fifty years. An agent has no such feeling, no reputation among colleagues who will read this code, and no expectation of being the one who maintains it.

So the prediction, from incentives alone:

Where agents author most changes, duplication rises and restructuring falls — not because the agents are bad at their jobs, but because they are doing their jobs correctly under a cost gradient that points toward duplication.

Compare that prediction to §4.2's least-contestable measurement: moved code down from 24.8% to 9.5%, copy/paste up from 8.4% to 12.3%, and 2024 the first year copy/paste exceeded refactoring. The prediction and the signature match.

I want to be precise about what this does and does not establish. It does not prove the GitClear numbers are right. It shows that the numbers are what you would expect from an incentive analysis conducted independently of them — which is the sort of corroboration that matters more than another dataset, because a mechanism that predicts a measurement is harder to dismiss than two measurements that agree.

4.6 The homeostat we removed

There is a deeper version of this, and it is the chapter's real contribution.

Complexity, under purely additive change, is monotone. Add a branch, complexity rises. Add a special case, complexity rises. Nothing in the ordinary business of satisfying requirements ever removes a branch. If a system only ever receives additive change, its complexity grows without bound, and this is true of human-written code as well.

Human codebases did not grow without bound. Why not?

Because they contained a negative feedback loop that nobody designed and nobody measured. Periodically, a maintainer's discomfort exceeded their tolerance and they cleaned something up. Not because a ticket demanded it. Because it had become unpleasant. That is a homeostat: a mechanism that senses a deviation and acts to reduce it, keeping a variable within bounds without any external controller.

This reframing matters because it changes what the remedy is.

If you believe agents produce debt, the remedy is to make them produce less of it — better prompts, stricter rules, more review. Reasonable, and mostly ineffective, because the cost gradient in Figure 4.3 does not care about instructions.

If you believe delegation removed a homeostat, the remedy is to install a replacement, and the replacement must have the properties the original had: it must sense the deviation without being asked, and it must act without waiting for a ticket. Which is to say it must be a sensor with a standing mandate — the exact object Chapter 8 calls a continuous drift sensor and Chapter 12 places in the outer loop as the Observe phase.

And the best engineering organisations have already worked this out, arriving from experience rather than theory. OpenAI's published account of its own harness reportedly includes recurring "garbage collection" scans for drift, with agents proposing the fixes [D] 🔴. Thoughtworks describes a "janitor army" addressing architecture drift with a mix of computational and inferential sensors [D] 🟡. Neither is a rule telling an agent to write cleaner code. Both are standing processes that detect accumulation and act on it — homeostats, deliberately built, because the implicit one is gone.

There is a pleasing symmetry here that I do not think is coincidental. The thing that regulated code structure for fifty years was a feeling. Feelings do not survive delegation. So the feeling has to be replaced by an instrument, and that is what Part II is: the systematic replacement of tacit human regulation with explicit engineered regulation. Chapter 17 makes it one of the ten shifts — tacit knowledge to externalised knowledge — and this is the sharpest example of it. What stays in your head is invisible to an agent. What stayed in your gut is invisible too, and it was doing more work than anyone credited.

4.7 The shape of the bet

One structural observation, and it is the reason this chapter sits in Part I rather than being an appendix.

Look at the magnitudes on each side of the ledger, and notice that they are not the same kind of quantity.

The velocity gains are bounded. Chapter 3's best organisational figure was 2.09× per-capita pull requests, and Amdahl's law caps the cycle-time improvement well below the generation speed-up. Even the most optimistic honest estimates cluster, in the enterprise study's own summary of the field, on a gain of at most roughly 40% in credible field settings. Good, real, and finite.

The structural costs are unbounded in the tail. Most of the distribution is unremarkable: slightly slower changes, slightly more warnings, a gradual tax. But the tail contains outcomes with no natural ceiling — the service nobody will touch, the migration that gets abandoned, the rewrite. These are rare and they are not small.

Taleb's term for bounded-upside, open-tail exposure is fragility, and his argument is not that fragile positions are always wrong. It is that they are routinely held unknowingly, because the small steady gains are visible in every reporting period and the tail is absent from all of them until it isn't. The turkey of Chapter 3 was in the same position.

Two consequences, and they are the practical output of this chapter.

Guardrail metrics, not vanity metrics. Complexity and duplication trends belong on the dashboard not because they are goals but because they are the only early warning available for a cost that arrives late. Chapter 14 classifies them explicitly as health guardrails — you do not optimise them, you watch them for the shape of the curve, and a guardrail with no threshold and no owner is decoration.

This is why a lifecycle rather than a tool. A tool cannot fix a missing feedback loop, because the loop is not inside the tool. It runs through the repository, the review process, the metrics, and the question of who is accountable when structural quality degrades and no individual change was at fault. That is an organisational apparatus. Which is the definition of a lifecycle, and the subject of the remaining twenty-three chapters.

4.8 What this licenses

Licensed. One quasi-experimental study with matched controls finds velocity gains transient and complexity and warning increases substantial and persistent, and identifies the latter as driving the former's decay. [A], primary abstract verified, effect sizes not.

Licensed. Refactoring, measured mechanically as moved code, has fallen sharply as a share of changed lines, and duplication has risen. [C] vendor data, but the least-contestable proxy in the set.

Licensed. AI adoption is associated with increased delivery instability alongside increased throughput. [C] DORA, ~5,000 respondents.

Licensed, and this is the load-bearing one. The cost gradient facing an agent points toward duplication more steeply than the one facing a human maintainer, and the counter-force that regulated human codebases — felt discomfort — does not survive delegation. This is an argument from mechanism, not a measurement, and it is falsifiable: it predicts that codebases with strong computational structure sensors should not show the duplication signature. Nobody has tested that. Chapter 10 flags it as the gap.

Not licensed. That agent-assisted codebases are measurably worse today on acute quality measures. The best enterprise evidence says merge and revert rates held steady, and a controlled experiment reportedly found no maintainability penalty. Claiming otherwise would require ignoring the strongest short-horizon data available.

Not licensed. The specific percentages you have seen quoted. Not the +30% warnings, not the +41% complexity, not the churn figure that had drifted before I checked it. The direction is supportable. The decimals are not, and a book with decimals in it is a book that will be wrong in print.

The asymmetry that survives all of this is not "AI makes code worse." It is narrower, better evidenced, and more actionable:

The benefits of delegation are prompt, countable, and defended by whoever bought the tool. The costs are deferred, contestable, and owned by nobody. Systems with that structure do not need malice or incompetence to degrade — they only need time.