AI can generate a prototype in minutes, and the result usually looks impressive at a glance, which is exactly the problem. A prototype that looks finished and fails on inspection is more dangerous than one that looks rough, because it invites you to trust it and ship it. To find out where AI-generated prototypes actually break, rather than where people assume they do, the useful thing is not opinion but a structured review of a real sample. This piece gives you that: a taxonomy of the failures that recur across AI-generated prototypes, drawn from patterns anyone doing design QA will recognize, and a method you can run to attach real numbers from your own review. The failures below are consistent and predictable, which is good news, because predictable failures are catchable.
This applies the same structured-review approach as our teardown of 50 SaaS dashboards, pointed at AI output specifically.
How to run the review
AI can generate a prototype in minutes, and the result usually looks impressive at a glance, which is exactly the problem.
A review is only as trustworthy as how it was done, so run it deliberately. Gather a set of AI-generated prototypes, a mix of your own across different tools and prompts plus public examples, spanning product types (dashboards, consumer apps, forms, marketing). Review each against the fixed checklist of failure categories below, record which failures appear in each, and report the real counts: how many exhibited each failure. Reporting the sample size and its makeup plainly is what makes the numbers trustworthy.
The value of counting, rather than asserting, is that it turns "AI prototypes have problems" into "this specific failure appeared in X of 30 prototypes," which is a claim that ranks, gets cited, and actually helps a reader prioritize what to check. The categories below are what to count.
The seven ways AI-generated prototypes break
Across AI-generated prototypes, the same failures recur, and they cluster into seven categories. These are drawn from the consistent patterns of how AI generates design, and your review will attach a frequency to each.
1. Missing states. The single most common failure. AI generates the happy path, the screen with typical data, and omits the empty state a new user sees, the loading state during a wait, and the error state when something fails. A prototype that only shows the populated, everything-worked version is showing the easiest case and hiding the ones that actually determine whether the design works. In a prototype, this often shows up as screens that assume data always exists and interactions that assume nothing ever goes wrong.
2. Broken or fake interactions. A prototype implies interactivity, and AI-generated ones frequently have interactions that look real but don't work, buttons that go nowhere, flows that dead-end, navigation that's inconsistent from screen to screen. The prototype demonstrates the concept for the one path the demo takes and falls apart the moment you try anything off that path.
3. Edge-case blindness. AI generates against tidy sample data, so prototypes break on reality: the long name that overflows, the huge number that breaks the layout, the empty list, the list with hundreds of items. Because the AI only ever saw clean data, the design has no answer for the messy data real users bring.
4. Weak information architecture. The prototype looks organized and structures the information wrong, surfacing what's easy to generate rather than what the user needs first, burying the primary action, ordering things by convenience instead of by task. It's plausible-but-wrong structure, which is harder to catch than a visual bug because everything looks fine.
5. Fake or generic content. Placeholder-grade copy dressed up as real: generic headings, meaningless microcopy, "Something went wrong" errors, lorem-adjacent filler. The content looks like content and says nothing specific, which in a prototype masks whether the design actually communicates.
6. Accessibility failures. Low contrast, missing focus states, poor semantic structure, the same accessibility gaps AI generates everywhere, present in prototypes and usually invisible until someone checks, because the prototype looks fine to a sighted mouse user and fails for everyone else.
7. Systemic inconsistency. Across a multi-screen prototype, the pieces don't cohere, spacing drifts, components vary, patterns change from screen to screen, because the AI generated screens somewhat independently rather than from a consistent system. The prototype feels slightly off as a whole even when each screen looks fine alone.
Notice that only two of these, generic content and some accessibility issues, are visible at a glance. The other five hide behind a finished-looking surface, which is why a structured review beats an impression, and why counting how often each appears is worth doing.
The fixes
For each failure category, there's a corresponding fix, and together they form the QA pass that turns an AI-generated prototype from a risky first draft into something trustworthy.
The through-line is that most of these failures are caught by a structured review rather than a glance, so the primary fix is having a QA rubric and running it on every generated prototype, which is exactly what a rigorous design-QA process lays out. Specifically: check for the three missing states explicitly, because they're the top failure; test every interaction and every flow off the demo path, not just the one the demo takes; push the prototype against messy data, long strings and large sets, to expose edge-case blindness; review the information architecture against the actual user task, not the visual polish; replace generic content with real, specific copy; run the accessibility checks (contrast, focus, semantics); and review the whole prototype for systemic consistency, not just each screen in isolation.
The second fix is upstream: better prompts reduce the failure rate at the source. Naming the required states, specifying real content, and demanding consistency in the prompt cuts down how much the review has to catch, which is why prompt quality and review quality work together, a relationship covered in designing AI features users trust. You won't prompt the failures away entirely, but you can shrink them before QA even starts.
Why this matters more for prototypes
There's a reason to care specifically about prototypes, beyond general AI-design QA. A prototype's whole job is to represent how something will work so a team can make decisions from it, test it, get buy-in, commit engineering time. If the prototype hides the hard parts, the missing states, the broken edge cases, the decisions made from it are made on a false picture, and the gaps surface later, in build, when they're expensive. An impressive-looking prototype that omits exactly the parts that are hard to build is worse than useless; it's actively misleading, because it makes the work look more done than it is. Reviewing AI-generated prototypes rigorously isn't perfectionism; it's making sure the thing you're deciding from is telling the truth.
Why prototypes get a free pass they shouldn't
Prototypes are uniquely dangerous among AI-generated design, and it's worth understanding why, because it explains why this review matters. A static mockup is understood to be a picture; nobody expects it to work. A prototype, by contrast, implies function, it looks like it behaves, so people evaluate it as if it does, and an AI-generated prototype that demos smoothly for one path invites everyone in the room to believe the whole thing works. That belief is where the free pass comes from: the prototype looks finished and interactive, so it gets treated as proof the design is sound, and the gaps, the untested paths, the missing states, the interactions that go nowhere, stay hidden until someone tries to build it. The more polished the prototype, the bigger the free pass, and the bigger the eventual surprise. Reviewing AI-generated prototypes rigorously is really about revoking that unearned free pass before decisions get made on a false picture.
Running the review efficiently
Reviewing thirty prototypes, or even one, is faster with a system, and the system doubles as your ongoing QA habit. Work through the seven categories in a fixed order rather than looking for problems randomly, because a checklist catches what a wandering eye misses, and the structural failures (missing states, weak IA, broken interactions) are invisible to a glance. Start with the failures that hide, the states and the off-path interactions, since those are both the most common and the most consequential, and leave the visible ones (generic content, obvious contrast issues) for last because you'll catch them anyway. Test interactions by deliberately going off the demo's happy path, clicking the things the demo didn't, entering the data it didn't, because that's where the fakeness lives. Recording which failures appear, rather than just noticing them, is what turns the review from an impression into the countable data that makes this piece rank, and it's the same rubric-driven discipline any solid design-QA process requires.
What a good AI-generated prototype actually looks like
To keep this fair, it's worth saying what passing the review looks like, because the point isn't that AI prototypes are worthless, it's that they need work to be trustworthy. A good AI-generated prototype, after review and fixing, handles all three states rather than just the populated one, has interactions that actually work across every path a user might take, holds up when you throw messy data at it, structures information around the user's real task, uses specific rather than generic content, meets basic accessibility, and stays consistent across every screen. That's an achievable bar, and the value of the review is precisely that it takes an impressive-but-hollow first draft and turns it into something that clears that bar, which is a genuinely useful starting point. The failures aren't a reason to reject AI-generated prototypes; they're a checklist for turning them into prototypes you can actually decide from, which is the difference between AI as a fast first draft and AI as a source of confident, misleading pictures. Used with the review, an AI-generated prototype gets you to a trustworthy artifact faster than building one from scratch, which is a real gain; used without it, it gets you to a wrong decision faster, which is a real cost. The review is what determines which of those you get.
Start Monday
Take one AI-generated prototype, yours or a public example, and run it against the seven categories above, writing down which failures it has. You'll almost certainly find missing states and at least one broken interaction, and seeing it on a real prototype makes the pattern concrete. Then do it across a handful more and you've started the review that this post is built around, a real count of where AI prototypes break, which is both the beginning of your own QA habit and, if you push to thirty, a genuinely rank-worthy piece of research.
AI-generated prototypes break in consistent, predictable ways, which means a structured review catches them reliably. Check for the missing states, test the interactions off the happy path, push against messy data, and review structure and consistency, not just surface. Do that and a prototype becomes a truthful basis for decisions rather than an impressive picture that falls apart in build.