Vibe Coding Made the Spec More Important, Not Less

Vibe coding does not remove the need for a spec. It changes what the spec is for. When an AI agent can build any feature you describe in an afternoon, the constraint is no longer how fast you can write code — it's deciding what's worth building, and knowing what you actually built.

What Is Vibe Coding, and Why Does It Break Planning?

Vibe coding is describing software in plain English and letting an AI write the implementation. Andrej Karpathy coined the term in February 2025. By November it was Collins Dictionary's Word of the Year. In under twelve months it went from a novelty to the default way a lot of products get built.

It works. That's the problem.

An AI coding agent will build whatever you describe, including the wrong thing, in an afternoon. There's no engineer pushing back on your requirements, no designer catching the unclear user journey, no tech lead flagging that your scope is wishful thinking. Two failure modes follow, and almost every AI-built product hits at least one:

You shipped a pile of features, not a product. Each one works. Together they don't add up to anything a user would pay for.

You have code you're afraid to touch. It runs. You don't know why. Adding the next feature might bring the whole thing down.

The first is a planning failure. The second is an auditing failure. Both are spec problems.

What Should You Write Before the First Prompt?

Write the promise before the features. Ian Khor, building his habit tracker Dowyn with Claude Code, frames it exactly that way. The temptation is to skip straight from idea to implementation — you describe a feature, the model writes it, you run it, it works. It feels like magic. The catch, as he puts it, is that a sequence of working features is not a product.

A promise is the one sentence that says what changes for the user. Everything downstream is either in service of that promise or it's scope creep wearing a convincing disguise.

This is what a PRD's problem statement is for, and it's the section people skip. "Users find onboarding confusing" is a vibe. "47% of new users abandon the setup wizard at step 3" is a promise you can hold a build accountable to. Our guide to writing a PRD in 2026 goes deeper on structuring that section.

Does AI Actually Make Developers Faster?

Often yes, but not reliably — and you are a poor judge of your own speed. Three findings from 2025 complicate the story in useful ways.

Measured speed and felt speed diverge sharply. METR ran a randomized controlled trial with 16 experienced open-source developers across 246 real tasks in repositories they knew well. Developers using AI tools were 19% slower. They estimated afterward that AI had made them 20% faster — a perception gap of roughly 39 points. The setting matters: mature codebases, expert maintainers. That's closer to maintaining a vibe-coded app six months in than to building a greenfield prototype.

Speed and stability move in opposite directions. Google's 2025 DORA report, drawing on nearly 5,000 technology professionals, found that higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability. Teams adapted for speed. Their underlying systems didn't adapt for safety. The report's own framing: AI doesn't fix a team, it amplifies what's already there.

The code is getting harder to maintain. GitClear analyzed 211 million changed lines and found 2024 was the first year on record where copy-pasted code exceeded refactored code. Refactored or moved lines fell from roughly 25% of changes in 2021 to under 10% in 2024. Duplicated blocks rose sharply.

Put together: AI makes you faster at producing code, worse at judging whether you're actually faster, and less likely to clean up as you go. The lever that still works is deciding well up front, and checking honestly afterward.

How Do You Audit a Vibe-Coded App?

Start by asking the AI to explain your own code back to you. It's the move most people never run, and it's the one that surfaces the gap between what you think you built and what exists.

Not "find bugs." Explain. Where does state live? What happens on this route? Which of these three files is actually being used? You wrote all of it, or you think you did, and you will be surprised by the answer at least once.

Then run the comparison that matters. Put the explanation next to your spec and ask three questions:

1. What exists that isn't in the spec? Either it's scope you didn't intend, or the spec is stale. Both need a decision.
2. What's in the spec that doesn't exist? Either it got quietly dropped, or you talked yourself out of it and never wrote that down.
3. What exists twice? Duplication is the load-bearing signal. Two implementations of the same idea means the next change has to happen in two places, and eventually won't.

Without a spec, you have nothing to hold the explanation against, and the audit degrades into vibes about vibes.

What Should a Spec for AI-Built Software Include?

A lean seven-section PRD covers most AI-built features: problem, solution, target users, key features, success criteria, scope and constraints, and open questions. If you can't fill that out in 30 minutes, the idea needs more thinking — not more documentation. Our PRD template guide breaks down when to reach for something heavier.

The shift worth internalizing is what the document is for. In a pre-AI workflow, the spec was a coordination device — a way for eight people to agree before anyone burned two sprints. When your only teammate is a model, coordination isn't the job anymore. The spec has three new ones:

• It forces the promise before you can be seduced by a working demo.
• It's the context you feed the model. A model working from your actual problem statement, constraints, and prior decisions produces dramatically better output than one working from a paragraph you typed in a hurry.
• It's the diff target for the audit. You cannot detect drift from a plan you never wrote down.

Plan, build, audit, update the plan. The spec is the only artifact that survives all four steps.

The failure mode of vibe coding was never that the code is bad. Increasingly, the code is fine. The failure mode is building the wrong thing very quickly, then losing track of what you built. A spec is the cheapest defense against both, and it costs less than the afternoon you'd spend rebuilding.

Frequently Asked Questions

Do you still need a PRD if AI writes the code?

Yes, and it matters more than before. A PRD does three jobs in an AI workflow: it forces you to state the product's promise before a working demo convinces you it exists, it gives the model the context it needs to produce accurate output, and it acts as the reference you compare the finished code against to detect drift.

How do you audit a vibe-coded app?

Ask the coding agent to explain your own codebase back to you — where state lives, what each route does, which files are actually in use. Then compare that explanation against your spec and ask three questions: what exists that isn't in the spec, what's in the spec that doesn't exist, and what exists twice.

Does vibe coding produce worse code?

Not necessarily worse on first write, but harder to maintain over time. GitClear's analysis of 211 million changed lines found copy-pasted code overtook refactored code for the first time in 2024, with duplicated blocks rising sharply — a maintainability cost that shows up months after the code ships.

How long should a PRD be for an AI-built feature?

Seven sections is usually enough: problem, solution, target users, key features, success criteria, scope and constraints, and open questions. Reserve heavyweight templates for features where multiple teams are involved or the cost of getting requirements wrong is high.

When should you audit a vibe-coded project?

Before the next significant feature, not after something breaks. The audit is cheapest when the codebase is still small enough that the explanation fits in one sitting, and most valuable right before you add the change that would otherwise compound the existing duplication.