AI didn't automate the hard part

A year ago, shipping software was gated by whether you could build it. That gate is gone. I can describe a product on Monday and have people using it on Friday, and so can you, and so can a competitor who thought of it six weeks after you did.

Everyone noticed the speed. Fewer people noticed what it removed: the excuse.

When a build took a year, a weak decision took a year to surface. There was always somewhere for it to hide — in the roadmap, in the integration work, in the quarter that slipped. Now the decision arrives in public within a fortnight, wearing no disguise at all. Speed didn’t make companies better at choosing. It made the choosing visible.

What did AI actually automate?

Implementation. That’s it, and it’s worth being precise about how narrow that is.

Writing code was never the expensive part of building a product. The expensive part was the sequence of decisions in front of it — what problem to solve, for whom, in what order, and what to leave out. Those decisions were always the constraint. They were just hidden behind a six-month build cycle, so nobody had to look at them directly.

Remove the six months and the decisions are all that’s left. Standing in the open, unflattered.

This is why so many teams feel busier and less certain at the same time. They’ve automated the part that used to make them feel productive, and inherited a job that mostly consists of judgment. That’s a different job. Most product organisations aren’t staffed for it.

Why does everything built with AI look the same?

Because a model trained on everything returns the average of everything, and the average is mediocre by definition.

Ask for a dashboard and you get the dashboard — cards in a grid, a chart nobody reads, a sidebar with eight items. Ask for a landing page and you get the landing page: hero, three feature columns, a testimonial, a call to action in a rounded rectangle. It isn’t wrong. It’s the statistical centre of everything that has ever been called a landing page.

Convergence is the point of these systems. It’s what makes them useful for the boring 80% of any interface — and it’s exactly why the remaining 20% now carries all of the differentiation.

The tell is easy to spot once you know it. Generated work is complete but undecided. Every element is present. Nothing has been sacrificed. There’s no evidence anyone chose one thing over another and accepted the cost.

Isn’t this just taste?

Partly. But taste is a worse word than it deserves, because it makes people think of decoration.

Taste, in practice, is a series of refusals. It’s knowing which four features to cut so the fifth one is obvious. It’s the restraint to leave a screen mostly empty because the one number on it is the only thing that matters. It’s noticing that the receptionist — not the doctor, not the patient — is the person whose day your software actually governs, and building the whole system around her.

None of that is styling. All of it is judgment expressed through the interface. And none of it can be prompted, because a model has no stake in the outcome. It cannot want the product to be good. It will produce whatever you ask for, at length, forever, with no opinion about whether it should exist.

That’s not a flaw to be fixed in the next version. It’s what these systems are.

So what’s actually scarce?

Three things, in order of how badly they’re missing:

Knowing what to build. Most AI initiatives I see are a technology in search of a use. The question was never “where can we put AI” — it’s “what is expensive, repetitive or badly served in our business, and does this happen to solve it.” Those produce very different roadmaps.

Knowing what to leave out. Now that everything is cheap to build, everything gets built. Scope has stopped being constrained by cost, which means it has to be constrained by conviction. Fewer teams have that than have budget.

Knowing how it should feel. Function has become table stakes. When four products all work, people choose the one that treats them like an adult. That’s the only durable moat left in most software categories, and it’s the one least likely to be on a roadmap.

Look at almost any category and you find the same shape. Clinic software that ignores the person actually typing into it. Design tools that solved presentation and never touched the part where the designer gets paid. Personal AI that answers questions beautifully and cannot run a single thing in your life. In each case the function works. The experience was an afterthought. That gap is not a technology problem, and no model will close it.

What this means if you’re building something

Assume your competitor can build whatever you can build, in roughly the same time, starting roughly now. That assumption is close enough to true to plan around.

What follows from it:

• Your product thesis is the asset. Not the code, which is now a commodity, and not the feature list, which will be matched.
• Speed is only an advantage if you’re pointed the right way. Shipping the wrong thing faster is a worse outcome than shipping it slowly, because you’ll have more of it to unwind.
• The interface is the argument. It’s where a company’s understanding of its customer becomes visible, or fails to.
• Decide out loud. Write down what you refused to build and why. That document will be worth more in a year than the roadmap.

I build three products at the moment. Every one of them exists because I found a category where the software worked and the experience was an afterthought, and I thought the second half was worth taking seriously. That’s the whole bet. It’s not a technology bet.

The building got easy. The thinking didn’t, and it isn’t going to.