AI has entered product design at both ends of the process and barely touched the middle. Discovery now runs through AI research synthesis and synthetic participants, generation runs through prompt-to-prototype tools, and the design phase between them is the only part of the sequence that produces output that somebody can be held to. That distinction matters because generated design output becomes usable only where a system enforces constraints rather than documenting them, and enforcement is the part that most teams have not built. This article uses a three-zone model, discovery, design, and generation, to locate where AI-assisted product design breaks down inside a funded team.
Between February and June 2025, METR ran a randomised trial on sixteen experienced open-source developers working on repositories they had maintained for years. Tasks were randomly assigned to allow or disallow AI tooling. Before starting, the developers expected the AI-assisted tasks to go 24% faster. They finished them 19% slower. The part worth sitting with is what happened afterwards: having done the work, the same developers still estimated they had been 20% faster (Becker et al., 2025).
Sixteen developers is a small sample, the confidence interval is wide and the authors say plainly that the result should not be generalised. The perception gap is the finding that travels, and it travels becausethe subject is not really speed but the missing signal underneath itWhen output arrives faster and the cost of correcting it arrives later, in someone else's sprint, a team has no local way to tell whether the trade was good.
Stack Overflow's 2025 survey found the same shape from another angle. Among the 31,476 developers who answered its question on AI frustrations, the most common answer was not that the tooling fails but that output is "almost right, but not quite", named by 66% (Stack Overflow, 2025). That figure counts the developers who noticed. Anything caught at review has already cost somebody an afternoon, and anything not caught costs considerably more.
Product design has the same shape with none of the same instrumentation. A codebase complains eventually, through failing builds, slowing test suites and pull requests nobody volunteers to review. Nothing equivalent happens to a folder of screens.
Product design in a funded team runs through three zones. Discovery, where the problem gets defined and research becomes a set of priorities. Design, where those priorities become an information architecture, a scope, a sequence, an estimate and the system later work has to conform to. Generation, where screens, components, prototypes and increasingly front-end code get produced.
AI has arrived in all three, and the distribution is uneven in a specific way.
A survey of 906 designers across more than 60 countries, fielded in March 2026 by Designer Fund and Foundation Capital, found 91% using AI in their design work at least weekly, up from 54% a year earlier (AI in Design Report 2026). Three quarters use it daily, the average designer runs seven off-the-shelf AI tools against three last year, and half of all respondents say they have shipped code to production. The authors concede their sample may skew toward AI adopters, and the report is co-published by a venture firm with positions in the category, so read it as directional.
The year-on-year movement is the useful part, and it does not say what a neat version of this argument would want. Code generation rose 31 points and wireframing 27. Design systems came third at 24. Teams are applying AI to the middle, not only to the ends.
So the claim worth defending is narrower than "the middle was skipped". It is that AI arrived at the middle last, arrived there as an authoring tool rather than as an enforcement one, and that authoring is the half of the middle that was never the constraint.
What has not moved at all is trust. Figma's 2025 report found 32% of respondents agreeing they can rely on the output of AI in their work, against 78% agreeing it improves their efficiency (Figma, 2025). The published methodology for that figure is the phrase "surveying 2,500 Figma users", so treat it as one vendor's read on its own users.
The usual explanation is technical. Generating a component is a bounded problem and defining a product is not, so the bounded problems went first. That explanation does not survive contact with discovery, which is not bounded at all and went early anyway.
A better explanation is about what each zone leaves behind, and whether a machine can be trained on it.
Discovery produces findings. A finding is a claim about what people want, and nothing inside the artefact tells you the claim is wrong. Generation produces components, of which there are billions in public repositories and public design files. Both ends are richly represented in training data and both can be evaluated, loosely, by looking at the result.
The middle produces commitments: a scope, a sequence, an estimate with somebody's name against it, a set of non-functional requirements. Those documents are confidential, they never leave the client, there is no public corpus of them and there is no established way to score one as correct. They are also the outputs a person is answerable for, which is why they stay confidential in the first place.
That leaves a structural problem for a funded team. AI now supplies the inputs to the middle and consumes its outputs, while the middle is the only part of the sequence carrying constraints that something can be held to. Where the middle is thin, the two ends compound rather than cancel. Unfalsifiable findings feed a scope nobody constrained, and a generator produces components against a system that documents its rules without enforcing them. Teams that have thought carefully about where AI sits in their delivery workflow tend to reach the same place from the engineering side.
One objection is worth stating rather than dodging. A company that sells the middle as human hours has an interest in the middle staying human. The argument here does not depend on that. It depends on the middle producing constraints that can be checked, whoever or whatever produces them. The practical consequence is the same either way.
Nielsen Norman Group ran the obvious test in 2024. They took three studies already run with real participants, regenerated them using synthetic users and compared the output (Rosala and Moran, 2024).
Synthetic participants reported completing all the courses in a platform where real participants reported completing three of seven. They described active participation in community forums that real participants had dismissed as contrived. Most usefully for anyone buying discovery, the synthetic study returned seven engagement factors of apparently equal weight, with no priority ordering at all.
Ranking is the whole reason a team commissions research in the first place. An unranked list of everything a user might value reads as a transcript, and a roadmap built from one has no defensible basis for sequencing anything, which is where deciding what not to build quietly stops being possible.
The same group returned in March 2026 with a narrower concern: AI research tools now generate the study design as well as the synthesis, and generate it badly (Rosala, 2026). One produced a task telling participants to "pay close attention to whether the available courses are live online or self-paced", priming the exact behaviour the study was meant to observe. Both findings are illustrations rather than measurements, and NN/g does not claim otherwise.
Then there is the claim this section is expected to make and cannot. That products fail in discovery rather than in delivery is among the most repeated unevidenced assertions in product management, and its usual source is a 2015 essay offering it as experience with no study behind it. The closest thing to data is a 2026 review of 431 venture-backed companies that shut down since 2023, of which 385 had an identifiable cause: 70% ran out of capital and 43% cited poor product-market fit (CB Insights, 2026). Those are founder post-mortems measuring company death rather than product design, and they do not separate a discovery failure from an execution one. Nobody has published that decomposition.
Which leaves the practical version. Discovery output is the input to the middle, and a wrong finding does not announce itself. It arrives as a prioritised feature list, correctly formatted, ready to be estimated against.
Scale is the part that gets underestimated. One design engagement on a US-based energy intelligence platform we worked with produced 2,253 components, six Figma design files and a design library. At that size nobody reads the documentation. People search it, find something close enough and copy it.
Generation changes the rate rather than the behaviour. Agentic tools can now query a component library, read the codebase and ask a clarifying question, which the first generation could not. What they cannot do is tell a rule from a suggestion, and they work fast enough that a rule expressed only as prose gets overtaken before anyone reviews the output.
Coverage is not the constraint. zeroheight's 2026 survey of 147 practitioners found 92% include documentation and 86% have design tokens, but only 40% have any token automation pipeline and only 7% report full adoption across all teams (zeroheight, 2026). The sample is small and drawn from a design system vendor's audience, which over-represents organisations that already have a system, so 7% is better read as a ceiling than an average.
So coverage is high while enforcement lags a long way behind it, and generated output only ever meets the second one. Four things have to be enforced rather than documented before generated output is safe to ship.
A compiled token is a value defined once in a build pipeline and consumed by both the design file and the codebase, so a raw value cannot enter either one. A published token is a name in a document, which anything generating against it is free to read, approximate or ignore.
The gap between 86% having tokens and 40% having any automation is the distance between those two things. Most teams have named their values without connecting them to anything that refuses alternatives. A page describing the palette is a request, and requests get overtaken
A component API is the set of properties a component accepts and, more importantly, the combinations it rejects. Offering the correct component does not prevent the incorrect one being assembled next to it.
This is the failure that scales worst. Creating a variant that should not exist is a decision when a person does it and a default when a generator does, and the result is a library growing plausible near-duplicates faster than anyone reconciles them.
A state coverage requirement means every component is defined for loading, empty, disabled, error, success and edge cases before it is considered finished, and that a component missing those states cannot be marked done.
Published design work is thinnest exactly where real products spend their complexity: error recovery, partial completion, validation failure. A system that documents its states without gating on them produces interfaces that look complete and fall over on the second unhappy path.
Adoption measurement means instrumenting which components production actually renders, against which components the system publishes. Without it, a design system's health is assessed by asking the people who maintain it.
Only 41% of zeroheight's respondents measure adoption at all, and satisfaction with organisational buy-in fell from 42 to 32% year on year. The same survey found 61% worried about AI design generation against 35% worried about AI code generation, which is a reasonable ordering given that generated code lands in a repository with tests and generated design lands in a file with none. Teams that have built a design system across a large product estate hit the measurement problem before they hit the coverage one.
It does not land in the design file, which is why it stays invisible. The available evidence says it lands in the codebase, as work nobody goes back to. That evidence is about code rather than design, so what follows is a hypothesis with a mechanism, not a finding.
GitClear analysed 623 million code changes between 2023 and 2026 and found moved code, its proxy for refactoring, falling from 21% of changed lines in 2022 to 3.8% in the 2026 year to date (GitClear, 2026). Duplicated blocks rose 81% against 2023, and cross-file function calls, roughly a measure of reuse, fell 35%. GitClear sells code analytics, publishes no confidence intervals and restates baselines between editions, so the direction deserves more weight than any single percentage.
DORA's 2025 survey of nearly 5,000 technology professionals found 90% using AI at work, 30% reporting little or no trust in what it produces, and AI adoption positively associated with delivery throughput while remaining negatively associated with delivery stability. They also found no evidence that AI adoption weakens the historical harms of that instability (DORA, 2025).
The limit is worth stating plainlyNeither study contains a design system variable, no one of those 623 million changes is known to have come from a design generator, and 90% direct developer use of AI coding assistants is a sufficient explanation on its own. What the datasets establish is that output volume is rising while the mechanisms that correct it weaken. Whether unenforced design systems contribute is a reasonable inference and an untested one, and it is why code quality is worth treating as a live constraint rather than a later cleanup.
The sequencing argument stands on its own regardless. A team that builds enforcement first gives generated output something to be wrong against. A team that generates first gets volume, and finds out later in a codebase where nothing was refactored and no design decision traces to a rule. Both teams adopted AI, and only one of them can tell whether it worked, which is where this started, with sixteen developers who finished slower and believed they had been faster.
Three moves, ordered cheapest first, because the cheap one tells you whether the expensive ones are worth doing.
Adoption instrumentation means recording which components production actually renders, against what the system publishes. Grepping imports across consuming repositories gets a usable first number in an afternoon; the harder version maps system components to code components and survives non-conforming usage that never imports the library at all.
It comes first because it is diagnostic. Only 41% of teams measure adoption, which means most teams improving their design system have no way to tell whether the improvement landed.
Token compilation means moving values from documentation into a build pipeline both the design tool and the codebase consume, so a raw value fails rather than passes.
Most teams do not need new tokens. They need the ones they already named to become load bearing. Expect the first run against a mature library to surface thousands of violations, so the real work is the exception policy: charts, gradients, marketing pages and third-party embeds are where these projects usually stall.
System-level acceptance means a review gate asking whether new work conforms to the system, held separately from the review asking whether the screen is good.
It is the hardest of the three and the least technical, because it changes who can say no and what happens when saying no costs a release date. It is also the only one that survives staff turnover, since it lives in a process rather than in the memory of whoever built the library. The same logic applies to AI output generally, where the review gate is the design rather than a workaround.
Most teams can answer the first half of that question from memory and struggle with the second half. The gap between them is where generated output either becomes useful or becomes maintenance, and it is measurable before anyone commits to a cleanup.
If a generator is about to meet your component library, the first useful step is an inventory: how many components exist, how many are near-duplicates, which values are compiled rather than merely written down and what proportion of production actually renders the system. That is what determines whether the work ahead is a pipeline change or a consolidation project, and the two are not the same size.
If you're more of a visual learner, here's the full infographic to put these numbers into perspective: