I ran a one-liner over a production API I work on. The last six months: 468 commits. 227 of them are fix:. Nine are refactor:. Twenty-five patches shipped for every structural improvement, in a codebase that several teams touch every day.

The uncomfortable detail isn’t the ratio. It’s that the last seven fix commits in the log all orbit the same problem: one core relationship in the domain model, think how an order links to its fulfilment records, that is modeled subtly wrong. Every one of those PRs patches a different symptom of the same wrong shape. Each was small, reviewable, tested, and approved within hours. The model itself has never had a ticket.

The Quilt Predates AI

None of this is an AI phenomenon, and it would be dishonest to frame it as one. The patchwork quilt is what modern delivery culture optimizes for:

  • Ticket-shaped work. Work arrives as symptoms (“owing quantity doubles when X”), and the definition of done is the symptom gone. The root cause is out of scope by construction.
  • Small-PR orthodoxy. We (correctly) learned that 2,000-line PRs don’t get reviewed, so we cap the diff. But a structural fix doesn’t fit in 40 lines, so structural fixes stop being proposable.
  • Nobody owns the model. Every engineer owns their patch. The wrongness that generates the patches belongs to no one, so it persists by default.

Under those incentives, papering isn’t laziness. It was, for a long time, the economically rational move: a root-cause fix meant weeks of risky work that delivered zero visible features, and the patch meant your ticket closed today.

Then AI Killed the Excuse

That economic defense is the part that just died. An agent can hold the whole tangle in context, propose the corrected model, mechanically migrate every call site, and regenerate the test coverage, the expensive 80% of a structural refactor, in an afternoon. The cost argument for papering has never been weaker.

And yet the ratio didn’t move. Mine has only widened since agents joined the team. The reason is obvious once you say it out loud: AI made the patch cheaper too. If the patch was already the path of least resistance, a tool that accelerates all paths accelerates the patch most, because the patch needs no permission. So we paper faster than ever, back ourselves into corners faster than ever, and the corners arrive with better test coverage.

Which exposes what the constraint actually was. It was never cost. It was appetite: no ticket, no owner, no reviewer who wants the big diff. AI is the control variable that proved it. Remove cost from the equation and the papering continues, so cost was never the binding term.

Leave the campground cleaner than you found it.

— Robert C. Martin, Clean Code

I’ve written before about how agents don’t refactor unprompted, they add, they rarely subtract. This is the organizational mirror of that post: the humans don’t ask, either. The Boy Scout Rule failed to survive contact with delivery pressure back when tidying was expensive. Now tidying is cheap and we still don’t ask, which tells you the rule didn’t fail on economics. It failed on incentives, and incentives don’t fix themselves.

What “Just Refactor It” Gets Wrong

The balanced version of this argument has to concede real ground:

  • Small PRs are small for good reasons. Blast radius, reviewability, bisectability. In regulated or high-stakes domains, a sweeping model change carries risk a patch genuinely doesn’t.
  • The rewrite graveyard is real. “Fix the root cause” has historically been the battle cry of six-month rewrites that shipped nothing. Skepticism of big structural work is earned, not irrational.
  • An AI refactor you don’t understand trades one debt for another. If an agent restructures the domain model and no human on the team could re-derive why, you’ve swapped patch debt for comprehension debt. That’s a worse trade in the long run.
The fifth-fix tripwire

The honest heuristic isn’t “always fix the root cause”, it’s a tripwire: when you’re writing the Nth fix against the same underlying shape (pick N, mine is now three), the next unit of work is a root-cause spike, not another patch. Count your fixes per root cause. The log already knows; nobody usually asks it.

Boy Scout at Agent Scale

What I’m actually changing after staring at that 25:1 ratio:

  • Make the agent write the proposal, not just the patch. Every time I ship a symptom fix, I have the agent draft the root-cause fix as a design note in the same session: corrected model, migration path, blast radius. Cost: minutes. It turns “we should fix this properly someday” from a vibe into a reviewable artifact that can be scheduled.
  • Count fixes per root cause, not fixes per module. git log --grep clusters the paper. Seven fixes orbiting one relationship is an architecture ticket wearing seven disguises.
  • Spend the savings on structure. The patch that used to take a day takes an hour with an agent. The boy scout move at agent scale is spending part of the difference on one structural improvement per visit, sized to still be reviewable, not banking all of it as throughput.
  • Give the model an owner. Not a rewrite mandate, a name attached to the question “why does this keep generating fixes?” Unowned wrongness is permanent wrongness.

The tools that could unwind the quilt are already at our fingertips. The papering continues not because the fix is expensive but because nobody’s job is to ask for it, and an agent will never volunteer what you never prompt. First principles cuts both ways here: AI didn’t break your codebase’s architecture, and it won’t fix it as a side effect. It just made both outcomes cheap enough that, for the first time, the choice between them is purely yours.

Related Posts