The Prototype Has Become Too Cheap to Trust

A prototype used to mean that an idea had survived contact with several people.

Someone had tried to explain it. Someone else had misunderstood it. A designer had turned the explanation into screens and discovered that the simple feature needed twelve states. An engineer had asked where the data came from. A manager had noticed that two departments used the same word to mean different things. By the time the prototype existed, the idea was still incomplete, but it had at least accumulated some resistance.

That relationship between effort and evidence is starting to break.

UX Pilot can turn a paragraph into a user flow. Figma Make can make the flow interactive. v0 can turn a prompt into a functioning interface. Lovable or Replit can add authentication, a database and deployment. Cursor or Codex can continue building the parts that do not quite work yet.

These tools are usually compared as competitors, but they increasingly look like different stations on the same assembly line. An idea enters as a sentence and leaves as something with navigation, accounts, a dashboard, responsive layouts and a domain name.

It may happen before anyone has seriously disagreed with it.

I find this more interesting than the usual question of whether AI can replace designers or developers. The tools clearly can produce parts of their work, sometimes impressively. The stranger question is what happens to the meaning of a prototype when almost anyone can generate one before understanding the problem.

For a long time, the prototype carried a little bit of institutional weight. It suggested that someone had made decisions. The decisions might be wrong, but they had at least been made deliberately enough to become visible.

Now the prototype may only show that someone wrote a detailed prompt.

That does not make it useless. A generated flow can be a very good object to react to. It can expose that a supposedly simple service actually requires onboarding, permissions, recovery states, notifications, account management and some uncomfortable explanation of what happens when the automated recommendation is wrong.

But the output can also make those questions disappear too quickly.

The tool fills empty space with plausible product logic. It creates a familiar sidebar. It invents labels. It adds a progress indicator to onboarding. It places a calm green success message at the end. The result feels coherent because we have seen variations of it in hundreds of other products.

It looks less like a proposal than a decision.

This is where the tools become dangerous in a very ordinary way. Not because they produce obviously terrible interfaces, but because they produce interfaces that are good enough to change the conversation.

Before the prototype, a team might ask whether the product should exist in this form. After the prototype, the questions often become smaller. Should this button be blue? Can the card be moved higher? How long would it take to connect the database? When could we show it to users?

The existence of the object quietly narrows what can still be questioned.

This happened before AI, of course. Teams have always become attached to their own prototypes. A polished mockup has always been able to make a weak idea feel more inevitable. The difference now is how quickly the idea can acquire all the external signs of seriousness.

Within an afternoon it can have a visual system, a working login, sample data and a deployment link. By the next meeting, it no longer feels like someone's suggestion. It feels like a product that is already late.

The old process contained a lot of waste, and I do not want to romanticise it. Designers spent days rebuilding familiar screens. Developers repeatedly wired up the same authentication flows. Teams held workshops that produced more sticky notes than decisions. Slow work was not automatically thoughtful work.

But some of the friction was doing something useful.

The awkward wireframe forced someone to decide what belonged on the page. The engineer asking for the data model exposed that the organisation did not actually know where the information came from. The designer struggling with an error state discovered that nobody had decided who was responsible when the system failed.

The project learned what it was by encountering people who could not proceed without answers.

The new tools are built to proceed anyway.

UX Pilot needs to complete the flow, so it invents a reasonable next screen. Figma Make needs the interaction to continue, so it creates a transition. v0 needs the interface to run, so it supplies a conventional structure. Lovable needs the app to function, so it makes assumptions about the database and user roles.

Each assumption may be individually sensible. Together, they can carry a half-formed idea surprisingly far without forcing the team to confront what remains unresolved.

This may be the real difference between an AI product team and a human one.

The AI product team has no one in it who disagrees.

There is no designer saying that the workflow makes no sense. No engineer asking why the system needs to exist at all. No operations person pointing out that the organisation cannot deliver what the interface promises. No researcher explaining that users do not think about the problem in the categories shown on the screen.

The tools are extremely cooperative. Cooperation is the product.

You ask them to make the idea real, and they try very hard not to become the person who slows the idea down.

This creates a new kind of responsibility for the person using them. The important skill is no longer only knowing how to produce the prototype. It is knowing when to distrust it.

A generated healthcare dashboard may look credible while giving equal visual importance to two actions with completely different consequences. A financial app may communicate confidence more effectively than the underlying model deserves. A public-service flow may remove the visible complexity of the institution while leaving the actual complexity for the user to discover later.

The screens are not necessarily badly designed. They may be designed too convincingly.

For HAAM, this is probably the more interesting territory. As the cost of producing a respectable interface falls, the value moves toward examining what the interface is claiming.

Can the organisation actually respond within the time shown on the screen? What happens when the data is missing? Who can override an automated decision? Is the user being shown uncertainty, or has uncertainty been converted into a reassuring card? Does the service still work when it meets the people who do not follow the expected path?

These questions are not as visually impressive as generating a complete dashboard from a prompt. They are also harder to demonstrate in a thirty-second video.

But they may become more important precisely because the visible parts are now so easy to produce.

We may soon have more prototypes than anyone knows how to evaluate. More apps that technically exist but have not survived contact with an institution. More product-shaped objects that can be deployed, demonstrated and funded before anyone has decided what maintaining them will require.

The problem is not that AI lets people build too quickly. Sometimes building quickly is the only way to understand an idea.

The problem is that speed can remove the moments when the idea would normally encounter resistance.

A prototype should not only make an idea visible. It should give reality a chance to push back.

When the prototype becomes almost free, that resistance has to be added deliberately. Otherwise the tool does not merely accelerate the product process. It carries the idea past the point where people still feel permitted to ask whether it should have become a product at all.

Tools referenced

This essay compares a group of tools that compress different parts of the path from idea to deployed software: UX Pilot, Figma Make, v0, Lovable, Replit, Cursor, and Codex.

Connected reading

• The Interface Is Now Part of the Answer
• The Product Needs a Harness
• The Coding Assistant Is Becoming the Development System
• Executable Drafts

AI authorship note

This essay grew from Kris Haamer testing UX Pilot and asking how it compares with other AI tools that generate interfaces, prototypes, code, and complete applications. AI supported comparison, drafting, editing, and implementation. Kris redirected the article away from a feature comparison and toward the changing meaning of prototypes, selected the central argument, sharpened the language, and chose the final version for publication.