This article is a response to Allie Paschal’s “The hidden cost of AI prototypes that are made to die“. I argue that why she is auditing a thirty-minute artifact against a process built for a designer-week, and calling the artifact the problem. AI changed the pipeline. Asking whether a prototype can survive handoff assumes handoff is still a stage.
AI Key Takeaways
AI prototypes are disposable because they moved upstream into ideation, the phase where ideas are supposed to die cheaply. Evaluating them for survival into production reads the direction of change backwards.
Rework counted as waste when an artifact took a designer-week to produce. Once generation is nearly free, the costs that remain are choosing what to give the AI and judging what comes back.
Cheap generation concentrated prototyping in expert hands: selecting the model’s inputs and recognizing a flawed output are both design judgment.
A research job that ends in a prototype is now a design job with research as a prerequisite. That’s most jobs now.
The failure mode worth worrying about is the polished prototype that refuses to die and gets mistaken for shippable product.
AI is fundamentally impacting how we do UXR,
and what kind of products we do it for.
Allie Paschal’s “The hidden cost of AI prototypes that are made to die“ argues that product teams pay later for prototypes built to be thrown away, and that teams should favor tools whose output can survive into production. I read the same evidence and reached the opposite conclusion.
It is symptomatic of anxiety I am seeing more and more in research and product teams.
A response.
The most useful sentence in Allie Paschal’s essay is one she spends a single line on: “If your team’s goals are to validate ideas quickly, disposable prototypes are a wanted tool outcome versus a flaw.”
Validating ideas quickly is the ideation phase. The ideation phase is where nearly every AI-generated prototype is born, does its job, then dies. That single line covers almost everything these tools are used for, and the rest of the essay argues with what’s left over.
Her taxonomy of AI app-builders (full-stack generators, visual builders, design-native tools) is accurate and worth keeping. My disagreement is with the scorecard she builds on top of it:
Rework was only expensive because artifacts were
The old design-to-development pipeline was continuous for an economic reason: a high-fidelity mockup cost a designer-week, so abandoning one was irresponsible, so every artifact had to earn reuse downstream. The wireframe fed the mockup, the mockup fed the spec, the spec fed the build. Then, handoff existed as a ritual both designers and engineers endured because artifacts were too expensive to throw away.
Generation now costs minutes. So at that price, reuse stops being a virtue and there is no sunk cost left to protect. What still costs something is the judgment wrapped around the artifact: deciding what the AI should build, and recognizing what is wrong with what it returns. I’ve argued in a previous article that judgment is the asset the whole AI economy is repricing, and the prototype question is that thesis at desk scale.
Re-read her three survival questions with that inversion in mind:
“- Can the prototype be extended without starting over?
- Can it be handed off without reinterpretation?
- Can it live outside the tool that created it?”
>> All three price the artifact but none of them prices the decision it produced. A prototype that dies after thirty minutes, having ended a three-week internal debate, delivered more value than one that limps into a codebase carrying an unexamined assumption.
The tool puts the process on trial, bye bye handoff?
Ask whether a prototype can survive handoff and you have already assumed that handoff remains a stage.
AI entered the profession’s story as a faster way to produce the same artifacts, and it keeps being graded that way, while the pipeline those artifacts served was itself a workaround for their old price. I documented the same pattern in research methodology, where methods stay calibrated to conditions that stopped holding and the templates keep running on inertia.
AI moved the prototype upstream and handed the artifact to more people, earlier, cheaper, with less attachment. The polish that reads like ambition to graduate into the codebase is a side effect of price: fidelity got cheap, so everything looks finished. Mistaking that finish for intent is how a thirty-minute artifact ends up audited against production criteria.
Two people could make these prototypes, only one should
The first is a researcher with a recommendation. Before AI, that recommendation shipped as a slide deck with a lo-fi sketch, because anything richer required designer time no one would spend on a proposal that might die at the next prioritization. Now the recommendation can be experienced. The request designers keep hearing in rooms is some version of “I don’t want a recommendation deck, show me the thing.” Meeting that demand matters more than it sounds, because every gap between artifact and product is space where a non-expert bridges with imagination and lands on assumptions you will spend a quarter correcting. The closer the artifact sits to the final look, the less imagination gets invited. That’s a good thing for product teams.
The second is a designer with a proposal: research findings, stakeholder feedback, and their own knowledge, built into candidate directions. Ten mockups in an hour means no emotional stake in any single one. The sunk cost fallacy, the oldest distortion in design critique, starves.
I have never been in a designer’s room
where the understood purpose of these artifacts was handoff-ready code.
The expertise did not travel with the tool
Anyone can technically generate the prototype now, including that researcher. Generating a good one is a different job. It requires knowing what to give the model, and it requires the eye that catches the flaw in what comes back: the interaction that can’t exist, the pattern that violates the platform, the technical dead end, the accessibility nightmare. An expert spots those at the prototype stage and corrects them before the stakeholder review, at a cost of minutes. Both acts, the selection and the catch, are design judgment.
A research job that ends in a prototype
is a design job with research as a prerequisite.
The pushback these tools generate from designers starts to make sense here: they have never had more responsibility in the product pipeline, and are still held to old frameworks that don’t let them deliver on it. The public conversation covers what the machine generates, while the actual job now lives in what the designer chooses to give it and what she refuses to accept back. That choice is the design act. And choice requires taste, knowledge, expertise that are not, and shouldn’t, be expected from researchers.
Let the old UXR process die, too, as we’re at it
This whole reflection comes back to our collective reluctance to face the fundamental change AI-generation tools imply. They are accelerants that question the validity of UXR steps themselves. I have heard designers argue that lo-fi wireframes still have value in a world where we can generate final looking screens in seconds. They are clinging to old paradigms that make no sense from a client / business perspective. At this point, it’s thinking about the craft more than the needs and expectations. We are designing for outcomes, not for process. Process-first practice is what Art does.
Some things are easier to translate from before AI, the mental model is the same or close enough, so they encounter less pushback: a look-and-feel prototype from Figma Make or a Claude artifact plays the role the Figma click-through always plays, and a clean one carries research-reviewed content the way a linear-quality mock always has. Design at the service of Research, following Research’s script, the way Research has always used design’s material.
But it works only for static. It crumbles as soon as you are testing dynamic systems: embedded intelligence can’t be scripted.
From a process standpoint, UXR is fundamentally testing hi-fi products. To simplify, the useful outcome is a set of concrete instructions for the code (personality for a bot, dynamic decisions for an interface etc.). The model needs to be coded first. The UI is a prerequisite for testing. Technical expertise precedes research, limits research. The order of things is disturbed.
Read more about how to test for dynamic system using red-teaming here.
Even that artifact stays disposable. A live-model sandbox is an afternoon of work and an API playground. The new shape of UXR for dynamic systems is a different conversation that I won’t expand in this piece, but that, again, puts the designer (and engineer) at an earlier place in the product pipeline.
It’s hard to hear for most teams, because it feels uncomfortable for people who see that reorganization, as inevitable as it is, as a threat to their influence.
The prototype that refuses to die
Her essay closes with advice for product teams: evaluate AI tools by whether their prototypes can survive, prefer output that engineers can extend, code that can leave the tool that made it. The cost she wants teams to avoid is the rebuild, when engineering rewrites what the prototype already showed.
In working teams, the hazard is a vice president who sees a polished demo once and wants it on next quarter’s roadmap, because it already looks shipped. The demo was built in an afternoon to test whether an idea lands and now it’s a committed feature.
Following her advice would make that scenario more likely. A team that treats prototypes as future production code teaches its stakeholders that a finished-looking demo is progress toward shipping. The VP asking “why isn’t this live yet” has learned that lesson perfectly. The team’s one protection is the shared agreement that prototypes are disposable: the demo arrives labeled as an experiment, and “it looks done” has an answer, which is that it was never on the road to production.
Better code underneath makes it worse. The prototype answered an ideation question. It never asked whether the feature is accessible, whether it fits the technical environment, whether it survives the hundred constraints production exists to honor. Those questions got asked during the rebuild, the exact step her essay counts as waste. Remove the rebuild and the unexamined assumptions ship with the demo.
When a team runs a paper prototype, no one audits it for accessibility or compatibility with the tech stack, and no one asks why the pencil came in the wrong color. The AI prototype deserves the same courtesy. It was built to answer a question and die. Let it.
NA: AI-assisted tools were used for transcription, reference formatting, and language editing. All intellectual content and conclusions remain solely the author’s.