Chapter 5: Vibe Coding for Value: Prototyping to Decide

A functional prototype built in a day is the new spec, but only as a learning instrument, never as a demo and never as a product. Vibe coding is for validating value and de-risking a bet. The whole discipline is knowing exactly where the working demo lies to you.

You can now build a working full-stack prototype in a weekend without writing code. Describe what you want to one of the app builders and it returns a deployed application: a frontend, a backend, a database, a login screen, all of it apparently functional. This is real, not aspirational; it is the 2026 baseline. For a PM it is one of the most useful capabilities that has ever existed, and one of the most dangerous, and the danger is the exact thing that makes it useful. The speed that lets you validate a bet in a day is the same speed that produces something that looks finished and is not.

This chapter is about using that capability for what it is good for and refusing to use it for what it is not. The good is large. The trap is specific, documented, and has a name.

Why a prototype beats a doc now

The PRD was always a proxy. You wrote down what the product should do because building it to find out was too expensive, so a document stood in for the thing, and everyone argued about the document. The argument was never really about the document; it was about a product nobody could see yet. The spec was the cheapest available way to externalize a guess.

When building the real thing drops to an afternoon, the proxy loses its reason to exist. You no longer have to argue about a description of the product when you can put a working version of it in front of the person whose reaction you actually need. A prototype answers in an hour what a spec review debates for a week, because it replaces opinion about a hypothetical with a reaction to a thing. This is the sense in which the prototype is the new spec: not that it ships, but that it is now the cheapest way to externalize and test a product guess, which is what the spec was for all along.

That only holds if you treat the prototype as a learning instrument and not a demo. A prototype’s job is to invalidate your riskiest assumption as fast as possible, before you commit real money. The discovery practitioners have a discipline for this, the opportunity solution tree, which is just a way of naming which assumption you are actually testing: is the risk that people do not want this (desirability), that they will not switch to it (adoption), or that it will not work at scale (feasibility)? A prototype is the right test only for the first two. If you build a vibe-coded prototype before naming the riskiest assumption it is meant to attack, you are not doing discovery. You are doing demo theater with better production values.

What vibe coding is actually good for

Used as a learning instrument, the prototype does three things a document cannot.

It shows instead of telling. A stakeholder who would nod through a PRD section and then ask for the opposite thing at launch cannot misunderstand a screen they are clicking. The prototype collapses the translation loss between what you meant and what they pictured.

It de-risks a bet before the bet is expensive. The whole point of building fast is to fail fast, on the assumption that would have sunk the project anyway, while the cost of being wrong is an afternoon rather than a quarter.

And it tests a job to be done against reality rather than against a persona slide. Put the prototype in front of someone who has the problem and watch where they get confused, where they stop, where they reach for something it does not do. That is data a spec review cannot produce, because the spec review is populated by people imagining the user instead of being one.

None of this requires the prototype to be good code. It requires it to be good enough to provoke a real reaction. That is a low bar, and the vibe-coding tools clear it easily, which is exactly why the next section matters.

Where the working demo lies to you

Here is the trap, and it is not a soft warning. A vibe-coded app generates code that works under the conditions you happened to test. It does not generate code that is secure, scalable, or maintainable under the conditions you did not test or imagine. The demo is honest about the happy path and silent about everything else, and the silence reads as success.

The numbers are not subtle. Across multiple independent 2025-2026 studies, between forty and sixty-five percent of AI-generated code contains security vulnerabilities. One audit found AI-generated code produced nearly three times the security issues per change as human-written code. More than nine in ten vibe-coded apps audited in early 2026 had at least one hallucination-related flaw. A separate finding: roughly a fifth of the software packages AI tools recommend do not exist, and attackers have started pre-registering the predictable fake names with malicious code, waiting for vibe-coded apps to install them. The tool that built your prototype in an afternoon will, with high probability, have built something an attacker can walk into.

This is the MVP house of cards from chapter three, in its newest form. The claim is direct: a vibe-coded app is an MVP, the smallest thing that runs and demos, and we are now producing MVPs faster than ever and stacking them the same way we always did. The mechanism has not changed. Only the speed has, and speed is exactly what removed the friction that used to slow the stacking down. When an MVP took six weeks, the cost of building one bought you a little time to ask whether you should. When it takes an afternoon, that pause disappears, and the cards go up faster than anyone can count them.

Someone will object that a vibe-coded app is not really an MVP, that it is less, because a hand-built MVP had a person who understood every line and chose the scope on purpose, while a vibe-coded app has no one who knows what is inside it. That objection is correct, and it makes the problem worse, not better. A traditional MVP was a thin card, but a read one; its author knew where it was load-bearing and where it was not. A vibe-coded card is just as thin and unread, generated by something that cannot tell secure from insecure, only plausible from implausible. So the newest form of the house of cards is not merely faster. Each layer rests on the assumption that the layer beneath it is sound, and now no human has checked whether it is. The structure stands until the first condition no one tested arrives, and then it does not fall gracefully.

What you build and what you must not ship

So the line is bright, and it is the line the whole chapter turns on. You build the prototype to decide. You do not ship it to users. A working demo is not enterprise-ready, secure, scalable, maintainable software, and the gap between the two is precisely the skill of the engineering team, which is the subject of the next chapter. The PM who confuses the prototype for the product has not saved the build cost. They have moved it downstream to the worst possible moment, the production incident, and attached your name to it.

This is also where the preface’s promise comes due: vibe coding does not turn the PM into a builder. It turns the PM into someone who can test a bet cheaply, which is a different and more valuable thing. The prototype is yours to make and yours to learn from. Turning it into something a real user can safely touch is work you hand to people who do it for a living, with the prototype as the richest spec you have ever handed them, one they can run, click, and interrogate rather than read and reinterpret.

The handoff is the payoff. A prototype carried to engineering is worth more than any document because it resolves the ambiguity a document preserves: this is what I mean, here is the flow, here is the thing the user reacted to. But it carries one obligation. You hand over the learning, what the prototype proved and disproved, not the code, which was never built to survive. The instinct to “just productionize the prototype to save time” is the instinct that builds the house of cards on purpose.

A closing question for your own roadmap. Take the bet you are least sure of. What is the single question a one-day prototype would answer, and what result would actually kill the idea? If you cannot name the killing result, you are not planning to learn from the prototype. You are planning to fall in love with it.