Why I Scrapped 120K LOC
with no regrets.

Here is what happened, and why it matters beyond my particular situation.

When you build with agents at speed, you are making a tradeoff that isn’t fully visible until you try to ship. The tradeoff is this: you trade comprehension for velocity. The code gets written fast. The features accumulate. The product takes shape. But your understanding of the system lags behind the system itself, because you didn’t write most of it — you directed it, reviewed it at the surface level, and moved on.

This is fine up to a point. The point, in my case, was around 120,000 lines.

By then I had seven different versions of the same data model coexisting in the codebase because each agent session had made slightly different assumptions about the schema. I had twenty-one database migrations for a product with zero users — a schema change per day, every day, with agents that couldn’t always tell which migration was canonical. I had files exceeding 5,000 lines because agents prefer to add rather than restructure, and nobody had drawn a hard boundary on file size. I had tests that tested the wrong things confidently.

The technical term for this is debt. But it felt less like debt and more like archaeology. I was excavating my own codebase trying to understand what I had actually built.

There is a specific failure mode in AI-assisted development that doesn’t have a good name yet. I’ve started calling it vestige accumulation.

A vestige is code that was never meant to be permanent, treated as permanent because it was never explicitly removed. It starts as a placeholder — a default value, a stub, a “we’ll fix this later” that got shipped. The agent sees it in the next session and assumes it’s intentional. Builds on top of it. Wires it into three components. Adds a test for it.

Now it’s structural.

I had vestiges everywhere. Settings panels with fields nobody had ever defined requirements for. Database columns that existed because an agent made a reasonable guess about what might be needed. An entire workflow system designed around a concept I had deprecated two weeks earlier but hadn’t fully purged. The agents had been faithful to a vision I had partially abandoned, because I hadn’t told them clearly enough that I’d abandoned it.

This is the part that nobody tells you about building with agents: they are extraordinarily good at building what they see. They are not good at knowing what to delete. Deletion requires understanding intent. Intent is exactly what evaporates between sessions.

The decision to scrap rather than refactor came down to a simple calculation.

A refactor would require me to understand the system well enough to fix it. But understanding the system was the problem. I had spent days trying to audit the codebase and kept finding new surprises — dependencies I hadn’t known about, patterns that contradicted each other, places where the same problem had been solved three different ways in three different files. Every fix revealed two new issues.

Starting over with the lessons from the spike was faster than finishing the spike.

This is a genuinely new calculation. Five years ago, 120,000 lines of code represented months of developer time. You couldn’t just scrap it and rebuild. The cost was prohibitive. Today, with agents, 120,000 lines can be a three-week prototype. The rebuild cost is measured in days, not months.

Code is cheaper than it has ever been. What isn’t cheap is architectural clarity. The decisions about what to build, how to structure it, where the boundaries are — those are still expensive, still slow, still require the kind of sustained human judgment that agents can assist but not replace.

The spike gave me architectural clarity at the cost of a clean codebase. The rebuild used that clarity to build something I could actually trust.

What I extracted from the scrap was not code. It was decisions.

The compiler logic that was the core of the product. The design decisions about data models that had taken three weeks of iteration to arrive at. The understanding of what the product needed to be and what it didn’t. None of that lives in files. It lives in comprehension. The scrap preserved the artifact. The builder preserved the lessons.

The new codebase started with a fraction of the scope. A single feature, implemented cleanly, with a clear data model and no legacy anything. The second feature was faster than the first because the architecture was cleaner. The third faster than the second.

There is a counterintuitive principle hiding in here somewhere: in an age where code is the cheapest it has ever been, the right amount of code might be less than you think. The value is not in the lines. It is in the clarity of what those lines express.

I am not recommending that everyone scrap their codebases. Most of the time refactoring is the right call. The right time to scrap is specific: when the cost of understanding the system exceeds the cost of rebuilding it with what you’ve learned, and when what you’ve learned is concrete enough to do the rebuild right.

What I am saying is that this calculation is different now than it was five years ago. The cost of building has dropped. The cost of carrying architectural confusion has not. At some point, in some projects, the math flips.

And in a world where agents can write code faster than you can read it, that point arrives sooner than anyone expects.

The strangest part of scrapping 120,000 lines was how quickly the new thing came together. Not because I was working harder. Because I finally knew what I was building.