Title card reading 'The Rapid Prototyping Loop'. Three labelled paths (Figma Make, Replit and Claude) converge into a single arrow pointing at a browser window with working toggles and a primary button.

AI Prototyping Discovery

Revolution in Rapid Prototyping

Figma Make, Replit and Claude: how PMs went from specifying software to building and validating it

Ody Bozhenko

12 Aug 2026 · 13 min read Published

Ten to twenty product ideas tested a week. That’s the bar Marty Cagan sets in Inspired, and for most of the last decade it read to me like a number from a different industry.

“To set your expectations, strong teams normally test many product ideas each week — on the order of 10 to 20 or more per week. […] these experiments, typically run using prototypes.”

Marty Cagan, Inspired, p. 28

It’s one of those lines you dismiss the first time you read it. Not because the principle is wrong. Prototyping has been the centre of how I work for ten years: Marvel App, then Figma, wiring screens and my designers’ work into something a person could click. The goal never changed. Iterate as much and as fast as possible before handing anything to engineering.

The problem was the maths. It took me hours to make something clickable enough to put in front of Sales, Marketing, Design or a stakeholder. Ten to twenty of those a week wasn’t a stretch goal. It was a different job.

And the gap was always visible. What I showed people and what users eventually met in production were never quite the same thing. Not because the prototype was badly made. Because people can only truly evaluate a product in the environment where they’d actually use it. A clickable mockup asks you to imagine the rest. The real thing doesn’t have to ask.

That gap is what closed.

I wrote a product requirements document last October that no human ever read.

It lived in Confluence and it had everything a PRD is supposed to have. Page structure. A field table with types and validation rules. Empty states. Loading states. Test cases. The exact wording of the success toast and the failure toast. It even specified that ten percent of requests should fail at random. I wanted to see the error path, and error paths are the thing nobody ever demos.

Then I pasted it into Replit and went to get coffee.

By the time I came back, the integrations tab of our dealer platform existed at a URL I could send to anyone. Not a picture of it. It. Toggles that toggled, a search box that filtered, pagination that held its place, and a red toast that appeared roughly one time in ten and said the thing I had written it should say.

So I stopped treating it as a demo and took it to users. My business developer and I ran it with real customers in a single session. Changes surfaced immediately, the way they only do when someone’s hands are on the thing. Our UX designer and the engineering team picked it up from there, and by the end of the following week the new flow was live.

The document hadn’t stopped being a spec. It had stopped having a human audience. And the deliverable at the end of that afternoon wasn’t a ticket asking someone else to build the thing. It was the thing, running, in front of three stakeholders who would otherwise have spent a week arguing about it in the abstract.

That afternoon is the clearest example I have of a change I’ve been watching for about eighteen months. We talk about it as speed. It isn’t speed.

Five handoffs in a chain, replaced by one loop you run in a single sitting.

The loop we used to run, and what it actually cost

The traditional path from idea to evidence had four handoffs in it, and every one of them was a queue.

You wrote the PRD. You booked time with design for wireframes. You pitched for a sprint slot against everything else in the backlog. Weeks later something clickable existed, you showed it to users, and you learned the thing you could only ever learn by showing it to users: that the second screen was confusing.

Then you went back to the top of the queue.

The economics of that loop were brutal in a way we mostly stopped noticing. Because each round was expensive, you ran few of them. Because you ran few of them, you had to be right early. Because you had to be right early, you spent the cheap part of the process (thinking) defending a single idea instead of generating several.

And here’s the part I find uncomfortable in hindsight: we’ve known for thirty years that this was the wrong shape.

Jakob Nielsen’s iterative design research is the number everyone quotes: roughly 38% usability improvement per iteration in his 1993 study, and about 22% in a later website case study. Useful, incremental, exactly what you’d expect.

But NN/g also measured a different approach. In parallel design, several designers independently produce competing interfaces. Then comes the part that always gets dropped in the retelling: you merge the best parts of each into one design instead of picking a winner. In their 1996 study, four parallel versions were produced. The merged design measured 70% higher usability than the average of the four originals. One iteration on top of that took it to 152%.

Seventy percent from a single round. Against twenty-two.

Parallel design won, decisively, and almost nobody ran it. Not because product people were ignorant of the research. Because building four designs cost four times as much as building one, and no one could justify throwing three of them away.

“That was never a knowledge problem. It was a price problem.”

What the old loop taught us:

Iteration count was rationed by build cost, not by how much you had left to learn
Being right early was a budget constraint dressed up as a professional virtue
Every handoff in the chain was a queue, and queues are where conviction goes stale

That price is what collapsed.

The new loop

The reason 2026 feels different isn’t that one tool got good. It’s that the tools stopped starting from a blank page.

Figma Make, Replit, Claude Code, Claude Design. What they now have in common is access to the context that used to live only in my head and in my team’s repositories. The design system. The architecture and logic of the actual source code. The markdown files where I keep the expected end-value and the user needs. The output isn’t a picture of a user flow any more. It’s a working user flow that behaves like the real platform.

Which is exactly why the gap I described at the top closed.

Ten years of prototyping, measured by the one thing that mattered: how much the user still had to imagine.

A short tour of the ones I actually use:

Figma Make solves fidelity. The advantage isn’t prompt-to-app; plenty of tools do that. It’s that the prototype is built from your existing components, colours and type, so it looks like your product rather than a generic AI demo. That decides what feedback you get: show someone a generic mockup and they critique the buttons, show them something that looks like what they already use and they critique the idea. In large organisations the design system lives in Figma, and Make is the cheapest way to get it into whatever you build next. Figma’s own team makes the argument directly, in a post titled “Prototypes Are the New PRDs”: the spec that reaches engineering is a Make file plus designs.

“You're not shipping the code, but you're tightening the build-measure-learn loop.”

Ezra Mechaber, Product Manager, Figma

Replit solves behaviour. Figma Make will convince you something looks right; Replit will tell you whether it works when there are four hundred rows, or when the request fails, or when two people hold conflicting state. You get a real backend, a real database and a URL you can put in Slack. That URL matters more than the stack does. A link a stakeholder can open on their phone in a meeting is a completely different thing from a screen-share.

Claude Code solves context, and it’s the one PMs underrate. Figma Make and Replit both start from a blank page plus your prompt. Claude Code starts from your repository, your research, your last six months of notes sitting in markdown files. When I want a prototype to reflect how the product actually behaves, not how I remember it behaving, that’s the only one of the three that can read the code and tell me I’m wrong.

Claude Design, which landed in April, closes the loop. It reads your codebase and design files once, builds a design system from them, and packages a handoff bundle you can pass straight to Claude Code.

The revolution isn’t any one of them. It’s that a flow which used to cross four teams now crosses three tabs, and nothing is lost in the crossings. Uber’s product organisation reported the same cluster of tools after a year of running this across their org: Lovable, Figma Make, Claude Code and Cursor. Nearly 40% of the submissions at their global tech hackathon used a prototyping tool.

Fewer iterations, not faster ones

Here’s the distinction I keep having to make in meetings, because everybody’s first instinct is the wrong one.

The gain is not that each round got faster. The gain is that rounds stopped being sequential.

When a concept costs an afternoon, you don’t build the best one you can think of and then refine it. You build four. Uber’s write-up has the sharpest version of this: a product manager on their Business Platform team described exploring “six distinct concepts for the same problem in about 20 minutes.” That is parallel design, the method NN/g measured at 70% and everyone shelved as unaffordable. Running casually, before lunch, by one person who isn’t a designer.

The knock-on effect is the one that actually changes your quality before launch, and it’s about the conversation. Uber describe conversations moving quickly from “what is this?” to “is this the right approach?”, and one of their merchant PMs summarised a session as two hours of prototyping unblocking four weeks of discussion. I recognise that number uncomfortably well. Most of the four weeks in my own past projects wasn’t disagreement about the right answer. It was five people holding five different mental images of the same sentence.

And then there’s the detail from my own October afternoon that matters most. I specified the empty state, the loading state, the double-click guard and a ten-percent random failure. In a throwaway. In the old loop none of that would have made the first prototype. It would have surfaced in QA, or in production, as bugs, because edge cases are the first thing you cut from something expensive.

When the prototype is nearly free, you can afford to prototype the failure modes. That’s not shipping faster. That’s arriving at the sprint having already found the things that would otherwise have been found by users.

We didn’t get faster at guessing. We stopped having to guess.

Asking for the keys

There’s a ceiling on all of this, and it has a name in the PM community: the prototype on an island.

Generic components, styling that doesn’t match, no awareness of your conventions. Beautiful in the demo, worthless as a foundation, and quietly misleading in user testing because people react to the newness rather than to the change. It’s the standard critique of prompt-to-app tools and it’s largely fair.

The fix isn’t a better tool. It’s access.

The moment that changed my own practice wasn’t a product launch. It was my engineers green-lighting me to run our whole platform locally, with a standing offer to push PRs if I dared. Two years ago that sentence would have been a joke at my expense. What it bought me was the ability to prototype against real components, real styles and real data shapes, so what I put in front of a user is a plausible future version of our product rather than a nice-looking stranger.

The payoff wasn’t abstract. Take the complex business flows, the kind that used to mean a slide deck and three rounds of design review with everyone nodding at a different version of the idea. I started bringing a working prototype instead: real environment, real data, in front of actual end users and customers. That one change did more to cut friction between Product, Sales, Marketing, Design, Engineering, our stakeholders and the people who’d actually use the thing than any process change I’ve tried in ten years of doing this job.

This is where the community consensus has landed too. Colin Matthews’ team-wide prototyping playbook makes the same argument: prototype inside your real codebase, mock the API responses, accept the more complicated setup. It’s more friction on day one, and it’s the difference between a prototype that answers a question and one that just entertains a room.

That was my experience, with my engineers, in my org. It isn’t a formula, and I’d be suspicious of anyone telling you three tool names and one access request is a universal fix. Some engineering orgs have real reasons to say no: compliance, security review, a codebase nobody wants a non-engineer touching. If the answer where you are is no, that’s information, not a sign you didn’t ask hard enough.

What the revolution doesn’t fix

I’d be writing marketing copy if I stopped here. So here are four things it doesn’t solve, in order of how much they can cost you.

A prototype is evidence, not a verdict. Uber list “prototype seduction” (mistaking a mockup for a decision) first among their five pitfalls, alongside skipping the why, anchoring bias, poor collaboration, and the assumption that prototyping is free. The failure mode is specific: something looks finished, so the room stops asking whether it should exist and starts asking when it ships. A convincing prototype has stopped being an experiment.

I know that failure mode from the other side, because for years it was the normal state of affairs. A low-fidelity prototype went into a room, the majority were satisfied, it got approved, and then production told a different story. Nobody had lied in that room. We had agreed about a drawing, and the drawing had never been the product. What live prototyping changed isn’t that approval got easier, it’s that the discussion moved off the artefact and onto the goal. The seduction risk didn’t go away, it just got better dressed. What you gain is that the disagreements you flush out are the real ones, surfaced while they’re still cheap.

The code is a first draft. Veracode tested more than 100 models and found that AI-generated code introduced security vulnerabilities in 45% of cases, a rate that hasn’t improved since. That’s not an argument against prototyping. It’s an argument against the sentence your prototype will provoke every time. “It already works, can’t we just ship it?” You are the person responsible for answering that one.

The PRD didn’t die. It changed audience. My October document was more rigorous than most specs I’ve written for humans, not less, because a build agent won’t infer what you left out. Uber reach the same conclusion in one line: “This did not replace PRDs or design reviews. It strengthened them.” Engineers still need acceptance criteria, edge cases and component requirements, and none of that is visible in a clickable demo.

Speed was never actually the point, for me. There’s a sharper critique of this whole article than “the prototype might mislead you,” and it’s worth naming directly: if AI prototyping is easy for you, it’s easy for every other PM too, and once everyone can explore fast, exploring fast stops being what makes you good at the job. Spend the time it frees up on faster building instead of sharper discovery, and you’re optimising the wrong variable. I think that’s a fair challenge, and I don’t think it lands cleanly on my situation. My product runs across three countries and millions of users, and a meaningful share of what I ship touches financial risk, compliance and external vendors. I can’t push a flow to production and see what happens. Some of it has to be right before a single customer touches it, not just fast. So the speed in this article was never about outrunning another PM. It was about compressing an expensive, slow, stakeholder-heavy validation cycle for high-stakes flows into something that fits in an afternoon instead of a quarter. If you’re at a five-person startup, your maths are probably different, and shipping something fast, cheap and imperfect might genuinely be the right call there. For me, building right had to matter exactly as much as building fast, or the whole exercise wasn’t worth running.

“When building is nearly free, deciding what deserves to exist is the whole job.”

What to do Monday morning

Build four, then merge them. Don’t pick a winner. Take the next feature where the team is arguing in the abstract and build four genuinely different versions in an afternoon. Then do the part almost everyone skips: NN/g’s 70% came from merging the best parts of each, not from choosing a favourite. Picking a winner throws away three-quarters of what you just paid for.

Ask for read access and a local environment. Not to write production code, but to make your prototypes stand on your real components. Ask this week; the answer comes back faster and warmer than you expect. I’ve stopped validating design on its own. I build against the design system and the real source code, locally.

Make the design system the floor, not the finish. Every prototype should stand on it and on the real product’s logic. If you don’t have one yet, that’s the actual first task: it’s what turns each prototype from a one-off into something engineering can absorb without re-deciding everything.

Spec the failure path into your throwaway. Empty state, error state, the request that doesn’t come back. It costs you two extra sentences in the prompt and it moves your worst discoveries from production to Tuesday afternoon.

One more thing, because tool names age badly. Figma Make, Replit, Claude Code and Claude Design are this idea’s current shape, not its final one. In six months two of them will have merged, been renamed, or been replaced by something better, and the version of this article I’d write next year will probably name three different tools. What won’t change is the underlying shift: a prototype built with real context beats one without it, and validating early beats defending an idea in a room. Don’t get attached to the stack. Get attached to the habit of trying whatever closes the gap further next. This isn’t the destination. It’s one step, and the next one is already on its way.

The prototype stopped being a picture of the product. For an afternoon at a time, it is the product. The only question left is which of the four you should have built.

More on AI in product management in the articles ahead. If you see it differently, reach out.