Deleting 19k Lines of Dead Compiler Code Without Trusting the LLM

The author recounts deleting about 19,000 lines of dead code from a compiler in roughly a week, shrinking the binary by more than 50 MB. A month on, there were no reverts and no fix-up commits.

Why deletion gets skipped

Code piles up and no one clears it. A former colleague once advised the author to leave tangled code alone: cleanup goes unnoticed and unrewarded, and in his experience such refactors ended in disaster and a revert. If it works, don't touch it.

The author disagrees. Software obeys the second law of thermodynamics: left alone it drifts toward disorder and becomes unmaintainable. AI shifts the economics both ways. It raises the cost of dead code — a model reads a retired pattern as a valid example and reproduces it in new code. And it lowers the cost of cleanup: understanding every dependency before cutting, once the bulk of the effort, is now something the model does well.

The problem

A retired flow, call it flow X, was controlled by the option --XYZ. It no longer sat on any default path, yet its code was interleaved with code still in production. The task: remove every trace of it while leaving the surviving flows' behavior unchanged.

Five steps, no trust required

Scope. The first question was not how to delete but what to read at all. From where the flag is parsed, static analysis over compile_commands.json walks every caller and callee. The model marks each reached function by color: RED if behavior depends on the flag, BLUE if it merely forwards the flag's data. The marking is checkable — a second call-graph tool should reach the same set of functions. No faith in the model needed.

Classify. Each node gets a category: mechanical deletion, cross-ownership, side effects, or surgery. The model mislabeled only a few nodes — all whole-file deletions for files that in fact registered a pass under a string name. The fix was always to move the node to a riskier category.

Scaffolding. Each goal gets a test that fails until the goal is met. The deletion test is red before removal and green after; a forgotten site stays red. These tests are scaffolding, removed when the work is done.

Deletion and surgery. The AI makes the edits category by category, round by round. A subagent reviews each round first, then the author does.

Post-op cleanup. What remained was code shaped for modes that no longer exist. Touching only what the earlier steps touched, the author collapses a single-alternative std::variant into a plain type and reduces one-route dispatch to a direct call.

The result

Around 30 files and 19,000 lines gone, the binary lighter by 50+ MB. Only about 12% of the deleted lines got careful review — the classification said which 12%. The author's takeaway: the AI did most of the work, and he trusted none of it. There is no contradiction. Every change site had a verifier — a color, a category, a test — and his job was to check the verifiers, not to redo the work.

Source: Lobsters