Coherence debt: why a healthy system gets expensive to change

The request fitted on one line: add a third loyalty tier to checkout. Eighteen months earlier a change like that took two days. This time the estimate came back at three weeks, and nobody in the room could say why.

Nothing was broken. There was no incident and no failing test, and coverage had gone up. When the engineer went looking, the three weeks had a shape. The order total was computed in three places: checkout worked it out to show the customer, the receipt service recalculated it for the confirmation, and the revenue report recalculated it again, slightly differently, for finance. The three didn't even agree on what an order was. One carried line_items and a total, another items and a total_cents, and the report folded the discount into a per-line adjustment. Each had been a reasonable choice when it was made. Together they turned one loyalty tier into the same change made three times, plus a job nobody had budgeted for: checking afterwards that the three still reconciled.

The story is a composite of conditions I have seen in several long-lived systems, and its code exists as a runnable fixture. The pattern in it is common enough that most engineering leaders will recognise it.

Naming what built up

I call this coherence debt: the structural cost carried by software that still works and is steadily harder to understand, coordinate and change. Individually safe changes accumulate into it. A pull request passes review, tests and deployment and still leaves behind one more local workaround, a second way of expressing the same rule, or a dependency nobody meant to create.

The name has earlier uses. Mikkilineni and Kelly used it in 2025 and 2026 for structural fragility in AI architectures and for the governance of operational commitments, and Mohammadi and colleagues used it in 2026 for the facts an edit needs that an agent doesn't have in front of it. I use it in a narrower sense: the condition standing in the source, which can be measured from the source.

It differs from the technical-debt backlog most teams already keep. A backlog lists debt someone has already seen: the module everyone agrees is bad, the migration that keeps slipping. Coherence debt is the part nobody has seen yet, because none of the instruments show it. It never reaches the backlog, so a bigger backlog or more diligence won't pay it down.

Why the gates can't see it

Most of what we check in a delivery pipeline is behaviour. Does the code compile, do the tests pass, does the deployment succeed, did the error rate move. Coherence debt arrives without changing any of those answers. That's what makes it expensive: by the time it shows up as a three-week estimate, it has been accumulating for a year through changes that were each, on their own terms, correct.

You can watch it happen at small scale. The coherence ratchet, an open-source tool I built to study the problem, ships with a demo: a billing subsystem that starts with one retry helper and one paginator. Three features arrive, each written the way a busy author or a coding agent would write it, and each quietly re-implements retry logic instead of reusing the helper that's already there.

Every commit passes. The duplicate ratio goes from zero to 0.75 in three changes. A consolidation pass that reuses the existing helpers brings it back to zero, which is the useful part of the demo: the debt is repayable when someone can see it and decides to.

Why AI makes it arrive faster

AI-assisted development makes code cheaper to produce. It does not make a long-lived system cheaper to change, and the gap between those two is where coherence debt grows.

A coding agent writes a sensible local solution to the problem in front of it. When the helper it should reuse sits outside what it can read, it writes another one. When the second place that computes a total isn't in its context, it changes the first and stops. I measured that second case directly, and the result is stark: with the second site out of reach, two models from different vendors got the change right in none of thirty trials each. Every one of those changes was correct where anyone would look.

Humans do the same thing, more slowly. What changes with agents is the rate: more changes arrive, and a smaller share of them gets read closely by someone who knows the rest of the system. The consolidating work that used to happen in passing, when an engineer noticed a near-duplicate and merged it, needs someone in the code long enough to notice.

What a team can do about it now

The aim isn't zero divergence. Plenty of duplication is harmless, and some of it is deliberate. The aim is to keep coherence where it matters, at the contracts and shared shapes that other teams depend on, and to leave each team free inside its own area. I put it as coherence at the contract, freedom within the cell.

Getting there takes four habits, and none of them needs a new role.

Measure what a change does to the structure, alongside whether it works. Dependency cycles, coupling between modules and new duplicate clusters can all be read from the code at each commit, and a reviewer can see them next to the test results.

Keep what the code contains apart from what the team has agreed. A pattern repeated fifty times is a candidate, not a rule. Only the structure an owner has explicitly ratified, with a name and a date against it, should be allowed to instruct a coding agent.

Hold a line from where you are today. The big structural cleanup rarely survives the calendar. A ratchet, baselined on the current state, fails a build only when a change makes the structure worse, so a team can stop the bleeding without first earning the right through a rewrite. Teams already do this with test coverage.

Make accepted deterioration a decision. Sometimes the right call is to ship the worse structure. When that happens, record who owns it, what would trigger repayment, and when it will be reviewed. Rate the exposure on a few plain dimensions: how often the area changes, how many teams it spans, how critical it is, how easy it is to find, and how far a wrong result would travel. A debt with an owner and a review date is a decision. One without them is drift.

Where the evidence stops

The decisive measurement doesn't exist yet. Nobody has watched a large system written mostly by agents age for five years, because none is old enough. What does exist is the human baseline, and it is not reassuring: in long-lived, carefully maintained open-source libraries, the architecture tangled for over a decade while the usual quality metric pointed the other way.

That gap between the two is the argument for instrumenting now. By the time the long-run curve is measured, the systems it describes will already be carrying the debt.