# Prototyping with AI: when it speeds up the work and when it misleads > Prototyping with AI is fast, but a working demo does not prove the idea is good. Which prototypes suit AI and how to avoid being misled by a demo. *Tags: ai, prototypes, ux-for-ai, vibe-coding* --- > [!info] Quick Definition > **Prototyping with AI** means building a functional prototype by describing what you want to a code or design generation tool, instead of building every screen by hand. It speeds up exploration, but it does not replace testing with people. ## What changes when the AI generates the prototype? Before, a clickable prototype required weeks of work in a design tool and often help from a developer. Today, one person can describe a flow and have a clickable version in an afternoon. What changes is not only speed but who can explore: a designer can test five variants of a flow before asking for a review. The risk changes too. A hand-built prototype usually looks like a draft, and the team treats it that way. A generated prototype can look polished from day one, which gives it more weight than it deserves. ## How much does it really save? The evidence is still thin, so read it carefully: - **A UX Tools survey (Spring 2026 report)**, with 1,478 responses across 18 regions, found that 43.8% of designers spend more than half their time vibe coding. It measures usage, not time saved or quality ([UX Tools, the state of prototyping in 2026](https://www.uxtools.co/blog/this-is-the-state-of-prototyping-in-2026)). - **A lesson from software development.** A METR trial published in July 2025, with 16 experienced developers and 246 real issues, found that with early-2025 AI tools they took 19% longer, although they believed they had been 20% faster. It is not a study of designers, and METR flags those results as out of date: in February 2026 it published new data, but considers it unreliable because many developers refused to work without AI ([METR, 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/); [METR, February 2026 update](https://metr.org/blog/2026-02-24-uplift-update/)). What still stands is the warning: the feeling of speed is not a measurement. Because the evidence is scarce and changes fast, do not promise anyone a savings percentage. The quality of the interaction still needs human review. Measure your own process: how long a prototype takes you and how long it takes to correct it. ## Which prototypes suit AI? | Prototype type | Good with AI? | Why | |---|---|---| | Testing whether a flow makes sense | Yes | It is easy to discard and fast to iterate | | Showing an idea to stakeholders | Yes | It only needs to be understood | | Testing microinteractions or timing | With care | Needs fine tuning by hand | | Validating accessibility or contrast | Not on AI alone | Needs review with tools and people | | Foundation of a real product | Not without engineering | See [[what-is-vibe-coding\|what is vibe coding]] | ## What makes the prototype useful? The quality of the prototype depends heavily on the description. A Kasava guide shows prompts with concrete values (colors, typefaces, spacing), interaction states and breakpoints for each screen, with the generator using the components the project already has. It warns that a vague prompt "technically works" but produces a generic prototype, and that each iteration costs time and can break things that already worked ([Kasava, on prompts for prototypes](https://www.kasava.dev/blog/your-ai-prototype-is-only-as-good-as-your-prompt)). ## How do you keep the demo from misleading? Three simple practices: 1. **Define the question before building.** "Do people understand how to cancel an appointment in three steps?" is a question the prototype can answer. "Do people like it?" is not. 2. **Test with people, not the team.** Someone who does not know the product finds problems the team no longer sees. According to Jakob Nielsen, five participants uncover about 85% of usability problems in a first round, and he recommends several small rounds instead of one big one ([Nielsen Norman Group](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/)). 3. **Label what is a prototype.** A banner that says "Prototype, test data" stops anyone from mistaking the demo for a product. If the prototype becomes the foundation of a product, the next step is a specification and code review, as described in [[spec-driven-development|spec-driven development]]. ## Example Illustrative example: a team wants to know whether a clinic's clients understand a three-step payment flow. A designer generates a prototype with AI in an afternoon: three screens with fictional data. Six people test it. Four get lost at the confirmation step because the button says "Process" instead of "Pay". The team changes the text, tests again with four other people and keeps it. The prototype cost an afternoon; the test gave the answer. ## How to apply it tomorrow? 1. Write the question you want the prototype to answer in one sentence. If it does not fit in one sentence, split the prototype in two. 2. Describe the screen with concrete values (colors, spacing, states) and point to the components the project already has. 3. Find five people who have never seen the product and test the flow in under half an hour each. 4. Record the total prototype time, including corrections. After two or three prototypes you will have your own measure, more reliable than any industry average. After the test, decide in one sentence what changes in the product. If nothing changes, the prototype still did its job. Save each prototype with its question and its result in one line, even when you throw it away. After a few months, that log tells you which kinds of questions the prototypes answered well and which ones they did not. If the prototype becomes a product, the next step is [[idea-to-app-in-a-day|idea to app in a day]], with its limits. ## Common mistakes - Showing a generated prototype as if it were a finished product. - Measuring time savings only by how fast it feels. - Testing only with the team that built the prototype. - Leaving real data or credentials in a public demo. - Not defining which question the prototype answers. - Using AI to validate accessibility details without human review. ## Sources - UX Tools, "This is the state of prototyping in 2026": [https://www.uxtools.co/blog/this-is-the-state-of-prototyping-in-2026](https://www.uxtools.co/blog/this-is-the-state-of-prototyping-in-2026) - Kasava, "Your AI prototype is only as good as your prompt": [https://www.kasava.dev/blog/your-ai-prototype-is-only-as-good-as-your-prompt](https://www.kasava.dev/blog/your-ai-prototype-is-only-as-good-as-your-prompt) - METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (July 2025): [https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) - METR, update on the productivity impact of late-2025 AI tools (February 24, 2026): [https://metr.org/blog/2026-02-24-uplift-update/](https://metr.org/blog/2026-02-24-uplift-update/) - Nielsen Norman Group, "Why You Only Need to Test with 5 Users" (2000): [https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/) --- Source: https://www.fernandoux.com/en/wiki/ai/prototyping-with-ai/