Within the same few months of 2026, two of the biggest names in AI-assisted prototyping quietly abandoned the thing that made them prototyping tools in the first place: disposability. On February 3, Vercel rebuilt v0 around importing real GitHub repositories, opening a branch per chat, and merging pull requests straight into main. Three months later, on May 28, Figma shipped a Mac-only beta of Figma Make that commits branches and opens PRs against a company’s actual production codebase without leaving the design canvas. Two products that sold themselves on how fast they could produce a throwaway version of an idea now sell themselves on how directly they can skip the throwaway part.
Vercel and Figma both named the prototype as the problem
Vercel’s own framing is unambiguous about what it thinks it was fixing. In Introducing the new v0, the company states plainly that “prototypes fail because they live outside real codebases, require rewrites before production, and create handoffs between tools and teams,” and pitches the new Git panel — branch per chat, PR against main, deploy on merge — as the cure, so that “every prompt generates production-ready code in a real environment, and it lives in your repo.” TechBooky’s coverage sharpens the stakes further, quoting Vercel CPO Tom Occhino calling the prototype-to-production gap “the world’s largest shadow IT problem,” and noting that over four million people had used v0 to build “millions of prototypes” that mostly needed rewriting to become real. Figma’s language is gentler but points the same direction: its Figma Make announcement frames the addition as dissolving the boundary entirely — “the canvas and the codebase, in the same place. There’s no right place to start. There’s just the work.” Read together, both companies are saying the same thing in different registers: the disposable prototype, the artifact you could throw away without consequence, had become the product’s biggest liability rather than its selling point.
That’s a real reversal of the pitch that built these tools. Instant prototyping worked as a category because it promised cheap, judgment-free exploration — you could generate ten ideas, discard nine, and nobody had to account for the discarded nine as technical debt. Rebuilding that exploration around branches, PRs, and merge-into-main is not a neutral feature addition; it re-imports the exact governance overhead — code review, ownership, migration planning — that prototyping exists to defer. A prototype wired into a real repo is safer to promote, but it is no longer free to abandon, and the tools are being redesigned around the assumption that abandonment, not promotion, was the failure mode worth engineering away.
The disposability-as-bug argument has real force
The strongest challenge to that reading is that disposability was never the virtue people nostalgic for prototyping remember it as — it was mostly wasted rework dressed up as flexibility. Vercel’s own diagnosis supports this: prototypes that “live outside real codebases” and “require rewrites before production” aren’t disposable so much as duplicated effort, work done twice because the first pass was structurally incapable of becoming the second. Practitioner write-ups echo the point, arguing that teams shouldn’t throw away a prototype when most of what an AI built already has value worth keeping rather than re-deriving. If the old model was really a governance hole — Occhino’s “shadow IT problem” — dressed up as creative freedom, then wiring generation into real infrastructure from the start is a straightforward improvement, and treating the throwaway prototype as sacred is closer to sentimentality than to sound engineering practice.
A prototype wired into a real repo is safer to promote, but it is no longer free to abandon.
Generation got cheap; deciding what deserves to exist didn’t
What that framing leaves out is where the actual bottleneck sits once generation is nearly free. The Vibe Coding in Product Teams study, an interview study of 22 product-team members across enterprises, startups, and academia, maps a four-stage workflow — ideation, generation, debugging, review — and finds the reported friction concentrated not in producing an artifact but in validating and integrating it: code unreliability, integration difficulty, and over-reliance on AI output are the recurring complaints, and effort visibly shifts toward reviewing what the model generated rather than authoring it. That’s the gap neither Vercel’s Git panel nor Figma Make’s branch-and-PR flow actually closes. Both tools make it dramatically cheaper to produce something that looks shippable; neither one helps a team decide whether the idea behind it should exist, whether it solves the right problem, or whether it’s worth the review it now formally requires. As Figma’s blurring of the design-to-dev handoff already suggested from a different angle, collapsing the distance between an idea and its shippable form doesn’t collapse the judgment required to use that shortcut well — it just moves the judgment later, dressed as a pull request instead of a decision.
