A PM for a learning platform was telling me how her team’s most recent prototype had gone. They had built it fast. They had been proud of it. Then the design team got involved: that doesn’t follow our design standards. You need to start over.
Design then offered to come in and turn the prototype into a design-approved prototype. They were busy. They were slow. The PM team waited a few weeks, decided the wait was killing the work, and pulled the prototype back to rebuild it themselves against a design spec. The other three PMs on the team got locked out of that round of the work because they did not have the technical fluency to make the design-approved version.
The prototype was real. The visual flow was real. The validation conversation with stakeholders had already happened. None of that survived first contact with the design system.
This pattern is the most reliable way I know to predict whether a vibe-coded prototype is going to ship. If the tool generates lookalike components instead of the team’s real ones, design review will catch it and one of two things will happen. Design will rebuild it, slowly. Or the PM team will rebuild it themselves, also slowly. Either way, the PM’s first prototype was not the artifact that got merged. It was the brief for the artifact that got merged.
The pattern shows up across the discovery interviews this year in roughly the same shape. The PM picks a tool – Lovable, v0, FigmaMake, Bolt – because the tool produces something that looks like a real product in twenty minutes. The PM builds the flow. The flow uses buttons that look like the brand’s buttons. They are not the brand’s buttons. The colors are close. The spacing is close. The interaction states are improvised. The tool has done what it was built to do.
Then the prototype enters a room with someone whose job is to enforce a design system. The lookalike fails the system. The system did not exist to be ignored. It existed to keep the product internally consistent across years of work and dozens of contributors. So design says no. Or design says yes and rebuilds it. Or, worst case, design says yes, ship it, and engineering ships a one-off that fragments the design system for the next year.
A PM at a sales engagement platform described the same wall from the other side of the table. He had built mockups in FigmaMake and walked UX through them in a presentation.
The mockups were close enough to spark a design-ownership question that nobody on the team had answered yet. FigmaMake had produced an artifact that required UX to step in and re-scope the work before it could move. The PM had not gained speed. He had moved the bottleneck from engineering to design.
A Lead PM at a customer experience platform described the cleanest version of the same trade in a December conversation. He had a Figma file. He used a vibe-coded prototype to make it interactive enough to test. The prototype did not match the actual product. He knew that going in. The prototype was, in his own words, fine for a quick gut check. It was not fine for a design review. The handoff to engineering was a Loom video and a reference Figma. Engineering rebuilt it.
The pattern is not that PMs are doing this wrong. The pattern is that the tool category was built for a different problem. Vibe-coding tools were built for the open web first. The open web does not have a design system you have to honor. A B2B SaaS product does. A vibe-coded prototype that ignores the system is not a prototype the design team can endorse. A prototype the design team cannot endorse is not a prototype that ships.
The painful part of the cycle is what comes after design approval. When the prototype moves to engineering, the week of polish work – the interactions, the states, the microcopy – all of it disappears in the rebuild, and the designer has to go back and fix what the engineers broke. For how to prevent this by choosing the right tool in the first place, see the AI-prototyping pillar, which covers the polish-protection move.
The pattern has a clean exit. Pick a tool that uses the team’s real components. If the tool reads from the team’s design system or runs against the team’s real frontend code, the lookalike problem disappears. The prototype that comes out is using the buttons that already exist. The colors are right because they came from the source. Design review becomes a question about the design, not about whether the design system is being respected.
The PM at the adult learning company did eventually get her flow shipped. She rebuilt the prototype against the design spec. Three PMs sat the round out. Engineering merged the second version. The first version – the one she had been proud of – was a sketch that earned a meeting and a rewrite.
She told me the part she would change next time was not the prototype. It was the tool. The next prototype her team builds, she wants to know that the components are the real ones before the design team is in the room. Not after. Tools that pull from the design system, or from the team’s real frontend code, are the ones she is asking about now. The ones she used last time were doing their job. Their job was to produce something that looks like the real product. The job she needed done was to produce the real product, with one thing changed.
The fix is not negotiating with design. The fix is producing artifacts design has no reason to reject.