A Director of Growth at a sales intelligence platform described what happened when his PMs picked up vibe coding. His PMs were super competent, super skilled, and they were vibing on every shift the team was working on. Then: “But I didn’t see anything.” The prototypes were getting built. The product wasn’t moving.
He’s not the only PM-adjacent leader who has said a version of that sentence to me. The pattern shows up in discovery call after discovery call. The PMs are doing the work. The vibe-coded artifacts are getting made. Somewhere between the artifact and the production product, the work disappears.
Vibe coding has done what every product blog said it would do for PMs. It has made the gap between an idea and a working version of the idea smaller than it has ever been. Lovable, Bolt, v0, Replit – pick your tool. A PM with no engineering background can describe what she wants in plain English and watch it appear in a browser tab in twenty minutes. The on-ramp is real. The on-ramp is the easy part.
Jackie Bavaro’s Substack essay on vibe coding for product managers is the most-shared piece in this category for a reason. She walks PMs through the on-ramp – picking a tool, learning to think about what you’re building, treating the AI as a peer instead of a magic box. If you have not read it, read it. Jackie wrote the intro. This piece picks up where she leaves off, when the prototype works and you have to do something with it.
The vibe and the ship are two different jobs
The thing nobody warns the PM about is that the prototype lives in one stack and the product lives in another, and the gap between them is filled by an engineer rewriting everything from scratch.
This has become a pattern in the discovery calls. Two weeks of polished prototyping. The output to engineering: a screenshot and a request to start over. The engineers on the other side of the handoff are not impressed. They have just been asked to rebuild something that already exists, in a different framework, against a different set of constraints.
This is a property of how vibe-coding tools are designed. The tool builds in its own framework. It writes its own TypeScript or whatever the model defaults to that day. It uses its own component library. It has no idea what design system the customer’s product runs on. It does not know the auth model. It does not know what the backend exposes. It does not know the file structure or the lint rules or the fact that this team uses kebab-case for component files because of a fight someone had in 2022. It builds something that looks like the product. It does not build something that is the product.
The handoff moment is the critical one. The vibe-coded artifact ends the PM’s work, but it does not start the engineering team’s work on the actual code. The artifact – still a screenshot, a Loom, or a spec – is the brief for a rebuild. The “validated prototype” was validation of an idea, not validation of code. That is fine if the company has staffed for throwaway prototyping.
For a longer breakdown of why a tool that runs in its own sandbox produces this pattern and a tool that runs against the real product does not, see Else vs Lovable. The shape of the ship problem is the difference between those two designs.
What shipping actually requires
What “ship” requires inside a B2B SaaS codebase is specific and unromantic.
It requires components from the real design system, not lookalikes. It requires auth wired through the real provider, not a stub. It requires API contracts that match what the backend already exposes. It requires code in the repo’s existing conventions – the file structure, the import rules, the testing patterns the team already uses. It requires a diff small enough that a senior engineer can review it in fifteen minutes without losing trust in the rest of the codebase.
The vibe-coded prototype gives you none of those by default. It is optimised for the demo. It passes the test of “does this look right when I show it to my CEO?” It fails the test of “can engineering merge this?” For the pattern of what happens when design systems reject lookalike components, see the start-over post.
The first test earns the PM a thumbs-up in Slack. The second test moves the product. The current generation of vibe-coding tools is good at the first and was not built for the second. PMs are starting to notice. The pattern in our discovery calls is no longer “vibe coding is amazing.” It is “vibe coding is amazing and then we’re stuck.”
The stuckness has a shape. It looks like a Loom video, a Figma frame, a paragraph of acceptance criteria, and an engineering team that says some version of: cool, we’ll get to it. The PM has done the harder thing in the workflow – figured out what the change is, validated it visually, gotten a stakeholder to buy in – and the work that remains is the work that vibe coding promised to make optional. Translation. Re-implementation. Throwaway code becoming sketch material for someone else’s real code.
There is a category-level reason this keeps happening. The vibe-coding tools were built for the open web first. The demo had to work for someone with no codebase. That meant the tool needed its own sandbox, its own framework, its own auth story, its own everything. Once that was the default shape of the product, retrofitting it to meet a real B2B SaaS codebase on its own terms was not a small change. It is a different product. The PM downloading Lovable to prototype a flow inside her real product is using a tool that was never designed to land inside her real product. It is doing exactly what it was built to do. The mismatch is structural, not a bug.
What the PMs who actually ship do differently
There are PMs who are getting vibe-coded work into production. The pattern is not a surprise once you see it. They use tools that are connected to the real codebase. Not running in a parallel browser tab. Inside the product, against the real design system, against the real backend, opening real pull requests against the real repo.
The cleanest example I know of is Drew Muller, a PM at Ferry International. Drew has shipped production pull requests through a tool that prototypes on his actual codebase. Engineering reviewed the PRs. They merged with zero code changes from the engineering team. Drew’s public quote: “With Else, we went from validated prototype to production PR in a fraction of the time it used to take. Engineering didn’t touch it until it was ready to merge.” For the full use case, see shipping production PRs without engineering rewrite.
The interesting word in Drew’s quote is “didn’t.” Engineering didn’t touch the prototype. They reviewed the PR. That is a different role for engineering than the one in the “annoyed engineers” sentence above. In one model, engineering is the rebuild team. In the other, engineering is the merge team. The tool decides which model the team gets, because the tool decides what the artifact is. A screenshot produces rebuild. A PR against the real repo produces merge.
The PMs who ship vibe-coded work are not better PMs than the ones who don’t. They are using something that knows about their codebase. The PMs whose work disappears into rewrite queues are using something that doesn’t.
A few patterns show up in the discovery calls where shipping is actually happening:
The PM picks a tool whose output is the same artifact the engineering team already merges. If the team works in pull requests on a Git repo, the tool opens pull requests on that Git repo. If the tool exports a zip file or pastes code into a chat window, it is not in the same workflow as the engineers it is meant to feed. The artifact has to fit the slot.
The PM treats the design system as the contract. They use the tool’s design-system awareness, not its blank-canvas mode. The PMs who ship know that the moment the prototype renders a button that does not exist in the design system, the engineering review has already lost trust.
The PM builds for the merge, not for the demo. The demo is for stakeholder buy-in. The merge is the point. PMs who default to screenshots optimise for the demo from the first round. PMs who ship optimise for the merge from the first round.
None of these are heroic moves. They are the mundane work of choosing tools that match the workflow on the other side of the handoff. PMs are good at this when they think about it. They are not always asked to think about it, because the vibe-coding category is still being sold mostly on the strength of the demo experience.
A note on what this means for the category
The vibe-coding-for-PMs category is going to split. One branch stays as it is – tools optimised for the demo, the share link, the validation conversation, the “I built this in a weekend” LinkedIn post. There is a real and growing audience for that. PMs who want to think out loud in code, founders prototyping side projects, designers who want to see a flow before they spec it.
The other branch is the ship branch. Tools that connect to a real codebase, respect a real design system, talk to a real backend, and produce an artifact that engineering can merge. Those tools will get bought by product organisations who have decided that throwaway prototypes are not the deliverable they want from PMs anymore. The deliverable is a PR.
Both branches will exist. PMs will end up using both, the same way most PMs already use both Figma and Notion. The mistake is treating the two branches as the same product. They are not. The first one is a sketch tool with a great model behind it. The second one is part of the engineering workflow. Knowing which one you are reaching for, before you start, is most of the work.
Closing field note
The Director of Growth from the open – the one who said “I didn’t see anything” – built his own micro-SaaS the same year he watched his PMs vibe-code shifts that never shipped. He vibed it himself. It worked. He shipped it.
The difference between his side project and his team’s prototypes was not skill. It was that his side project did not have to land inside a real product run by a real engineering team. He could merge his own pull requests. His PMs could not. The vibe was the same. The ship was the company they worked for.