A vibe is not a spec. Write a PRD your AI can build from.

These days anyone can ship an app in an afternoon. Open Cursor or Lovable, type what you want, and the AI wires up the screens for you. A few prompts later you have something that runs. This is what people call vibe coding: programming by feel, giving a rough idea and letting the AI fill in the rest.

The problem is not that it cannot build. It builds shockingly fast. The problem is that it builds the thing that looks right. It wows you on first open, but when you actually use it you find it understood the problem differently than you did. So you prompt a fix, it fixes that and breaks something else, and round it goes until the credits run out and the thing still is not right.

The mistake is asking the AI to do two jobs at once: decide what to build and build it. Those should be separate. A vibe conveys a feeling, but it does not say what "correct" is. A spec does, and the spec light enough to write before every build is a short PRD. This post covers where vibe coding breaks, what a minimal PRD that prevents it looks like, and how to tell whether your idea is ready to hand to an AI.

Part 1Where vibe coding breaks

Before you can fix it, you have to see how it breaks, because vibe coding does not fail loudly. It fails quietly, in the way that keeps you feeling like you are making progress.

It does not fail to build, it builds the wrong thing

The AI is good at filling gaps. Leave something out and it guesses the rest, but it guesses toward what "usually" fits from everything it has seen, which rarely matches the specific context of your work. You get something that is right by the generic textbook and wrong for your actual problem.

The more you fix, the more it breaks

When the output is off you prompt a fix, one point at a time. But the AI has no picture of what must not break, only the latest instruction, so it fixes the thing you named and quietly breaks another. No spec means no definition of correct, so the AI substitutes confidence for correctness, and you never quite finish chasing it.

Pretty on first open is not the same as working

What the AI builds usually looks good on the first screen: buttons present, layout tidy. But walk a real path, enter odd data, try the case that is not the happy one, and the holes show up everywhere, because a vibe catches only the surface. The edge cases and the rules nobody said out loud, it has no idea they need to exist.

Part 2The minimal PRD that makes AI build right

The good news: the spec the AI needs is not a thick old-school requirements binder. Half a page that covers eight sections changes the outcome a lot, because each section is a gap the AI will guess at if you leave it blank.

Eight sections the AI needs before it builds

1. Problem and users what you are solving, for whom, where it hurts
2. Scope what it does, and more importantly what it does not do
3. Capabilities written as a list, not a floating paragraph
4. Testable acceptance criteria "counts as done when..." in a way you can check
5. Data and state what data exists, where it lives, what it looks like
6. Constraints and hard limits to keep the AI from wandering too far
7. Edge cases empty, malformed, slow, failed, what should happen
8. Definition of done what a shippable version actually looks like

The one you cannot skip is acceptance criteria, because it is the only place that writes "correct" down concretely. The other sections tell the AI what to build; this one tells you how to see that it is right.

Write acceptance criteria the AI can check itself

Good criteria are checkable, not "easy to use" or "fast" (each of which means a hundred things), but "press Save and a new row appears in the table within 2 seconds," or "if the email is malformed, show an inline error and do not submit the form." Concrete like that, the AI can check its own work, and you can check the AI's, by eye.

The PRD is the spec, the spec is the source of truth

This idea has a name: spec-driven development. Keep the spec as the anchor. To change anything, change the spec first, then have the AI rebuild to it, rather than prompting the code directly. The payoff is that results are repeatable, you come back and get the same thing, and there is one place that says what you agreed to build, instead of a mile-long chat log nobody can retrace.

Part 3Check if your idea is ready, then start

Check before you burn credits

Before you turn the AI loose, answer a few quick questions. Do you know the problem and the users? Is the scope clear about what is in and what is out? Can you list what must work? And can you write even one testable acceptance criterion? Every question you cannot answer is a gap the AI will fill by guessing. The more blanks, the more credits you burn fixing it afterward.

The one rule to remember

If you take one thing from this post, make it this. Do not make the AI decide the problem and build it at the same time. Write a short spec first, always, even half a page beats none, then have the AI build to it, rather than guessing both the question and the answer in a single shot.

Where to start

You do not need a polished PRD. Start from half a page and let the AI help you sharpen it.

1. Write a half-page PRD from the eight sections above, just problem, users, scope, capabilities, and acceptance criteria to begin.
2. Have the AI read the spec and "push back" before it builds. Ask it where the spec is still ambiguous and where it would have to guess. What it points at is a hole in your spec.
3. Fix the spec where it asked, then tell it to build.
4. Test against the acceptance criteria one by one. Where one fails, fix the spec, not the code by a loose prompt.

With a spec leading, vibe coding stays just as fast, but you get the thing you meant, not something you have to reverse-engineer the AI's intent from later. If you want a tool that checks your idea's readiness and bounces it back as a PRD skeleton, we built a free one at productize.life/services/prd.