Should Product Managers Vibe Code?

👋 I’m Diego. In every article, I document my journey exploring AI and Product Management. I share the hard lessons I’ve learned from my latest “side quests,” report back on what’s actually working, and answer your questions about building in this space.

Every week there’s a new post. A PM built a feature over the weekend with Cursor. Another shipped an app without writing a single line of code. Someone is shipping vibe-coded features to real users and calling it a workflow.

The question follows every one of these posts: should I be doing this too?

I use vibe coding regularly to prototype my PRDs. I wrote a whole walkthrough about it a few weeks ago. But prototyping a PRD and shipping a vibe-coded feature into production are two different things, and the second one is where the conversation gets complicated.

I posted on LinkedIn that I don’t think PMs should be vibe coding things into production. Two reasons:

• At best you’re an overpaid junior engineer

• PMs already don’t have enough time for the work that actually matters.

Over 80 comments came in from senior PMs at Google, LinkedIn, Meta, YC startups, and Stanford faculty. They disagreed with each other. A lot.

So I spent the past week going through the arguments, looking at the data, and figuring out where I actually stand now that I’ve heard all of it.

“Should PMs vibe code into production?” sounds like it has a yes-or-no answer. It doesn’t. The 80+ comments on my post split into camps that disagree with each other for completely different reasons.

A PM at a 15-person startup and a PM at a company serving millions of users are making fundamentally different bets. At a startup, speed to learn often matters more than code quality. You’re trying to find out whether the thing should exist at all. Waiting for an engineer to pick up a ticket next sprint could cost you a week you can’t afford.

One PM at a YC-backed startup described his workflow: ship behind feature flags, test with fewer than 50 users, kill it if it doesn’t work, hand it to engineering for hardening if it does.

At that team size and product maturity, that process can work. But the fact that it works at 15 people doesn’t mean it scales, and the costs that come with it don’t wait until you’re bigger to show up.

Every vibe coding post on LinkedIn follows the same arc: I built a thing, it works, I learned something. That’s where the story ends. Nobody posts about what happens three months later when the feature breaks, when a dependency changes, when a new engineer inherits the code and can’t make sense of it.

A PM in the comments shared something an engineering manager told him, and I haven’t been able to get it out of my head: “You vibe code the solution, then you vibe code the maintenance and support of it.”

It’s funny because it’s true. The feature shipped. Now someone has to debug it when it breaks, update it when a dependency changes, and explain to a new engineer what this code does. If that someone is the PM who built it, they’re now doing engineering support instead of PM work. If it’s an actual engineer, they’re inheriting code they didn’t write and may not understand.

A Group PM at Google asked the follow-up that nobody in the thread could answer: how do you measure success on vibe-coded features, and when do you decide something needs to be refactored?

Speed is easy to measure and easy to celebrate. The maintenance costs play out over months, and by then nobody’s posting about it.

The instinct to say “PMs shouldn’t code, engineers shouldn’t do product work” feels clean. But it doesn’t match what I’ve seen. I’ve worked with engineers who have better product instincts than some PMs I’ve met, and PMs who can read a codebase better than some junior engineers. The lines have always been blurry, and vibe coding just makes the overlap wider. A PM who couldn’t write a line of code six months ago can now build a working feature in an afternoon.

What concerns me is what happens to the rest of the PM’s job when building becomes that easy.

Christina Wodtke, who teaches product management and HCI at Stanford, listed what ideally PMs should actually be spending their time on, and it’s not even exhaustive: watching markets, tracking competitors, figuring out pricing, GTM, aligning teams, learning from stakeholders, talking with users... That’s already more than a full-time job.

Role boundaries shouldn’t dictate who can build. Teresa Torres made that point in the thread, and I agree with her. But she also named what actually happens when PMs start building without guardrails: jumping to solutions too fast, building the wrong thing, getting stuck in what she called ‘the vibe coding doom loop’, and neglecting the responsibilities that only a PM can own.

Building is fast and satisfying. Discovery is slow and ambiguous. That’s always been true, but vibe coding made the gap wider. It’s now easier than ever to skip the hard part of PM work and go straight to the part that feels productive.

The pull toward building instead of thinking is not new. Vibe coding just made it cheaper and faster to follow. And telling PMs they shouldn’t use it won’t work either, because the upside is real and I agree with Teresa: “I don’t like shoulds. I also don’t like should nots.” The question is whether you’re using the tool to think better or to skip the thinking.

None of these tensions resolve cleanly. But there’s data now on what happens when AI-generated code hits production, and it adds something the debate has been missing.

AI tools are great for building something new. Prototyping, exploring ideas, testing whether a flow makes sense. That’s where PMs should be using them.

But when AI-generated code hits production, even inside professional engineering teams with code review, testing, and deployment pipelines, more code is going out the door and more of it is causing incidents. Not “a little” more. Output is up 20% and incidents are up 23.5%1. Failures are rising at the same rate as output. And the code that ships doesn’t age well: developers are duplicating more and refactoring less, so the maintenance burden keeps growing underneath.2

AI is an indiscriminate amplifier. If your engineering process is strong, it makes you faster without making you worse. If it’s weak or missing, it helps you produce more broken code, faster.

That’s the part that matters for PMs. When you vibe code a feature into production, you’re usually not going through code review, testing, or any of the process that catches problems before users hit them. You’re shipping outside of it. And when those guardrails are missing entirely, the failures hit your users directly.

Moltbook, a social network built entirely through vibe coding, was breached in under three minutes by a security researcher. A basic database security setting was never enabled. 1.5 million API tokens and 35,000 email addresses were exposed.3

That’s not an isolated case. A security firm scanned 5,600 apps built on vibe coding platforms and found over 2,000 vulnerabilities, hundreds of exposed API keys, and personal data including medical records sitting in accessible code.4

Every one of those is a product team decision that failed. Exposed user data, leaked credentials, security breaches. The kind of things a PM should be constantly thinking about, regardless of who wrote the code.

The data draws a clear line. AI helps you move faster when you’re prototyping and exploring. It creates real risks when you ship into production without engineering process around it.

For PMs, the question is which side of that line you’re on.

The data makes the risk clear. But even if you could ship clean, production-ready code, there’s a more basic question: is that the best use of your time as a PM?

I don’t think it is.

PMs already don’t have enough hours in the day. The time between meetings is where the actual product thinking happens: talking to users, digging into data, pressure-testing your roadmap, aligning your team on what matters next. That work is hard to protect because it doesn’t have a deadline or a ticket attached to it. It’s the first thing that gets squeezed.

Vibe coding a feature into production takes that squeeze and makes it worse. The afternoon you spend building is just the beginning. Then comes the week of debugging, fielding questions from the engineer who inherited it, and figuring out why it broke after a dependency update. Every hour you spend on that is an hour you’re not spending on the work that only a PM can do.

Christina’s list from earlier is already more than a full-time job. Adding “write and maintain production code” on top of that just means the PM work suffers.

The startup PM from the comments had a real counterpoint: at 15 people, there aren’t enough specialists, and speed to learn matters more than clean role boundaries. That’s real. But even in that context, the question holds: is the PM’s time better spent shipping a feature an engineer could build in a day, or doing the discovery work that tells the team which feature to build next?

I keep coming back to something Teresa Torres said in the thread: PMs will “jump to the solution space all too soon” and “neglect their other responsibilities”. Building feels productive because you can see the output. You can demo it. Discovery doesn’t demo well. Talking to users, synthesizing patterns, updating your assumptions. That work is invisible until it saves you from building the wrong thing.

PMs can build. That’s been proven. What matters is what they’re choosing not to do while they’re building.

Everything I’ve said so far might sound like I’m against PMs coding. I’m not. I’m against PMs shipping into production without engineering process around it. The distinction matters because there’s a whole category of things PMs can build with vibe coding that never touch production and never need to.

Vibe coding changes how PMs communicate with their teams. I wrote about this a few weeks ago: I take my PRDs into Google AI Studio, prompt my requirements on top of a screenshot of the current UI, and click through the flows myself. Last time I did it, my admin UX fell apart the moment I could actually interact with it instead of reading it linearly. I caught it that morning and fixed the PRD before the team ever saw it. You’re stress-testing your own thinking with a working version instead of a document.

Engineering conversations change when you’re reacting to something you can touch instead of interpreting something you read. “I don’t understand requirement 4” becomes “can we change how this transition works?”.

But prototyping is the use case everyone already talks about. There’s many more that can change your every day workflows.

I spend a lot of my time pulling metrics, reading through customer feedback, and trying to find the pattern underneath it all. I’ve been using CLI tools (Gemini CLI at work, Claude Code on side projects) and agents that do parts of this for me: synthesize interview notes, query data in plain English, surface what changed week over week. LinkedIn wouldn’t call it vibe coding, but it’s the same muscle: using AI to build something that helps you think. You’re using AI to build something that helps you think, not something that ships to users.

The PMs I’ve seen go furthest with this are the ones who stopped asking “what can I build for the product?” and started asking “what can I build for my own workflow?”. A tool that pulls your top customer complaints across three channels and clusters them by theme. A script that turns your dashboards into a Monday morning briefing. These are leverage on the PM work itself.

The line is simple. None of these involve shipping to users. All of them make the PM better at work that’s already theirs.

AI is an amplifier. If your PM fundamentals are strong, it makes you faster, sharper, and harder to ignore. If they’re weak, it helps you produce more of what wasn’t working, faster.

That’s the part of this conversation that keeps getting skipped. The debate is all about the tool: should PMs use it, how should PMs use it, where’s the line. But the tool isn’t the variable. The PM is.

A PM who deeply understands their users, knows how to frame a problem, and can tell the difference between a feature that matters and a feature that demos well will use vibe coding to do all of that better. A PM who skips discovery, jumps to solutions, and ships whatever feels productive will use vibe coding to do all of that faster. The same tool in the hands of two different PMs produces completely different results.

The anxiety around vibe coding, the “you MUST learn this or you’ll be left behind” energy that fills LinkedIn every week, assumes the tool is what matters. The fundamentals are what matter, and they’ve always been what matters. Vibe coding just made that more visible.

Not learning to vibe code won’t leave you behind. What will is not understanding your users, not knowing what to build (and why), and not being able to tell the difference between activity and progress. Those have always been the things that separate the PMs who move products forward from the ones who stay busy.

The tools will keep changing. They always do. The fundamentals won’t.

Should PMs vibe code features into production? I don’t think so, at least not yet. The risks are real, the maintenance costs are real, and the opportunity cost of doing engineering work instead of PM work is real.

But should PMs vibe code? Yes. Just not into production. Use it to prototype your thinking, build tools for your own workflow, communicate ideas in higher fidelity. Use it to get better at the job, not to take on a different one.

See you on the next side quest.

Party up! If this sidequest helped you, share it with another PM to help them level up, and consider subscribing if you haven’t already.

See you in the next Side Quest 👋,

Diego