Your Code Was Never Pristine

I keep seeing the same lament, and it’s almost always from the most senior person in the room. An architect, a staff engineer, someone with twenty years in: AI is flooding the codebase with slop, they say, look what we’ve lost. The thing underneath is always the same assumption. That before the agents showed up, the code was clean. Considered. Just so.

It wasn’t. It was never just so. And the people insisting otherwise wrote some of the messiest systems still running in production.

The cathedral never existed

Start with the word itself. “Technical debt” was coined by Ward Cunningham in 1992, at the height of the supposedly pristine pre-AI era. And the thing everyone forgets is what he actually meant. He spelled it out in 2009: debt was never about writing code poorly. He was “never in favor of writing code poorly.” It was about shipping code that reflects your current, partial understanding of a problem, and paying interest until your understanding catches up. Even careful, well-intentioned, beautifully-formatted code goes into debt, because you don’t understand the domain yet when you write it. Martin Fowler put a number on the inevitability: it can take a year on a project before you know what the design should have been.

So the cleanest team that ever lived was already in debt the day it shipped. Pristine was never on the menu.

Then look at what the world actually runs on. Roughly 70 to 80 percent of global business transactions still touch COBOL: 220 billion lines of it, maintained by people who are now, on average, 55 years old. The US federal government spends 74 of every 95 IT dollars not building anything new but keeping legacy systems alive. That is the real inheritance of decades of human craftsmanship. Not a cathedral. A vast, load-bearing, barely-understood pile that we are too frightened to touch. The mess isn’t the AI era’s invention. The mess is the baseline condition of the entire industry, and always has been.

Beauty was always displacement

Here’s the harder thing to say to the person mourning clean code: the obsession was never doing what they thought it was doing.

Code is a liquid. You spray it through hoses. You don’t freaking look at it.

— Steve Yegge

Yegge is being provocative on purpose, but the pedigree of the idea is old and impeccable. Greg Brockman, years before anyone vibe-coded anything: “code is a liability, not an asset.” Michael Feathers, in the canonical text on legacy code: without tests, “it doesn’t matter how pretty or object-oriented or well-encapsulated it is,” it’s bad code. The Agile Manifesto said it in plain English in 2001, that working software is the primary measure of progress, and a generation of engineers nodded along and then went straight back to arguing about file structure.

We even have proof that “beautiful” and “good” can be opposites. When Casey Muratori benchmarked textbook Clean Code against a blunt switch statement, the pretty version ran more than an order of magnitude slower, enough that Uncle Bob himself conceded the criticism was fair. Elegance is not a synonym for correct, or fast, or secure. It never was. It was a proxy we reached for because it was the thing we could see.

What actually matters

Strip the aesthetics and the list of things that matter is short, boring, and unchanged:

• It works. It does the thing, including the edge cases nobody enjoys.
• It performs. Fast enough that the user never feels it.
• It’s secure. It doesn’t hand the keys to anyone who asks.
• It scales. It survives ten times the load you have today.

And the load-bearing word under all four: verified. You don’t get to claim any of them. You have to confirm them. That is the job. It always was. The prettiness was a story we told ourselves about the job.

A prompt away from the form, not the proof

Here’s where I have to keep myself honest, because there’s a lazy version of this argument and I’ve written against it. The lazy version says code is disposable now, you’re a prompt away from refactoring to a state machine, so who cares.

You are a prompt away from the form. That part is real, and it’s exactly why fetishising the shape is pointless: I can restructure, rename, and re-architect on demand. But the form was never the expensive part. Cleanup and correction were always where the money went, and agents add far more readily than they subtract. What you cannot prompt away is the verification that the new shape still does all four things above.

And the data on what happens when people skip that step is brutal:

• Veracode tested AI-generated code across 100-plus models: 45 percent failed security tests. For Java it was 72 percent. “Secure” is not a property the prompt hands you for free.
• DORA’s 2024 research tied AI adoption to a 7.2 percent drop in delivery stability, even as it raised throughput. Faster, and more broken.
• METR ran a controlled trial with experienced developers on code they already knew: AI made them 19 percent slower, while they reported feeling 20 percent faster.

The artifact got cheap. Confirming the artifact’s behaviour did not. If anything it got more expensive, because now there is more of it, arriving faster, written by something that doesn’t understand what it wrote.

The polisher and the disposer make the same mistake

This is the part worth sitting with. The senior engineer lovingly refactoring for elegance and the vibe-coder regenerating a whole module on a whim look like opposites. They are the same person. Both are fixated on the artifact, one worshipping it and one discarding it, and neither is doing the single thing that counts, which is proving the behaviour.

This is also why Martin Fowler’s “the cost of high internal quality is negative” isn’t a rebuttal to any of this. It’s the correction. Fowler isn’t defending beauty, he’s defending legibility, because legible code is cheaper to change and cheaper to verify. Keep the code clean enough to reason about, not because clean is pretty, but because clean is checkable. That is the only definition of quality that ever paid its way.

Mourn the right thing

The seniors aren’t wrong that something is being lost in the rush. They’ve just put the wrong name on it. What’s vanishing isn’t beautiful code. That was always rarer than the nostalgia claims, and it was never the thing keeping the lights on. What’s vanishing is reviewability: the shrinking fraction of the code that anyone has actually read, understood, and confirmed.

So mourn that, then go fix it, because it is fixable. Stop asking whether the code is clean. Start asking whether you’ve proven it works, holds up under load, keeps its secrets, and survives success. That was the only question that ever mattered. The pretty code was a costume it wore for thirty years, and the costume finally slipped off.