The Cheapest Code Is the One You Never Write

Every dashboard in engineering right now is pointed at the same number: how much faster the team ships with a model in the loop. It is a fair thing to measure, and a genuinely good number to move. But it sits beside a quieter question almost no one has instrumented, because it has never been easy to instrument: of everything we shipped this quarter, how much of it needed to exist at all?

For most of the history of this craft, the difficulty of building was doing quiet work for us. Effort was a tollbooth. A feature that wasn't quite worth it tended to die on its own — not because anyone made a wise decision, but because no one could be bothered to pay the cost of building it. We mistook that for discipline. It was mostly friction. And the moment AI made building nearly free, the tollbooth came down, and every half-justified idea that used to stall at the cost of implementation now sails straight through to production.

What did not get cheaper is everything that comes after the build. A model can write the feature in an afternoon; it cannot carry the feature for three years. Maintenance does not discount itself because the first draft was generated. A failure at the worst possible hour does not resolve faster because the thing that broke was quick to create. Every feature you ship is a standing obligation — to understand it, to watch it, to fix it when it breaks, to explain it to whoever inherits it. AI compressed the cost of creation to almost nothing and left the cost of ownership exactly where it was. The bill didn't shrink. It moved out of view, to a date after the demo.

K Subramanian put a clean name on something I had been circling for months. The discipline AI cannot replace is the one that happens before a single line is written: the decision not to build. When you could only build a few things, choosing was forced on you. Now that you can build almost anything, choosing has to become a deliberate act — and most organizations have not yet noticed that the choosing is now the job.

This inverts what we reward. We have spent a decade celebrating the engineer who can build anything, fast. The scarce skill now runs the other way. It is the judgment to look at a feature that would demo beautifully on Friday and say, out loud, that it should not exist — that the roadmap it sits on grew to match the new velocity rather than any new understanding of the customer, and that shipping it would buy a week of applause and a year of weight. Subtraction is harder than addition. It always was. AI just made addition so cheap that subtraction is the only place real judgment has left to show itself.

There is a test I have started using, and I will credit the shape of it to that same essay. For anything we are about to build, I ask whether there is a specific person who will still be able to stand inside it a year and a half from now — diagnose it when it misbehaves, hand off what they know in an afternoon, defend why it exists. Not a team. A person. If the honest answer is that no one will own it that way, we have not designed a feature; we have taken on something no one is home to keep, and the unkept things are how a codebase quietly becomes unlivable. The fix is unglamorous and entirely human: make the decision to build explicit, attach a name and a horizon to it, and treat "should this exist" as part of what done means rather than a question we were too busy to ask.

So I have stopped reading velocity as the headline and started reading it as half of a sentence. The other half is restraint, and restraint never shows up on a chart — you see it only in the absence of things, in the features a disciplined team chose not to build and therefore never had to carry. The teams that come through this era in good shape won't be the ones with the most impressive build velocity. They'll be the ones who remembered that the cheapest code to own is the code you had the judgment never to write.