Vibe coding is a PM skill, not an engineering shortcut

The prototype in the interview is the new take-home

A candidate shows up to a product interview, gets the case prompt, and instead of walking through a whiteboard flow, opens a laptop and hands the panel a working prototype at the end of the loop. Clickable. Real copy. A data model that mostly holds together. Two years ago that was a party trick. Now it’s the reason one candidate gets the offer and three others get the polite rejection. The prototype-in-the-loop is now a hiring filter because it measures the one PM trait that matters: the speed to turn a hypothesis into evidence a room can react to.

The PMs winning these loops aren’t better engineers. They’re faster at turning an idea into something a room can react to, and that speed is the whole job. This is not a story about product managers learning to code. It is a story about a tool that collapses the distance between a hypothesis and the evidence for it.

What actually changed is the cost of a first artifact

The thing that changed is the cost of a first artifact. Lovable, Cursor, v0, and Bolt didn’t make PMs into developers. They made the first draft of a product nearly free to produce.

For most of my career the flow from idea to reactable artifact ran through other people. You wrote a doc, you socialized it, you got design time, you got a spike from an engineer, and somewhere three weeks later you had a thing you could put in front of a user. Each handoff cost days and diluted the original intent. Half the arguments in a product review were about a mockup that didn’t exist yet, which meant they were arguments about words.

Now a PM can go from prompt to prototype in an afternoon. The artifact isn’t production code and nobody pretends it is. It’s a forcing function. It makes the fuzzy parts of an idea concrete, and concrete ideas are easier to kill, sharpen, or fund. The value was never the code. It was getting to a shared object fast enough that the conversation is about the real thing instead of a description of the thing.

The hiring shift is a signal, not a gimmick

Hiring managers noticed before the frameworks did. When a candidate ships a prototype in the loop, it tells you something a case study can’t: this person closes their own loops.

Most product interviews test whether someone can describe good judgment. The prototype tests whether they can act on it without waiting for permission or headcount. That maps directly to the behavior that separates PMs who move an org from PMs who generate meetings. The prototype in the loop is a proxy for a trait that’s otherwise hard to observe in 45 minutes: bias toward evidence over argument.

It also filters for taste. Anyone can generate a screen with these tools. The candidate who generates the right screen, cuts the scope to the one flow that proves the hypothesis, and ignores the nine that don’t, is demonstrating the actual skill. This connects to the argument that as AI commoditizes the mechanical middle of the job, the scarce human work like taste and judgment becomes the whole job. I’d rather see a PM ship one crude flow that tests the core bet than a polished demo that tests nothing.

Engineers are mostly fine with this, and they’re right to be

The obvious objection is that this bleeds into engineering’s craft and engineers will resent it. Mostly they don’t, and the ones who’ve worked with a strong builder-PM understand why.

A prototype that clarifies intent before a single line of production code gets written is a gift to engineering, not a threat. The expensive failure mode in product isn’t a PM who mocks up a flow. It’s a PM who hands engineering a vague doc, watches them build the wrong thing for a sprint, and calls it a learning. When the PM shows up with a working artifact that says “this is the interaction I mean,” the ambiguity that usually gets discovered in code review gets discovered in the prompt instead. That’s cheaper for everyone.

The resentment shows up in one specific case: when the PM mistakes the prototype for the product. That is the trap, and it’s worth pulling apart.

The trap is confusing the artifact for the ship

Here’s where it goes wrong. A PM ships a prototype that works in the demo, feels the dopamine of having built something, and starts treating it as 80% done. It is not 80% done. It is 5% done and 95% understood, a different and more valuable thing, but only if you know the difference.

The prototype has no error handling, no auth, no data integrity, no edge cases, no load, no accessibility, and no security. It works because it’s running on the happy path in front of a friendly audience. The gap between that and a live and supported product is the part engineering actually gets paid for, and it’s most of the work. A PM who says “I already built it, why is this taking three sprints” has learned the tool and missed the lesson.

The discipline is to hold the prototype as a question, not an answer. It answers “should we build this.” It says nothing about “can we ship this,” and pretending otherwise is how a useful skill turns into a source of friction with the people who have to make it real.

The skill underneath the tool is old

Strip away the tools and the skill underneath is old. The best PMs have always found the cheapest possible way to make an idea real enough to test. Fake doors. Wizard-of-Oz flows. A landing page and a waitlist. A Figma prototype passed around in a hallway. Vibe coding is the current cheapest way, not a new category of work.

What’s new is the ceiling. The cheapest testable artifact used to be a static mockup or a fake button that logged clicks. Now it’s a thing that actually functions well enough to put in a user’s hands and watch them fail at. That’s a better test, produced faster, by the person who holds the hypothesis. The loop from idea to evidence tightened, and the PMs who tightened it fastest are the ones getting the offers.

The candidates shipping prototypes in interviews aren’t showing they can code. They’re showing they refuse to argue about a thing they could have just built.