YAGNI in the Age of AI Coding

When I work with Claude or Codex, I often discuss software architecture with them. I’ve noticed a recurring pattern: both are quick to suggest designs that are more complex than the problem currently requires. The proposals are more general, more extensible, and more “future-proof.”

There’s something funny about that last word. The models don’t know what the future of my software will look like. They’re applying familiar engineering advice: anticipate change, make components reusable, leave room to extend the design. Sometimes that’s right. Often, it means building things I haven’t asked for and may never need.

What Is the YAGNI Principle in Software Engineering?

In those moments, my job is to cut off the extra features. Software engineering has a name for that instinct: YAGNI — “You Aren’t Gonna Need It.”

Taken literally, YAGNI sounds like a claim about the future: this feature will never be needed. But that’s stronger than what we can usually know. In practice, it means something more modest: we probably don’t need this now. If we discover that we need it later, we’ll deal with it then. We’ll cross that river when we get to it — and build a bridge when there’s a reason to cross.

But why not build the bridge ahead of time?

Imagine building a road toward a river, then discovering that you need to cross it. If you already built the bridge, the road may connect to it neatly. You avoid stopping to redesign the approach or rebuild part of the road. Building ahead can make later work easier and keep the pieces compatible.

The trouble is that the bridge has a cost before it provides any value. Someone has to build it. Someone has to drag it through the desert to the river. In software, that means writing the code, fitting it into the design, testing it, explaining it, and maintaining it as the project changes around it. The bridge might save us work later, but carrying it there is work now.

How AI Coding Tools Change the Cost of Building Software

For most of software’s history, that calculation was shaped by the cost of human programming. Designing and implementing extra capability took time. So did reviewing and maintaining it. A feature that might be useful someday had to justify the present cost of building it. Often it couldn’t. YAGNI was a practical defense against paying that cost too early.

AI coding tools change part of the calculation. They can make it much cheaper to produce code. A generalized interface, an extra implementation, or a future extension point may take far less time to generate than it once did. If building the bridge becomes cheap, perhaps it makes sense to build it early.

The Hidden Costs of AI-Generated Code

But “cheaper to write” does not mean “free to own.” Generated code still has to fit the actual design. It can introduce more concepts, more paths through the system, more tests, and more behavior that a developer must understand. It can make the current problem harder to see. And if the imagined future never arrives, the project still carries the bridge.

That leaves us with a question, not a new rule: when AI reduces the cost of building ahead, how much should that change our understanding of YAGNI?

We shouldn’t answer using only the instinct we developed when every line of code was expensive to write. But we also shouldn’t assume that cheap generation makes speculative features harmless. The useful question is not simply, “Could this be useful later?” Almost anything could. It is: “Is the likely future benefit worth the cost of adding and maintaining this now?”

That cost has changed. Our judgment should change with it.