What it costs to unbuild what an AI wrote.

AI is fast in one direction. You ask for a feature and you get a feature, added to the file that is already open, at the end, where it is easiest to put. pdflokal’s main file started at 2,382 lines. That is already a lot of file. It did not stay there.

By the time anyone stopped to look, it was 3,634 lines. One file. Every feature had been added the same way, to the path of least resistance, and nothing had ever been taken back out. It ran. It shipped. Nothing errored, so nothing asked to be looked at.

The bill arrives when you change something

The cost of that speed is invisible until the day you need to change one thing. A 3,634-line file has no seams. To touch one part of it safely you have to hold all of it in your head at once, and you cannot, so every change is a small act of risk. That is the moment the bill for the fast start comes due, and it comes due to whoever is holding the file, which is usually not the person who typed it.

Taking it apart is a different kind of work than building it was. The file came apart into focused modules, each with a single job (a87304b). Then the harder pass: one commit removed 2,165 lines of dead code, duplication, and magic numbers (6bea91c). Not a feature. Not a fix. Just removal, of code that had been running the whole time.

2,165 deletions, 159 insertions.The shape of a cleanup pass: almost everything is a minus sign. Dead code that still runs looks exactly like live code until you check each line, which is why removing it is slower than writing it was.

And the same logic had been pasted into a dozen places, so a change had to be made a dozen times or it drifted. Pulling those into a single source of truth was its own series of commits. None of it added anything a user could see. All of it was the price of the speed that came before.

What this actually teaches

AI writes code at the speed of typing, and it writes debt at the speed of typing, because they are the same keystrokes. What it does not do is the other direction. It never proposes a deletion. It never says this file is too big. It never removes the thing it added last week. Growth is free and cleanup is manual, so the ratio only ever moves one way, until a human moves it back.

This is why “clean up my AI code” is a project, not a prompt. Adding two thousand lines took an afternoon of asking. Proving two thousand lines were safe to remove took real time, because dead code that still runs is indistinguishable from live code until you trace it. The speed you got up front was borrowed. The refactor is the repayment, and someone always makes it.

So when you inherit an AI-built codebase, the line count is a liability, not an asset. The question is not how much it built. It is how much of this can be safely deleted, and the answer is usually more than you think and slower than you would like.