The Cleanup Crew
Everybody spent the last two years teaching AI to write the code. The next few are going to be about surviving what it wrote.
That's not a knock on the machines. Agents got genuinely good at greenfield — spin up a service, scaffold a feature, ship it before lunch. That part is real, and it isn't going anywhere.
But greenfield is the easy twenty percent.
The hard eighty is changing code that already exists. Writing code and transforming code are two different jobs, and the second one is where the agent quietly comes apart. It can conjure a clean new file out of nothing all day long. Ask it to reach into ten thousand lines that already work and move one thing without breaking the other nine thousand nine hundred, and you watch the confidence drain right out of it.
The rewrite cycle came back
Code has always rotted. This isn't new, and it isn't AI's fault.
In the twentieth century we lived on a five-year rebuild cycle. Codebases decayed, and the fix was a match and a fresh start — throw it out, write it again, rot again, repeat. Then in 1999 two people published a book called Refactoring, and the tools that followed it — ReSharper, IntelliJ, the analyzers — turned maintenance from a white-knuckle manual exercise into something mechanical and safe. Rename across a million lines in one click. The rebuild cycle ended. Healthy ten-year-old codebases became a normal thing to have.
Then the agents showed up and broke the cycle again.
They write faster than any human, but without the discipline of an engineer who's been burned or the eye of an architect who's seen this movie before. Architectural drift that used to take five years now takes five weeks. Same output, a fraction of the structural scrutiny. Nobody's reading the shape of what's being produced, because it's being produced faster than anybody can read it.
The debt isn't bugs. It's shape.
Here's the part people get wrong. They brace for bugs. Bugs you can find — they announce themselves, they throw stack traces, they show up red in CI.
The debt the agents pile up doesn't announce anything. It's structural. Five files that each solved the same problem a different way. A rename that landed in nine places out of eleven, so two ghosts of the old name still haunt the codebase waiting for a bad Tuesday. Clusters of tangled responsibility. Chokepoints where everything routes through one fragile seam. A dependency graph slowly tightening around itself like a knot you can no longer find the ends of.
None of that is a bug. Every test can be green and the codebase can still be dying.
And this is the trap nobody priced in: you bought the agents for speed. Past a certain threshold the structure itself starts capping the speed. Every new change has to route around the mess. The velocity you paid for becomes the thing strangling your velocity. You go faster and faster until the shape of the thing won't let you go fast at all.
"Just point an agent at it"
The instinct is obvious. If an agent made the mess, point an agent at the mess.
Try it.
Naive editing — string swaps, find-and-replace, file-by-file passes — doesn't understand structure. It sees text. It corrupts about as often as it fixes. One rename catches the wrong symbol two modules over, and now you're not cleaning up the codebase, you're debugging the cleanup. You've made a second mess to cover the first.
The problem is that text isn't the unit of meaning. The syntax tree is. A tool that reads code the way a compiler does — as a tree of declarations and references, not a wall of characters — knows that this count and that count are two different things, and that renaming one must never lay a finger on the other. A tool that reads text just hopes. Hope is how you get an eight-hour, budget-immolating refactor that succeeds at destroying exactly the thing you asked it to preserve.
This isn't linting
Let me kill one comparison before somebody reaches for it.
This is not static analysis. A linter reads your code line by line, hunting for bugs and rule violations — a missing semicolon, an unused import, a function too long. Useful. Not this.
What the moment actually needs works a level up, on the health of the codebase itself. The relationships between things. Where the load concentrates. Whether the system, taken as a whole, can still move. The question isn't "is this line wrong." It's "is this thing still alive — can this codebase still change without a fight."
You measure a body's health by how it moves, not by spellchecking its cells.
The shovels
Every gold rush minted more fortunes selling shovels than digging gold. This one's no different.
The shovel this time is the cleanup layer — the thing that sits underneath the agent and makes whatever it generates trustworthy to change. Not a slicker way to generate more code. The opposite. A way to reach into code that already exists and transform it with the precision of a compiler and the memory of a historian: every reference resolved, every relationship preserved, a receipt written for what changed, and an undo that actually works.
I spent a few months holed up in the desert building exactly that, and then — the part that convinced me it was real — I started using it to build itself. That's act101. The shape it insists on is three beats: analyze the structure you're standing in, act with deterministic transforms instead of hopeful string edits, and attest — prove the change did only what it promised, against the behavior it was supposed to preserve.
That last beat is the one everybody skips. Analyze and act are table stakes. Attest — the proof, the receipt, the honesty — is what lets you trust an agent's hand inside a codebase you can't afford to break. It's the whole difference between a very fast intern and an engineer.
Writing the code was the demo.
Changing it safely is the business.