Vibe Coding Won’t Save You. This PM Skill Will.
Everyone’s talking about PMs who can code with AI. But the real skill isn’t writing code - it’s knowing where to point the gun.
The Vibe Coding Trap
Six months ago, I was a skeptic.
When the whole vibe coding wave started, I looked at it and thought - this is terrifying. Someone else’s AI writes your code, you don’t fully understand what’s happening under the hood, and if something breaks in production, you’re the one holding the bag.
I work in travel-tech. When I think about a bug in our flight booking flow, I don’t think about a Jira ticket. I think about money. Real money. A single bug in an airline ticket purchase can cost more than a developer’s monthly salary. So when people started telling me “just let the AI write it,” my gut reaction was simple: no way.
But here’s the thing about gut reactions. Sometimes they’re right. And sometimes they’re just fear dressed up as wisdom.
94% of product professionals now use AI frequently in their workflows. Nearly half have embedded it deeply into their daily work. The tools got better - fast. Claude Code, Cursor, Copilot - they went from “interesting toy” to “legitimate workflow” in what felt like weeks, not months.
And I realized my skepticism wasn’t protecting me. It was holding me back.
But - and this is the part nobody talks about - the opposite extreme is just as dangerous. The PMs who think vibe coding will replace their engineering team. The founders who believe they can ship production software by typing prompts into an AI. The product people who confuse “I can build a prototype” with “I can build a product.”
Both extremes are wrong. And I learned this the hard way.
The real skill isn’t vibe coding. It’s knowing exactly where AI belongs in your product process - and where it absolutely doesn’t. I call it the Precision Placement approach. And it changed how I build products.
The Problem With How PMs Think About AI Coding
Let me paint you a picture of how most product managers approach vibe coding right now.
Camp 1: The Ignorers. These are the PMs who still don’t use AI at all. Not for code, not for docs, not for anything meaningful. If I’m being direct - this is a red flag. If you’re a PM in 2026 and you haven’t found a single workflow where AI makes you better, you’re not being careful. You’re being left behind.
Camp 2: The Replacers. These are the ones reading headlines about “one-person billion-dollar companies” and thinking they’ll fire their dev team by next quarter. They vibe-coded a landing page once and now they believe they can ship enterprise software solo.
Camp 3: The FOMO Builders. This is where I found myself. The ones who see the potential, start building everything, creating side projects, spinning up apps, prototyping features - and then one day stop and ask: “Wait, is this actually moving me forward?”
Here’s the uncomfortable truth I discovered. Vibe coding creates a very specific kind of FOMO. You see what’s possible. You see people shipping products in a weekend. And something clicks in your brain that says - I should be building MORE. Faster. Everything.
But that FOMO is a trap. Because as a PM, your job was never to build everything. Your job is to decide what gets built, why, and in what order. Vibe coding doesn’t change that equation. It just makes the “building” part faster. Which means the “deciding” part becomes even more critical.
Here’s what I mean with a real example.
I manage a Chrome extension for travel agents - it works across GDS systems like Amadeus, Sabre, and Galileo. For over a year, users kept asking: “Is this available on mobile? Can we use it on a phone?”
We kept saying no. Not because it was a bad idea - it was a perfectly good idea. But it was never P1. It never directly impacted revenue. There were always bigger fires to fight - bugs that affected the core booking flow, features that directly moved the needle on retention, integrations that clients were waiting for.
That mobile version was the classic P2 backlog ghost. Important but never urgent. The kind of task that lives in your backlog for 18 months and eventually gets archived with a sad little “won’t do” label.
Then we tried something different. We gave it to AI.
In three days - not three sprints, three days - we had an 80% functional mobile prototype. Working. Usable. Not a mockup, not a Figma file - actual working software that users could touch and click and test.
And here’s the kicker: we spent more time on organizing the repo and setting up the sprint than on the actual development.
That project would have NEVER happened without vibe coding. Not because it was technically impossible. But because in the traditional prioritization model, it would have never earned its spot at the top of the queue. The ROI calculation would have never justified pulling a developer off P1 work.
This is the “aha” moment. Vibe coding doesn’t replace your developers. It gives your P2 and P3 backlog a chance to exist.
Think about that. How many features are sitting in your backlog right now that are genuinely good ideas but will never see the light of day because you can’t justify the development time? Vibe coding changes that calculation entirely.
Precision Placement: The Skill That Actually Matters
So if it’s not about coding everything with AI, and it’s not about ignoring AI entirely - what is it?
I call it Precision Placement. It’s the skill of knowing exactly where AI-generated code belongs in your product - and where it doesn’t.
Here’s how it works in practice.
Step 1: Map Your Risk Zones
Not all code is created equal. In every product, there’s a spectrum:
On one end - features where a bug is annoying but harmless. A settings page that doesn’t save preferences. A notification that fires twice. Ugly, sure. But nobody loses money.
On the other end - flows where a single bug costs real money. In my case, that’s the flight booking engine. A pricing error, a double charge, a failed cancellation - these aren’t bugs. These are financial incidents.
Before you vibe-code anything, map this spectrum for your product. Draw a line. Everything on the “safe” side is a candidate for AI-assisted development. Everything on the “dangerous” side gets human hands, human eyes, human accountability.
The mobile prototype I mentioned? Safe side. Low risk, high learning potential, zero revenue impact if something breaks. Perfect candidate.
The core booking flow? That’s the other side. I get nervous when AI touches that. And I think that nervousness is healthy.
Step 2: Redefine Your Backlog Categories
We started doing something new in our sprint planning. When we look at a task and estimate that AI can handle 55% or more of the execution, we assign the task differently. AI becomes the “executor.” A developer becomes the “curator” - someone who reviews, adjusts, and ensures quality.
This isn’t about replacing people. It’s about creating a new role dynamic. The developer isn’t writing code from scratch for these tasks - they’re supervising, catching edge cases, ensuring the output meets production standards.
Think of it like this: you wouldn’t hand a junior developer a critical production system on day one. But you’d absolutely let them work on internal tools, experiments, or non-critical features with a senior developer reviewing their work. AI is your extremely fast, extremely tireless junior developer. Treat it accordingly.
Step 3: Build to Learn, Not to Ship
Here’s where most PMs get it wrong with vibe coding. They try to ship AI-generated code directly to production. That’s the wrong frame.
Use vibe coding to learn. Build a prototype in half an evening to test if an idea even makes sense. Show it to users. Get reactions. Gather data. THEN decide if it’s worth proper engineering investment.
I can build a clickable mobile prototype in half an evening now. Not production-ready - but good enough to put in front of a user and ask: “Would this solve your problem?” That answer used to cost us two sprints of design and development. Now it costs an evening.
The prototype isn’t the product. The prototype is the question. And vibe coding lets you ask questions 10x faster.
Step 4: Start From Pain, Not From Courses
I see PMs signing up for “AI for Product Managers” courses from self-proclaimed gurus who teach you to paste a prompt into ChatGPT, get another prompt, paste it into Lovable, and call it a product. That’s not learning. That’s following a recipe without understanding cooking.
Instead - look at your actual day. Where do you waste time? Where do you repeat yourself? Where do you wish you could see something quickly but can’t justify the development effort?
Start there. Start from the pain you can see and touch, not from a curriculum someone designed to sell you a $997 course.
And if you want actual AI education? The courses from Anthropic’s documentation are some of the best out there. Free. Practical. Built by people who actually develop AI, not people who make content about AI.
Step 5: Accept the PM-Dev Tension
Here’s something I haven’t seen anyone write about - the identity crisis that vibe coding creates for PMs.
When you can build things yourself, you start blurring the line between product management and development. And that feels exciting at first. You’re not just deciding what to build - you’re building it. You’re a PM AND a developer. A PM-Dev.
Anthropic actually has an interesting internal principle: if a feature or project takes less than two weeks to launch, the developer IS the PM. They talk to users, coordinate with other teams, make the calls. No separate PM needed.
This is where things are heading. And it creates a genuine tension. Because when you’re building, you’re not doing PM work. You’re not talking to users, analyzing data, thinking about strategy, prioritizing the bigger picture.
I feel this tension constantly. With Temporal.day, with side projects, with the FOMO of “I could build this tonight.” And the honest answer is - I don’t have it perfectly figured out. Nobody does.
But here’s my rule of thumb: if building this thing teaches me something about my users or my product that I can’t learn any other way - build it. If I’m building because it feels productive and exciting but doesn’t actually move the needle - stop. Close the laptop. Go talk to a customer instead.
The Long Game Nobody’s Talking About
Here’s my final thought, and it’s the one I want you to remember.
Right now, if you compare a PM who uses AI to one who doesn’t - the AI user wins. Obviously. It’s a massive productivity multiplier.
But zoom out. In a year, in two years, everyone will use AI. It’ll be as unremarkable as using Google Docs or Slack. The tool becomes table stakes.
And when everyone has the same tool, what differentiates you?
Your skills. Your judgment. Your understanding of users. Your ability to make the right call when the data is ambiguous and the stakes are high. The things that AI can assist with but never replace.
I see products flooding the market right now - apps that were clearly vibe-coded in a weekend, full of bugs, solving problems that don’t exist. The barrier to building dropped. But the barrier to building something GOOD - something users trust, something that works reliably, something that solves a real problem - that barrier hasn’t moved at all.
In the short term, the person who uses AI best wins. In the long term, the person with the deepest skills who ALSO uses AI wins. There’s a difference.
Vibe coding is a tool. A powerful one. But it’s not a strategy, it’s not a skill, and it’s definitely not a replacement for knowing what the hell you’re building and why.
Figure out where you want to be on the map. Understand what you want to develop - in your product and in yourself. Then use every tool available - including AI - to get there deliberately. Not frantically. Not because of FOMO. Deliberately.
That’s the skill that matters. And no amount of vibe coding will teach it to you.