Vibe Coding Is Changing What Product Managers Own

What vibe coding actually is, and why it is different

Vibe coding is not "using AI." Using AI means getting help with a Jira ticket, summarising research, or cleaning up a PRD. Vibe coding means describing intent in plain language and getting working software back. No code written by you. No prerequisite technical skill. Just the thing existing.

That distinction matters because the gap between idea and working artefact has always been where PM authority gets tested. Engineers build. PMs describe. Vibe coding collapses that gap. The artefact now appears before the engineering conversation starts, not after.

That is structurally different from any other AI tool in the PM stack.

Three workflow changes that are already happening

The PMs I've seen move fastest with this have changed three specific things.

First, they test assumptions before writing a spec. Instead of a document describing how something should work, they prompt Cursor or Claude Artifacts to build a rough version, click through it themselves, and find the three things that are wrong. The spec that follows is sharper because it started with something real.

Second, they bring richer prototypes into user research. A Figma mock tells a user what something might look like. A working prototype, even a rough one, tells you what a user actually does when left alone with it. The difference in research quality is significant.

Third, they use the prototype as the discovery artefact instead of the PRD. I've seen this work especially well in early conversations with engineering leads. A disposable working prototype communicates intent more precisely than two pages of requirements. It also surfaces technical concerns faster, which is the point.

None of this requires writing a line of code. The skill being applied is still fundamentally a PM skill: understanding what problem you are solving well enough to describe it precisely.

The engineering culture problem nobody is talking about

Here is the uncomfortable part. A lot of PMs are doing this quietly. Building prototypes in a side tool, testing assumptions privately, then presenting conclusions as if they emerged from pure reasoning. That is a mistake.

Engineering teams that discover a PM has been running shadow prototypes feel two things: surprised, and then territorial. The prototype stops being a thinking tool and becomes evidence of a power grab, whether that was the intent or not.

The framing that actually works, based on what I have seen: disposable thinking tools, not deliverables. You are not shipping this. You are not making architectural decisions. You are generating something concrete enough to have a better conversation. Engineers who understand that framing are often relieved, not threatened. It means fewer badly-specified discovery cycles for them too.

The teams that are getting this right are redesigning their discovery process around AI in a way that treats vibe coding as an input to collaboration, not a replacement for it.

The tool stack problem

None of the tools PMs actually live in are built for this. Productboard, Aha!, Linear, Notion, these are all designed around a write-to-communicate workflow. You describe the feature, someone else builds it.

Vibe coding is a describe-to-generate workflow. The output is not a document. It is an artefact. And right now, PMs are duct-taping Cursor or Claude onto their existing stack with no coherent handoff process. The prototype gets built in one place, discussed in another, and then quietly abandoned without ever informing the actual roadmap.

This is a workflow problem, not a tool problem. The tools will catch up. The workflow needs to be designed now. Having AI tools without redesigning the workflow around them just adds noise to a process that was already fragile.

A starting framework that actually works

Not every PM problem is worth vibe coding. The ones that are share a pattern: the core uncertainty is about interaction or flow, not data or architecture. If the question is "will users understand this?" or "is this the right sequence?", vibe code it. If the question is "can we build this within our current infrastructure?", that is an engineering conversation first.

When you have a prototype, do two things before sharing it. Click through it yourself and write down the three assumptions it forced you to make. Then share it with one engineer as a thinking artifact, not a proposal.

Start there. The rest of the workflow will reveal itself quickly enough.