Prototypes that cannot fail are demos

Jakob Nielsen made the case in Vibe Coding and Vibe Design, quoting a line from Kshitij Agrawal that the field has more or less adopted.

mockups existed because coding was difficult; now that coding is easy, the future is prototypes

Kshitij Agrawal, quoted by Jakob Nielsen, March 2025

Go straight to something that runs. Test the real interaction instead of a picture of it. I agree with all of that. The conclusion skips a step, and the step it skips is the one that made prototypes work.

A high fidelity prototype used to cost about a week of somebody’s time. That price did a job nobody assigned to it. It forced a conversation before the build, because no team spends a week without asking what the week is for. The question came first because the budget made it come first.

The deliverable ate the question

Forty-three percent of designers say their company now expects a working prototype as the deliverable, according to AI in Design 2026, a survey of more than 900 designers in 60 countries. Half have pushed AI-generated code to production. In the State of Prototyping survey run by Tommy Geoco and UX Tools, 1,478 responses collected this spring, 43.8% now spend more than half their building time on code a model wrote.

A deliverable and a prototype have different jobs. A deliverable gets accepted. A prototype gets built to be wrong in a particular way that somebody named in advance, and the whole point is that it might come back wrong.

When the artifact arrives before the question, the question gets written afterward, if anyone writes it at all. A question written after the build is a rationalization with a sample size attached.

What gets approved is average

Ninety-two people were shown AI-generated and human-made prototypes without being told which was which, and rated them on the short user experience questionnaire. The results split cleanly. Positive on the pragmatic side: usable, efficient, clear. Neutral to negative on originality and innovation. The authors called it usable but conventional.

Nielsen Norman Group ran their own version, rebuilding one of their training pages with three kinds of prompt. The detailed prompts got close to the human original. The outputs still missed visual hierarchy, color contrast and consistent margins, which is why they land on these tools being better for ideation than for production.

So the thing showing up in your review is competent, conventional and finished-looking. All three at once is very hard to argue with. That’s the problem, not the achievement. In Figma’s State of the Designer 2026, 58% of designers define craft as visual polish, ahead of thoughtful problem solving at 47%. Polish is the part that just became free.

One line at the top

Nothing goes into a design review without one line at the top of it: the belief this is built to kill, and what we would be looking at if that belief were wrong.

I want that line before the build, not in the deck afterward. If nobody on the team can write it, we’re building a demo, and I’d rather we call it a demo and put it on the calendar as one. Demos are useful. They’re just not evidence.

The first question in the review is the same question. What would this look like if we were wrong? If the honest answer is “about the same”, the prototype tested nothing and the next 40 minutes are a conversation about taste. Sometimes that’s the meeting you needed. It shouldn’t be the meeting you thought you were having.

At Best Egg, applicants uploaded their documents and then the dashboard went quiet. What we were testing was whether telling them the status after the upload changed how many finished, not whether the screen looked better. That version of the question has a result. It went through an A/B test before rollout and came back with one.

The forcing function has to come from a person now

Eighty percent of designers say they still rely on their own quality meter over the model’s. I believe them, and I don’t think a quality meter is the thing under threat here. Judgment about whether a screen is good survives cheap production fine.

What doesn’t survive is the part of the process that used to happen on its own because building was expensive. Somebody named the uncertainty. The team agreed ahead of time on what a bad result would look like. And before anyone opened a tool, everyone knew which of the plausible directions the build was there to rule out.

None of that was ever a method. It was a side effect of the price, and the price is gone. Which means it’s now somebody’s job, in writing, or it doesn’t happen.

The teams that get this wrong aren’t going to look slow. They’re going to look extremely fast, and they’re going to ship a lot of usable, conventional, well-spaced work that nobody in the building ever had the standing to question.