Naval Ravikant said it last week: "Vibe coding is the new product management." 40k likes. Everyone on LinkedIn shared it.
He's partially right. But he's missing the dangerous part.
What is vibe coding?
Quick definition: you describe what you want in plain English, AI generates the code. Cursor, Bolt, Replit — the tools change but the logic doesn't. No technical skills required. You say "send an automatic SMS when an appointment is canceled" and the system flow appears.
The term emerged in early 2025. In 2026 it's genuinely reshaping how product work gets done.
And yes — it's powerful. I've used it.
I needed to test a user flow. Built a working prototype — not a Figma mockup, an actual clickable thing. What would have taken two weeks in a sprint got done in three hours.
The first time you experience this, it genuinely feels like something shifted.
Here's the problem:
When build speed increases, pressure accelerates too. Your manager sees a prototype and "why isn't this live?" arrives much earlier. Vibe coding multiplies a PM's build capacity by 10x. It doesn't multiply learning capacity.
That's the breaking point.
You can ship 10 features in 10 days. But which one actually solves the user's real problem? You still have to test. You still have to talk to users. You still have to say no.
A concrete example:
Say you're building dental practice software. Dentists are managing appointment cancellations manually — losing time, losing revenue. Classic scenario.
With vibe coding, you can produce three different cancellation flow prototypes in an afternoon. Different notification timing, different UI, different logic.
That's a superpower.
But shipping those three prototypes without sitting down with a dentist for 30 minutes first isn't speed — it's expensive guessing. Because the real problem might not be in the cancellation flow at all. It might be in pre-appointment reminders. And you only discover that by talking.
Vibe coding doesn't skip that conversation. It just means you spend less time building. And the time you save gets absorbed by amplified pressure to ship before you've validated anything.
On Naval's claim:
PMs can now build the product themselves. True.
But the core PM responsibility hasn't changed: deciding what to build and why.
Think about two PMs. One ships five features a week with vibe coding. The other ships one — but tests each with real users, challenges their own assumptions, breaks their own narratives.
Who builds the better product six months from now?
The second one. Almost every time.
The numbers:
CMU published a striking finding in early 2026: AI-generated code has a 1.7x higher bug density than human-written code.
Vibe-coded products ship fast. They break more too.
Users feel that brittleness. And they usually feel it in the first two weeks — when course-correcting is most expensive.
Where the real shift is:
What did vibe coding actually make PMs?
Faster hypothesis testers. Not better engineers.
Before, we'd say "build it, then we'll test it." The new trap is: "I can build it myself, so why wait to test?" Speed creates the illusion of progress.
Here's what I've noticed: the most dangerous PM isn't the one who can't build anything. It's the one who builds everything too fast and forgets to ask why.
The constraint didn't change:
The tool got stronger. But the decisions you still have to make didn't change.
What problem are we solving? For whom? How will we know if it's working?
Vibe coding doesn't start answering those questions for you. Asking them is still your job.
Is vibe coding the new definition of product management — or its biggest trap? Is your team shipping more features, or learning faster?