AI made prototyping faster. It also made bad ideas faster.

The prototype now arrives before the meeting ends

A few years ago a product idea needed time to become dangerous. Someone wrote the brief, made wireframes, designed the states, built a prototype, handed it to engineering. That friction was expensive, and it created natural moments where a team could still reconsider the premise.

Now a founder can describe a product in the morning and click through something convincing by lunch. AI tools produce a login flow, dashboard, onboarding, empty states and working interactions in hours. The prototype looks like progress because it is visible, concrete and interactive.

Which is exactly why teams need a sharper distinction between a prototype that demonstrates a concept and evidence that the concept deserves to exist.

A prototype is an answer to a question

The cleanest definition I know is operational. A prototype is an instrument for reducing a specific uncertainty. If you cannot name the uncertainty, you are building a demo.

Different questions need different prototypes. Do users understand this category is a message test. Can they complete this workflow is a clickable task prototype. Will the recommendation logic feel trustworthy needs realistic data and confidence states. Can the architecture support this latency is a technical spike. Will users pay is a demand test.

A full-stack app is not automatically better evidence than a sketch. It is only more expensive evidence, if the question could have been answered earlier.

Design fixation did not begin with AI

A 2019 experimental paper on early prototyping described a familiar problem: building and testing a prototype can cause people to commit prematurely to the concept they built, even when better alternatives exist. The authors connect this to fixation and sunk cost, and recommend using the lowest fidelity necessary to test the critical function.

This is older than generative AI. What AI changes is the psychology of fidelity.

The sunk-cost portion may shrink, because prototypes are cheaper to create. The persuasion cost grows. A generated prototype can look production-ready before anyone has spoken to a user.

Polish creates an illusion of evidence.

Stakeholders stop debating whether the workflow is right and start debating card padding. Engineers estimate the generated implementation. The team becomes attached, not because it spent three weeks building the concept, but because the concept has become easy to imagine as real.

High fidelity changes the question without asking

Suppose the team needs to answer whether finance operators understand the difference between matched, suggested and needs review. A low-fidelity prototype can answer that.

AI makes it tempting to build the entire reconciliation dashboard instead. Now the research session produces feedback on table density, button labels, chart preference and animation. The original question is buried in a much larger artefact.

That is one of the main risks of AI prototyping. It expands the test surface faster than the research plan expands. More realistic does not always mean more valid.

The fidelity ladder

I would deliberately choose among five levels.

1. Proposition. A sentence, a mock landing page, a storyboard. Tests whether the problem, audience and value make sense. 2. Structure. Boxes, rough flows, information architecture, basic states. Tests sequence, discoverability and mental model. 3. Interaction. Clickable prototype with realistic tasks and limited visual polish. Tests task completion and control logic. 4. Realism. Realistic data, role behaviour, error states, permissions, edge cases. Use when trust and operational complexity depend on production-like context. 5. Technical. Working integration, real performance, model output, APIs, persistence. Use when feasibility or system behaviour is the uncertainty.

AI makes level five cheap enough that teams want to start there. Do not. Start at the lowest level that can falsify your assumption.

Speed should buy more experiments, not more polish

This is the part many teams have backwards. If AI cuts prototype time by eighty per cent, the best use of the saved time is not one prototype that is eighty per cent more polished. It may be four structurally different prototypes, or three user tests in a week instead of one.

AI should widen exploration before it deepens commitment.

That matters more because of a second risk: AI assistance can raise average idea quality while reducing diversity across a group. If everyone uses the same model to produce alternatives, five generated concepts may be five cousins. Force structural variance. Ask for different information architectures, different control models, different levels of automation, different assumptions about the primary user. Colour changes are not exploration.

Put the test before the prototype

A strong workflow begins with a written test card. What do we currently believe. What happens if it is wrong. What exactly must we learn. What user behaviour or system result answers it. What is the cheapest artefact that produces that evidence. What result causes us to stop or change direction. What becomes worth building only after the test passes.

The failure threshold matters most. If a team decides what counts as success after seeing the prototype, it will almost always find a way to keep the concept.

Generated code is not validation either

A working app feels more truthful than a design file because it actually runs. But technical success answers a technical question.

If a coding tool can build the workflow, you have learned the workflow is buildable. You have not learned that users want it, understand it, trust it, or will change their behaviour because it exists. That distinction is easy to lose when the code arrives fast enough that teams skip research and call the build itself validation. The same methodological point applies from another direction in why your own team is not a sample.

Two tracks, meeting at gates

Run prototypes in two parallel tracks. An evidence track of interviews, concept tests, usability tasks, behavioural measures and success criteria. A build track of generated interfaces, technical spikes, data modelling and integrations.

The tracks meet at explicit gates. Build speed should not overtake evidence indefinitely.

The delete-it-tomorrow rule

Before starting a generated prototype, ask the team whether they would be willing to delete the entire thing if tomorrow's research disproves the direction.

If the answer is no, you are already too attached. That is the simplest test for whether the artefact still serves learning or has quietly become the roadmap.

The point

The old prototyping problem was cost. The new problem is credibility arriving too early.

AI lets us make ideas tangible before committing engineering time, which is a real advantage. The benefit disappears if the tangible artefact becomes the evidence.

Prototype quickly. Prototype several directions. Prototype the risky part first. Just keep the order straight: question, prototype, evidence, commitment. Not idea, generated app, attachment, retroactive validation.