You ask an AI to build you something. A few minutes later it works. You click around, and something is off. Nothing is broken. It just doesn’t make sense the way it should, and you can’t quite say why.
The easy explanation is that AI can’t design. I don’t think that’s it. I think what you’re feeling is older than AI, and I’ve watched very smart people fall into it for years.
I’ll say up front that I hold these ideas loosely. Some of them will probably look different to me in a year. But when I talk about this with people face to face, a lot of heads nod, so here’s how I’ve been thinking about it.
A classic I keep coming back to
Years ago, we won the bid to redesign USAFacts, Steve Ballmer’s nonprofit. It was an enormous, complex platform: thousands of small charts and facts spread across a huge system, with Penn Wharton managing the data, the Clippers’ tech team involved, and our partners at Dark Horse Analytics in Edmonton leading the data visualization.
One of the biggest problems with the site was that people didn’t understand what it was. A big reason for that was a really good idea.
Ballmer had noticed something genuinely clever: the way the US allocates its money maps closely onto the promises in the preamble to the Constitution. But the preamble had also become the site’s navigation. Visitors were asked to find their way through government spending by way of “establish justice” and “promote the general welfare,” and they just didn’t get it.
It wasn’t the only issue, but it was the obvious one, at least to us coming in fresh. To the people inside, it was too baked into the nature of the thing to question. Everything had been built around it. The insight was right. The anchor was wrong. And the more you build on an anchor, the harder it is to see.
The same thing, much faster
Recently I spun up a React app with AI, just to test some data structures for an internal reporting tool. It worked. It just wasn’t designed. It had picked a way of organizing itself early, and every screen after that followed from that first choice.
The more we used it, the clearer it became that I had to question every decision about how it was organized. So I told it to drop its earlier metaphors and navigation, look at the thing with fresh eyes, and work out what was actually needed and what wasn’t. Then we redesigned it together.
Had I not done that, it would have kept trucking along those same lines indefinitely. It wasn’t going to stop and ask whether the whole frame was wrong.
Isn’t it curious how similar that looks to the preamble? Step back ten feet and a wise founder holding onto a precious idea and a model extending its first guess look like the same thing. I’m not claiming the two work exactly the same way inside, but the behavior is similar: get locked into a metaphor, build a lot around it, and stop questioning the nature of the thing you’re building.
Where the design actually lives now
If the trouble starts with the first anchor, then the most important design work happens before anything gets built. It’s in deciding what the thing is, how it’s organized, who it’s for, and what each of those people needs to do. That’s the spec.
We used to hand that off to people, who would quietly fix the gaps as they went. Now we hand it to a machine that fills the gaps with guesses and keeps building on them, fast and confidently. If the spec is right, that’s a superpower. If it’s wrong, you get the preamble problem in an afternoon instead of over years.
That’s why I’ve come to think of design as the spec, and the spec as design. A thoughtful PRD is design work — writing it well means making a designer’s decisions. A thoughtful design, whether it’s a diagram, a few screens, or a prototype, tells the system more than pages of loose explanation. On USAFacts we produced hundreds of wireframes. Nobody needs that now. What you still need is someone who has made the decisions.
Saying it isn’t doing it
Spec-driven development is having a moment, and I think that’s a good thing. But I notice a lot of people treating the term as if it were the skill. Write a spec first, and the problem is solved. It isn’t.
A spec can be shallow. It can be wrong. It can anchor on a bad idea just as firmly as a prompt can. Ballmer’s preamble would have made a beautifully clear spec. Every screen would have followed it perfectly, and people still wouldn’t have understood the site.
So the question isn’t whether you have a spec. It’s whether the thinking in it is any good. Knowing what to put in it, and what to leave out, is a skill that has to be honed. You don’t get it by learning the vocabulary.
Earned, not granted
I want to be careful here, because there are two ways to get this wrong.
One is to read it as designers defending their right to decide how things work. That isn’t what I mean. Having “designer” in your title doesn’t give you a divine right. If anything, I think that attitude is dangerous.
The other is to decide that since anyone can write a spec now, the skill doesn’t matter. That undersells what an experienced UX designer with real technical chops and imagination can do.
What I’d say is that the right to steer is earned through understanding. You have to know what the AI is capable of. You have to know the conventions it’s drawing on and what it’s referencing. That understanding is the price of admission, and it’s also what separates good judgment from strong opinions.
We’ve seen this for years with tech teams and founders who bring us in to clean something up or make it better. The best relationships are with the people who are able to loosen their grip. We’ll often find a handful of kooky ideas sitting where thirty well-known conventions would have made the thing instantly more usable, the patterns people use every day. Nobody is born seeing that. It’s a trained muscle.
And it matters more now. When you can build incredibly fast, and the AI can anchor on a bad idea in the first hour, unravelling it gets hard quickly unless the spec was right from the start.
Holding it loosely
When I step back, the skill I keep coming back to isn’t writing specs, or taste, or knowing how to use AI. It’s being able to notice when the whole frame is wrong, and being willing to throw it out.
Written by
Micah Slavens
Principal, Lift
