The Code Your AI Wants to Delete Is Load-Bearing

AI Technical Debt

AI technical debt is what you get when an AI assistant refactors code it has never seen and deletes anything whose purpose isn’t obvious, including the guards that quiet edge-case bugs. The clean diff hides the lost context: speed today, a production failure next quarter. The fix isn’t banning AI. It’s knowing which old code is a load-bearing fence and which is just dead cruft.

It usually goes like this. A developer points Cursor or Copilot at a gnarly legacy file and asks it to clean things up. The model does what it’s good at and collapses a nest of conditionals into something half the length and twice as readable. Tests pass locally. The diff looks clean. It ships. A week later, a quiet edge case that one of those “redundant” branches used to catch shows up in production, on a client site nobody has opened in years.

There’s a hundred-year-old name for the mistake. Chesterton’s Fence goes like this: you find a fence across a road with no obvious purpose. The reckless reformer says, “I don’t see the use of this, clear it away.” The wiser one answers: go find out why it’s there first, then you may remove it. Every codebase older than its current team is full of fences. The validation that looks paranoid. The handler for a case that “can’t happen.” The query that dodges an obvious index for reasons lost to time. We are now handing those codebases to tools that are fast, confident, and carry zero memory of why anything was built.

The clean diff is the trap, not the safeguard

The standard advice sounds responsible: let AI move fast, then review the diff. Clean change, green tests, merge. The problem is that a diff shows you what changed, not what the change knew. A deleted block leaves no trace of the bug it was preventing. The tests pass because nobody ever wrote one for that edge case, which is precisely why there was a guard sitting there instead of a test. So you get a clean diff, a green build, and a landmine reburied for next quarter. The review ritual feels like diligence while it quietly rubber-stamps the deletion of context.

None of this is an argument against AI in the workflow. We run Claude Code, Copilot, and Cursor across React and PHP every day, and the speed is real. It’s an argument against confusing velocity with progress when you’re standing in code you didn’t write. The discipline of writing clean code with AI starts with knowing when not to let it touch something.

Why this bites agencies hardest

If you run an offshore or white-label shop, the exposure is sharper than it is for a product team that has lived on one codebase for years.

  • You inherit. Most of what we touch was built by someone else, often years ago, for a client whose original developer is long gone. The fence and the person who built it both left before we arrived.
  • Juniors lean on it hardest. A mid-level developer using AI to cover gaps is making the right move, until the model suggests something elegant and wrong and they don’t yet have the scars to tell the difference. In a pull request, elegant-and-correct and elegant-and-wrong look identical.
  • The data risk is its own category. Pasting a client’s source, an API key, or a slice of proprietary logic into a public model is a one-keystroke NDA breach. That isn’t a code-quality problem. It’s a get-fired problem.

This is the same pattern we flagged in hidden technical debt: the costliest problems are the ones nobody can see in a quick review.

Not every old line is a fence

Here’s where the lazy reading of Chesterton, “never delete old code,” is as wrong as the reckless one. Plenty of old code is genuinely dead: commented-out blocks, an abandoned feature flag, a function nothing calls anymore. That is not a fence. It’s litter, and AI is excellent at hauling it away. Let it. The whole skill is telling the two apart.

Signal It’s a fence (keep, investigate) It’s litter (safe to cut)
Purpose Not obvious, but something still depends on it None; clearly superseded or dead
History Added deliberately, often right after a bug or incident Left behind by a past refactor or a removed feature
Coverage Guards a case no test actually exercises Nothing references or runs it
Right move Run git blame, read the ticket, then decide Delete it and move on

When in doubt, treat it as a fence. The cost of investigating a line that turns out to be litter is two minutes. The cost of deleting a fence is a production incident on a client’s site.

Make the human own the commit

The rule we land on isn’t “trust the AI” or “distrust the AI.” It’s a short set of habits that cost time on purpose. The human owns the commit: “the AI wrote it” explains nothing, and if you push code, you defend every line in review. The AI builds inside your guardrails, not its own: state the stack versions, conventions, and component structure explicitly, every time, or it will invent a perfectly reasonable pattern that contradicts the three already in the project. And before you let a tool rewrite or remove anything, you find out why it’s there. We’ve written up the full workflow as Controlled AI Coding, but the pre-flight before touching existing code fits on one card:

  • Run git blame on the block and read the commit message
  • Check the original issue or ticket for the why, not just the what
  • Confirm whether a guard is covering an edge case the diff would silently remove
  • Make sure the change matches existing stack versions and conventions
  • Verify no client source, credentials, or keys are going into the prompt

This is not about slowing everyone down. It’s about spending two minutes on the handful of lines that are actually fences, and letting AI fly on everything else. The same caution applies when the speed feels intoxicating; the high of vibe coding is exactly when fences get cleared without anyone noticing.

The one thing AI can’t bring to the review

AI doesn’t tear down fences because it’s reckless. It tears them down because it has no memory and no stake. It was never paged at 2 a.m. by the bug that guard was written to stop, so it feels no caution. Which means the caution is now entirely ours.

The fences in a codebase you inherited are a map of everything the last team learned the hard way and forgot to write down. AI can’t read that map.

Reading that map, and knowing which fences to keep, is quietly becoming one of the more valuable things a developer can do, right at the moment the tools are most eager to skip it. Treat it the way Martin Fowler frames technical debt: something you take on deliberately and pay down on purpose, not something an assistant runs up for you while you watch the diff scroll past.

Want code refactored with the history left intact?

We’ve maintained other people’s codebases since 2002. We know a load-bearing fence when we see one, and we use AI without letting it quietly rewrite your architecture.

Get senior developers on your build

Visited 2 times, 2 visit(s) today

Related Posts

Search

 

Popular Posts

@macronimous Copyright © 2026.
Visit Main Site