Most Code Deserves to Die

One of our projects currently has 1,200 open pull requests. We accept maybe one or two per day. The rest will almost certainly be deleted.

This sounds wasteful. It's not. It's the point.

In traditional development, code is expensive. A developer spends hours, sometimes days, thinking through an approach, writing it, testing it, refining it. Every pull request represents a significant investment of human time and attention. Discarding code feels like discarding effort. So we optimize for not wasting it. We spec things out upfront, we debate architecture in meetings, we write detailed tickets. All of this exists to reduce the chance that someone writes code that gets thrown away.

But what happens when writing code costs almost nothing?

The economics flip entirely. When coding agents can produce implementations in minutes, the expensive part is no longer the writing. It is the reading. The bottleneck shifts from generation to evaluation. And that changes how you think about the entire process.

I personally discard code for the tiniest of reasons. If something feels off the moment I open a PR, it gets deleted, not because it's necessarily bad, but because "not obviously good" is now a sufficient reason to reject. When generating a replacement is cheap, your quality threshold can be ruthlessly high. You stop asking "is this good enough?" and start asking "is this the best version we could have?"

This is a fundamentally different relationship with code. Code is no longer a crafted artifact to be preserved. It's a hypothesis to be tested. Most hypotheses are wrong. That's fine. That's how you find the ones that are right.

The reason we still have 1,200 open PRs isn't because we're behind on reviews. It's because agents produce proposals faster than humans can evaluate them. And the most likely resolution for the backlog isn't to review them all. No, no! It's to delete them in bulk after a month or two. By that time, the project will have moved on. The problems those PRs were solving have either been solved better by newer attempts or have stopped being relevant altogether.

If this sounds brutal, consider the alternative. In the old model, you'd have a developer spend a week on a feature, submit it for review, get feedback, revise it, resubmit. The sunk cost at every stage makes it psychologically difficult to say "actually, let's start over." So you end up polishing something mediocre instead of exploring something better.

Now imagine the opposite. Hundres of agents propose hundreds of different approaches to the same problem. You scan them, pick the one that clicks, discard the rest. No sunk cost. No hurt feelings. No two-week review cycle for code that was never going to be great. Just rapid selection pressure applied to cheap, abundant output.

The skill that matters in this world isn't writing code. It's reading it. It's developing the taste and judgment to look at a pull request and know, within moments, whether it belongs in your codebase. It's pattern recognition at the level of "this feels right" or "something is off here" and having the discipline to act on that instinct without guilt.

We're not short on code. We're short on attention. And the teams that figure out how to allocate that attention wisely, how to evaluate fast, discard freely, and select ruthlessly, are the ones that will build the best software.

Most code deserves to die. The good news is that now it can, and something better will take its place by morning.