The Broken Window Theory of Code, and Why Cheap AI Rewrites Don't Save You

There's a project I think about whenever someone tells me they'll "clean it up later."

It started the way these things usually do. A small team, a tight deadline, and a decision to just ship. No linter config worth the name. No agreed structure. No real research into the problem, because researching felt like a luxury they couldn't afford against the pressure to deliver. None of it seemed important at the time. They had something working, and working was the only thing anyone was measuring.

Two years on, nobody on that team could confidently explain how half of it worked. Not because the people were bad. Because the standard had been set on day one, and the standard was "whatever gets it out the door."

That's the broken window theory, and it applies to code far more literally than most people realise.

What the broken window theory actually says

The idea comes from criminology. A building with one broken window that goes unrepaired sends a signal: nobody is watching, nobody cares. So a second window gets broken. Then graffiti appears. Then the building tips into genuine disorder, not because of the first broken window itself, but because of what leaving it unfixed communicated.

The Pragmatic Programmer brought this into software years ago, and the mechanism is the same. The first hack you leave in, the first // TODO: fix this properly, the first test you skip because you're in a hurry, the first function you let grow to 400 lines because splitting it is annoying right now. None of those individually sink a project. What they do is move the line.

Because the next person, or the next you, looks at the code and calibrates. Code teaches you how to treat it. A pristine module makes you reluctant to drop a sloppy patch into it. A module that's already a mess invites one more mess, because what difference does it make? The standard of the codebase becomes the standard of the next commit. And standards, left alone, only ever drift in one direction.

The part that actually does the damage

Here's the spiral, and it's worth being specific because it's so easy to wave away.

You skip standards at the start to move faster. The early code is messy but it works, so it stays. New code gets written to match the code that's already there, because consistency feels like the responsible thing to do, even when the thing you're being consistent with is bad. The mess compounds. Then you hire someone.

This is the moment people underestimate. The codebase becomes the onboarding document. Whatever bar your existing code sets is the bar your new engineer absorbs in their first week, no matter what your README claims your standards are. If the code says "we don't write tests here," they stop writing tests here. You didn't lower the standard for one person. You lowered it for everyone who arrives after the window broke.

A year or two of that, and you get the codebase I described at the start. Not broken, exactly. Just illegible. Nobody can hold it in their head. Every change is a gamble. And the team starts saying the thing teams always start saying at this point: maybe we should just rewrite it.

And now the rewrite is cheap

This is where it gets genuinely interesting, and it's the question I actually want to sit with.

For most of software's history, the rewrite was the nuclear option. It was expensive, it was risky, it took months, and it usually reintroduced bugs you'd spent years ironing out. "Never rewrite from scratch" was close to received wisdom for good reason. The cost of rebuilding was the thing that kept teams honest, or at least kept them trying to understand what they already had.

That cost is collapsing. With an AI assistant, you can regenerate a module in an afternoon that would have taken a sprint. The barrier to "let's just rebuild this part" is lower than it has ever been, and it's still falling. So the honest question is: if rewriting is nearly free, does understanding the old code even matter anymore? Do we read and comprehend our systems, or do we just keep regenerating them whenever they get uncomfortable?

I find the question genuinely uncomfortable, because there's a real version of it where the answer is "yes, just rewrite." Throwaway code, prototypes, a script that did its job. For those, rebuilding has always beaten preserving, and AI just makes that even more obviously correct.

But for a system you actually depend on, I think the cheap rewrite is a trap, and it's the broken window theory that explains why.

A rewrite doesn't fix the window, it just moves house

Think about what a rewrite actually is. The code was a mess because of the standards that produced it: the day-one decision to skip the research, the unrepaired windows, the drift. If you regenerate the code without changing any of that, you haven't fixed the problem. You've laundered it. You get a fresh, clean-looking codebase that's about to decay along exactly the same gradient, except now nobody understands the new one either, because nobody wrote it, they prompted it.

And AI makes this worse in a specific way. A model writes code that's locally correct and globally clueless. It doesn't know the constraint you learned the hard way, the pattern you abandoned after an incident, the reason that "ugly" branch exists. The understanding embedded in your old, messy code is real knowledge, paid for in production incidents. A rewrite that doesn't first extract that knowledge throws it away. The new code looks better and knows less. I've written before about the day 2 problem, where AI-generated systems sail through day one and become untouchable by month three. A culture of cheap rewrites is the day 2 problem on a loop. You never reach day 2 of any system, because you keep starting a new day 1.

The deeper issue is that "rewrite instead of understand" is itself a broken window. It's a standard, and it's the lowest one there is: the standard that says comprehension is optional and disposability is the default. Once a team internalises that, it stops building the muscle that lets it reason about systems at all. And reasoning about systems is the entire job. It's the thing that separates an engineer from a prompt.

What to actually do

So I'm not anti-AI here, at all. I use these tools constantly and they make me faster every day. The point isn't to rewrite less. It's to refuse the trade where cheap regeneration substitutes for understanding and standards. A few things I'd hold onto:

Fix the first broken window. The whole theory turns on the first one. Set the standards on day one, when there's almost no code and almost no cost, because that's the cheapest the standard will ever be to set. Decide on structure, testing, and the bar for review before the mess has anything to teach the next person.

Encode the standard so it can't quietly drift. Linters, formatters, and architectural fitness functions in CI are how you stop the slow calibration downward. A rule that fails the build doesn't care how busy you are this week. This matters more in an AI-assisted codebase, not less, because the model will happily break an invariant it doesn't know exists.

Use AI to raise the standard, not to skip it. The same tool that lets you launder debt with a rewrite can refactor the broken window properly, write the missing tests, document the constraint, and explain the gnarly function before you touch it. Point it at comprehension. Ask it to explain the old system before you let it generate a new one. That's the version of cheap AI that compounds in your favour.

Treat the rewrite as a last resort that has to earn its place, the same as it always was. If you genuinely choose to rebuild, do it after you've understood the old code well enough to carry its hard-won lessons forward, not as a way to avoid understanding it. A rewrite that inherits the knowledge is renewal. A rewrite that skips it is just a newer house with the same broken windows, freshly installed.

The cost of rewriting is falling, and that's real. But cheap rebuilding was never the thing that kept our systems healthy. Caring whether the window was broken was. That part hasn't gotten any cheaper, and I don't think it ever will.

If this resonates, it's the kind of thing I think about every week. I write about system design and the senior-to-staff transition in Monday BY Gazar on Substack, and I break down how to work with AI agents without losing your judgement on Gazar Breakpoint on YouTube.

And if your team is staring at a codebase wondering whether to understand it or rebuild it, book a free intro call and we can talk through your specific situation.