A Director of Growth at a sales intelligence platform was describing how his PMs had taken to vibe coding. He led with who they were: PMs doing data science. Super competent, super skilled. But he didn’t see anything.
Most writing pulls that sentence as a PM-fluency complaint. Erik meant the opposite. His team had picked up the tools instantly. They were vibing on every shift the team was working on. The prototypes were getting made on pace. Two quarters in, he could show me the output rate. The roadmap had not moved.
The standard response to this pattern is a training programme. More enablement. More PM fluency. A higher bar for who gets hired into the role. Erik’s PMs had already cleared every version of that. They were producing an artifact the real product could not receive.
What “the work disappears” actually means
The prototypes did not disappear. Erik could pull them up. Screenshots. Loom recordings. Figma frames that linked to Lovable previews. They were there.
What disappeared was the path from prototype to shipped. Engineering would look at the output, confirm that the idea was right, and start the build from scratch. Or they would look at the output and not know where to begin — because the prototype was built on a different stack, against a different component set, with no connection to the production repo. There was no PR to review. There was no diff to approve. There was a brief.
So the PM’s work became the spec for a rebuild. Two weeks of prototyping became two pages of acceptance criteria. The artifact that was supposed to compress engineering time became the input document for engineering work that looked exactly like it always had.
When Erik said he didn’t see anything, he meant this: the roadmap feature count had not changed. The sprint cycle had not changed. Engineering was not any faster. The PM had spent real time building something. That thing was not the thing that shipped.
Why the architecture produces this outcome
This is not a PM execution problem. It is a tool architecture problem.
Vibe-coding tools were built for the open web first. The demo had to work for someone with no codebase — a founder with a blank prompt, a designer building a concept, someone who wanted to see an idea working in a browser tab within twenty minutes. For that use case, the tool needs its own sandbox: its own framework, its own component library, its own auth story, its own deploy path. The tool builds the whole stack because there is no existing stack to build on.
That shape is the right shape for that job. It is the wrong shape for a PM at a B2B SaaS company who needs the prototype to land inside a product that already runs, built by an engineering team that already owns a codebase.
When that PM downloads Lovable or opens Bolt, she is using a tool designed for a blank-prompt founder. The tool does what it was built to do. It produces something that looks like the product. It does not produce something that is the product. The prototype runs in Lovable Cloud, not in her company’s staging environment. It uses Lovable’s component patterns, not her company’s design system. It has no connection to the Git repo engineering merges against.
The gap is not something a better prompt can fix. The gap is structural. The tool was designed to produce a parallel artifact, and that is what it produces.
What the teams that do ship have in common
Across the discovery calls where PM-built work actually makes it into production, the pattern is consistent.
The PM is using something that knows about the codebase. Not running in a parallel tab. Inside the product, against the real design system, opening pull requests against the real repo. Engineering sees the work as a diff — the same diff format they review on every other PR. They merge it or they don’t. There is no translation step.
Drew Muller, a PM at Ferry International, has shipped two features into production with zero code changes from engineering before merge. The reason is not that Drew is an unusually skilled builder. The reason is that the tool he used produced an artifact in the same slot as a PR. Engineering did not have to rebuild what Drew had already built. They reviewed it and merged it.
That is what Erik’s team was missing. The output rate was real. The artifact was wrong. Not wrong in content — wrong in format. A Lovable URL is not a pull request. A Loom video is not a diff. No amount of PM fluency turns a preview link into a mergeable branch.
The thing worth tracking
The canonical piece on what PMs who actually ship do differently is Vibe Coding for Product Managers: What Happens After the Prototype Works. The tool architecture that makes the handoff possible appears in Else vs Lovable.
Erik had watched his team output at a rate that should have moved the roadmap. It did not. Super competent. Super skilled. But I didn’t see anything.
See also: Pattern: Design Said Start Over — a second-order consequence of the same gap, when the prototype makes it past PM but fails design review before it reaches engineering.