The Hardest Part of Building Software Is Knowing What to Leave Out

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." — Antoine de Saint-Exupéry

Martyn Day published something worth reading this week. He asked an AI whether Autodesk Construction Cloud could be rebuilt. The AI said yes - for most of it. And then Martyn flagged two things that I think matter more than the capability question: that specification quality is now the binding constraint, and that UI matters more than most people building with AI appreciate.

Both of those observations point at the same underlying problem.

The addition trap

One of the things I've noticed with vibe coding and AI app builders is that they're optimised for addition. You describe a feature - it appears. You describe another - it appears alongside the first. But it goes further than that: the AI doesn't just comply, it suggests. "Would you like me to also add…" - and the suggestions are good. They sound logical. They sound like things a thoughtful developer would think to include. So you say yes, and yes again, and before long you have something comprehensive that nobody particularly wanted.

This feels like progress. It often isn't.

The best software is characterised by what's been taken out, not what's been put in. The decisions about what not to include - which option not to surface, which workflow to leave invisible, which feature to refuse - are where the quality actually lives. That discipline is invisible in the output but present in every good product you've ever used.

When Martyn says UI matters, he's not talking about aesthetics. He's talking about this: the person building with AI has to know what to subtract.

Specification is a subtractive skill

A good specification isn't a feature list. It's a sequence of decisions about what something should and shouldn't do, with enough precision that someone else - or an AI - can build it correctly.

That kind of specification requires real domain knowledge. Not because the technology is hard, but because knowing what to leave out is hard. Should the clash detection result surface three issues or thirty? Should the RFI response time appear on the list view or only in the detail panel? Which default saves the user a decision, and which default creates noise?

Those judgements aren't in the AI. They're in the person writing the specification. And that, more than any technical capability, is what determines whether what gets built is actually useful.

What this means right now

Martyn's piece describes a real shift: the constraint is no longer can it be built, it's can it be specified well enough. That's an optimistic framing if you have domain knowledge. It's a trap if you don't - because the tools will happily build you something complicated, comprehensive, and hard to use.

The skill worth developing isn't how to prompt an AI to build something. It's how to think clearly enough about what you want - and what you don't - that the result is worth using.

Saint-Exupéry would have recognised the problem immediately.

Martyn Day's original post — and Claude's full assessment — is worth reading in full.

I'll be coming back to this LInkedIn post again shortly, as there is something else that is very interesting as well...

If you're thinking through what this shift means for your software product or your practice, this is exactly the kind of thing I work through with teams. Let's talk →