For a long time, the cost of developing software served a purpose no one had assigned to it: it forced people to argue.
Before spending months on a feature, someone had to explain why it was worth building. Teams had to decide what made the cut, what stayed out, and which problem justified the effort. The process was slow and did not always produce good decisions, but it created a pause.
AI is removing much of that friction. Today, we can test an interaction in an afternoon or turn an idea into something functional before deciding whether we actually need it.
That is a significant improvement. It also creates a less visible problem: when building becomes cheap, overbuilding does too.
In The Convergence Trap, I wrote about how different teams, working with similar models and facing the same constraints, end up with similar solutions. Architectures repeat themselves. So do interfaces and even the language used to describe the product.
The model suggests the most likely answer. When many teams begin with that answer, their products converge.
But there is another consequence. These similar solutions do not only repeat across products. They also begin to accumulate inside each one.
A manual task appears, and automating it seems reasonable. Users keep asking the same question, so someone proposes an assistant. Each addition has a convincing argument behind it and, often, a working demo. Eventually, the product can do much more without necessarily solving its original problem any better.
Some of this similarity is reasonable. Similar problems often have similar solutions, and using a familiar pattern is not a failure of imagination. The difficulty begins when the technical answer replaces a decision that depends on context.
In one document-processing project, for example, two fields could both represent a quantity. The model could choose one and produce a perfectly plausible answer. The real decision was elsewhere: which field had authority, and what should happen when the two contradicted each other.
A better prompt could not resolve that.
Something similar happened with a knowledge tool. Extracting a claim from a document was relatively easy. The important question was whether that claim should enter the system as a fact or remain pending until a person confirmed it. The technical difference seemed minor. The difference in user trust was substantial.
Both cases had answers that were easy to implement. Neither decision could be fully delegated to the model.
This is the cost that estimates often miss. A feature does not cost only what it takes to build. It must then be integrated, explained, maintained, and given appropriate permissions. Its failures need to be anticipated. It also consumes attention. A feature can work exactly as designed and still make the product worse.
With AI, “less is more” is a product discipline, not a minimalist aesthetic. Some complex problems require complex products. The question is whether each part exists because of an observed need or because the technology made adding it tempting.
A small product can still be generic. Removing features does not create judgment on its own. The decisions that remain must come from the actual workflow, its exceptions, and the consequences of getting them wrong.
AI can also help us build less. It makes disposable prototypes possible and allows us to test the central assumption before turning an idea into a permanent feature. If the experiment shows that nothing important changes, removing it is a useful result.
Before adding something, we should be able to explain which specific behavior it is meant to change. If it works, we should also ask what part of the product could disappear. The review is complete when we can explain why this solution belongs in this particular product rather than any other one.
In the past, the pause was imposed by budgets and deadlines. Now it has to be introduced deliberately, just as the first prototype begins to feel like a decision already made.
Otherwise, AI will help us build much faster—including the things no one needed.