PMs Should Vibe Code Internal Tools, Not Customer Features

The short version

Vibe coding is the most valuable new skill a product manager can pick up. Learning to build with a tool like Claude Code turns a PM from someone who writes specs into someone who builds their own tools and prototypes in an afternoon. But there is a line, and crossing it is malpractice: vibe coding is for internal tools and prototypes, not for shipping features to customers. Vibe-coded code optimizes for looking right, and a PM usually cannot tell at the code level whether it is actually right. Point it at a dashboard, a feedback clustering script, or a throwaway prototype, where the worst case is losing your own time. Do not point it at the production code path, where the worst case is a customer's data and an engineering team inheriting a liability they did not write. Same skill, completely different blast radius. Here is the line and why it matters.

I want PMs to vibe code. I mean it. Learning to build with Claude Code is the highest-leverage skill a product manager can add right now, and the PMs who have it are operating at a level the ones who do not cannot match. This is not a cautious take about staying in your lane.

It is a take about which lane. Because the same tool that makes a PM dangerous in the good way makes them dangerous in the bad way, and the difference is entirely about where you point it.

What vibe coding is actually good at

Vibe coding is building by describing what you want and iterating on what the AI produces. Its core property, the thing that makes it magic and the thing that makes it risky, is that it optimizes for output that looks right and produces a reaction. For a huge category of work, looking right and working well enough is the whole job.

That category is internal tools and prototypes. A dashboard that pulls your own product metrics into one view. A script that clusters a thousand pieces of customer feedback so you can see the themes. A prototype that lets you put a real interaction in front of five users. An internal viewer that makes some gnarly dataset explorable. For all of these, the prototype is the point, and the blast radius is forgiving. If the thing breaks, you lose an hour of your own time. Nobody's data is exposed. No customer is harmed. This is where a PM who can build is a genuine superpower, and the lack of production-grade rigor is simply irrelevant.

“

Point vibe coding at things where the worst case is losing your own afternoon. That is where a PM who builds becomes unstoppable and the missing rigor does not matter.

”

Why customer features are the wrong lane

Now flip the blast radius. A customer-facing feature is the opposite of a forgiving environment. The worst case is not your wasted hour. It is a security hole, a data-loss bug, an edge case that corrupts something real, and a maintenance burden that lands on engineers who did not write the code and now have to own it forever.

Here is the part that makes it specifically a PM problem. Vibe-coded code optimizes for looking right, and a PM, by definition, usually cannot read the code well enough to know whether it is actually right. So the exact skill gap that makes vibe coding feel magical, you do not have to understand the code, is the skill gap that makes shipping it to customers reckless. You are deploying something you cannot evaluate at the level where the danger lives.

And the incentives are ugly. The PM gets the speed and the credit for shipping fast. The engineering team inherits the liability, the on-call pages, and the rewrite. That is not collaboration. That is offloading risk onto the people downstream of you, and it poisons the trust that makes a PM who builds valuable in the first place. The honest rule is the one I apply to knowing when not to use AI: the question is not can I produce this, it is can I stand behind it where it counts.

Prototype is not a synonym for product

The trap that catches good teams is promotion by inertia. A PM vibe codes a convincing prototype to test an idea. It works in the demo. Everyone is excited. And because it already works, somebody asks the obvious-sounding question: why rebuild it, can we just ship this?

That question is where prototypes go to become incidents. A prototype exists to answer a question and should be thrown away the moment it has. A product exists to serve customers reliably over time. They are different artifacts with different standards, and the fact that the prototype already runs is not evidence it is ready, it is the bait. I wrote a whole separate piece on how cheap demos kill good ideas in the prototype graveyard, but the production version of the danger is simpler: convincing is not the same as correct, and customers only experience the difference when it breaks.

“

A prototype that works in the demo is not a feature that is ready. It is bait. The fact that it runs is exactly what tempts you to skip the part that makes it safe.

”

The division of labor that actually works

None of this means PMs stay away from the build and hand off paper specs. The opposite. The strongest setup I have run looks like this.

The PM vibe codes the prototype that proves the idea. That prototype does double duty: it validates the concept with real users, and it becomes the de facto spec, because a working artifact removes the ambiguity that a written PRD never fully resolves. This is the eval-and-prototype-as-spec idea in practice, and it saves an enormous amount of the back-and-forth that used to eat weeks.

Then engineers build the production version, with the security, testing, and maintainability a customer feature requires. They are not translating a vague document, they are productionizing a concrete, working reference. The PM accelerated discovery and definition. Engineers own the part where consequences are real. That split is faster than either group alone and far safer than the PM pushing vibe-coded code to customers because it happened to run.

So learn to vibe code. Seriously, this week, if you have not. Build the dashboard you have wanted for a year. Build the feedback clustering tool. Build the prototype that settles the argument in your next planning meeting. Just keep it in the green zone, where the worst thing that can happen is you wasted an afternoon, and let the prototype earn its way into production through engineers, not around them. The skill is a superpower. The discipline is knowing exactly where to aim it.

Sources: Anthropic, Claude Code documentation · Simon Willison, on AI-assisted coding and its limits · Andrej Karpathy, on vibe coding