Specs vs Vibes: Knowing When to Plan and When to Just Build

Why this matters

There are two failure modes in vibecoding, and they look opposite.

Failure mode A: you spend three hours writing the perfect PRD for a side project, then never start, because the spec made it feel like real work.

Failure mode B: you skip planning entirely, prompt for "a SaaS for tracking gym workouts," get a beautiful demo, and discover four days later that the data model can't represent the one feature you actually care about.

Both are costly. Specs vs vibes is the meta-skill of knowing which trap is in front of you right now. Get it right and you ship 3x faster. Get it wrong and you ship nothing, or you ship the wrong thing.

The setup

This isn't a tools question. It's a judgment question. To make the call, you need three pieces of information:

• The cost of being wrong (low for prototypes, high for paid features)
• The reversibility of the decision (cosmetic = reversible, schema = expensive to change)
• Your own confidence in the destination

Step 1: Vibe when the cost of being wrong is low

If the worst-case outcome of building the wrong thing is "I throw away an afternoon," just vibe. Open Lovable or Cursor, prompt, ship. You'll learn more from the wrong build than from the spec.

Good candidates for pure vibe mode:

• Personal tools you'll be the only user of
• Marketing pages and landing pages
• One-off scripts and data transformations
• Quick design explorations
• Throwaway prototypes to show a stakeholder

"Build a dashboard that pulls my last 30 commits from GitHub 
and shows them as a punch card. Use shadcn. Stand it up locally."

That prompt is fine. No spec. If it's wrong, you delete the folder.

Step 2: Spec when schemas, money, or users are involved

The moment your decision touches one of these, stop vibing and write the PRD:

• Database schemas you'll have to migrate later
• Anything that touches money (Stripe, ledgers, balances)
• Multi-user permissions / RLS
• Public APIs you'll have to keep stable
• Multi-week features with parallel work

These are the irreversible parts. A schema you got wrong on day three is a migration on day ninety. A permissions model the AI improvised is a security review you can't pass. A vibey ledger is fraud waiting to happen.

The spec doesn't have to be long. Three things, in writing:

## Goal
One sentence. Plain English.

## Anti-goals
What we are explicitly NOT doing in v1.

## Schema / data model
The tables, the columns, the constraints. THIS is the part you can't vibe.

Paste it into your AI builder. Now you can vibe the implementation safely, because the load-bearing decisions are pinned.

Step 3: Switch modes mid-project

Real projects need both modes. The trick is knowing when to flip.

• Start vibe — explore the shape of the product.
• Hit something irreversible ("wait, what's the data model?") — pause, spec it.
• Spec is committed — go back to vibing the UI, the copy, the flows.
• New irreversible decision — pause, spec it.

The tax for switching is small. The tax for refusing is huge: stuck in spec land, or stuck in rework hell. Watch yourself for both.

Common mistakes

• Writing a 12-page PRD for a side project — You're procrastinating, not specifying. Three sentences is enough for most weekend builds.
• Vibing the schema — The schema is load-bearing. Specify the tables and constraints before you let the AI generate any data-touching code.
• Specifying the UI down to the pixel — UI is reversible. The AI is great at iterating on it. Just tell it the vibe, then iterate visually.
• Treating spec and vibe as personality types — They're modes. Switch as the work demands.
• Skipping the anti-goals — "What we won't build in v1" prevents 80% of scope creep. Cheaper than any other line in the spec.

What's next

Once you can switch modes mid-project, formalize the spec side with the PRD writing guide and tighten the vibe side with the iterative vibecoding workflow. The goal isn't to pick a side — it's to know which one the next 20 minutes needs.