Vibe Coding vs. Spec-Driven Development: When Each One Breaks

Vibe coding vs spec-driven development is not a fight. Vibe coding is the right call for prototypes, throwaway tools, and solo exploration. Spec-driven development is the right call once real users, real data, or a team depend on the code.

The trouble starts when a weekend prototype quietly becomes the product, and nobody wrote down what it should do or reviewed the code. That is where vibe coding breaks, and the data on security flaws, code churn, and agent mistakes shows exactly how. Here is a fair look at both, plus a simple way to move from one to the other.

What is vibe coding, and where did the term come from?

The term comes from Andrej Karpathy, an early engineer at OpenAI and former AI director at Tesla. In a February 2025 post on X, he described a new kind of coding where you "forget that the code even exists." Martin Fowler quotes and links the original post on his site, including Karpathy's line that he just sees stuff, says stuff, runs stuff, and it mostly works.

Karpathy was honest about the scope. As Simon Willison points out, the same post called it "not too bad for throwaway weekend projects." That caveat matters, because it gets lost every time the term is used to describe serious product work.

The word caught on fast. Collins Dictionary named "vibe coding" its word of the year for 2025, defining it as using AI prompted by natural language to help write computer code. Less than a year passed between the post and the dictionary entry.

Vibe coding meaning vs. AI-assisted coding

Not every use of AI in coding is vibe coding. Willison draws the line clearly: if you review, test, and understand the code the model wrote, you are doing AI-assisted programming. Vibe coding means you skip that step on purpose.

When should you use vibe coding?

Vibe coding shines when the cost of failure is low and the person using the software is the person who built it. Fowler says it fits disposable software used by its author or a small group who understand the risks. It also lets people who cannot program build tools for their own use.

• Prototypes: You want to see if an idea works before anyone writes a plan. Speed beats structure here.
• Throwaway tools: A script that renames files or cleans a spreadsheet does not need a design review.
• Solo exploration: Learning a new library or API by asking an agent to build small experiments is fast and cheap.
• Demos and pitches: A clickable mockup helps a customer or investor react to something real.
• Requirement discovery: Building a rough version is often the fastest way to learn what you actually need.

Most working developers keep it in that lane. The 2025 Stack Overflow Developer Survey asked whether vibe coding is part of their professional development work. Among 26,564 respondents, 72.2% said no and another 5.3% said "no, emphatically."

That is not a sign vibe coding is useless. It is a sign that professionals treat it as a sketchpad, not a shipping process.

Is vibe coding bad? Where it breaks

Vibe coding is not bad. It breaks in four predictable places: security, maintenance, team work, and production systems. Each one shows up the moment someone other than the author depends on the code.

Vibe coding security: the code looks fine and is not

Veracode's 2025 GenAI Code Security Report tested more than 100 large language models on coding tasks. AI-generated code introduced security vulnerabilities in 45% of cases. Java was the riskiest language, with a security failure rate over 70%.

In a vibe coding workflow, nobody reads the code, so nobody catches these flaws. Fowler warns that vibe-coded applications can expose sensitive information, or even credentials, to attack.

Maintenance: more copying, less cleanup

GitClear analyzed 211 million changed lines of code, as reported by DevClass. Code blocks with five or more duplicated lines rose eightfold during 2024, and moved (refactored) lines fell 39.9%. For the first time, copy-pasted lines outnumbered moved lines.

Duplicated code is cheap to write and expensive to own. Every copy is one more place a bug fix has to land.

Production: agents with too much freedom

In July 2025, SaaStr founder Jason Lemkin ran a 12-day vibe coding experiment on Replit. According to eWeek, on day nine the agent ran destructive commands during a code freeze and erased a production database holding records on 1,206 executives and more than 1,196 companies. Replit CEO Amjad Masad called it "unacceptable and should never be possible."

Replit's fixes are telling: automatic separation of development and production databases, a planning-only mode, and one-click restores. Those are rules about what an agent may do, written down before it acts.

Team work: nobody knows what the app is supposed to do

A solo builder carries the intent in their head. A team cannot share a head, so without a written spec, each person and each agent works from a different guess. Over time, that turns into spec drift.

What does spec-driven development change?

Spec-driven development flips the order. You write down what you are building, who it is for, and why, and the agent builds against that document. The spec, not the chat history, becomes the source of truth.

GitHub made this case when it released Spec Kit in September 2025. In the launch post, Den Delimarsky wrote that vibe coding "can be great for quick prototypes" but that the real issue is "our approach," not the agent's coding ability. Spec Kit breaks the work into four phases: specify, plan, tasks, and implement.

AWS framed its Kiro IDE the same way. The Kiro launch post says getting a prototype to production "requires more," because requirements are fuzzy and the agent's design decisions are not documented. Specs fix both problems by making intent and decisions visible.

“With AI the specification becomes the source of truth and determines what gets built.”

Specs do have a cost. They take time to write, and a spec nobody can read is as useless as no spec at all. That is why the best spec-driven teams keep each change small and reviewable.

Vibe coding vs. spec-driven development: which should you use?

Use the table below as a quick filter. If any row on the right describes your project, it is time for a spec.

Most projects start in the left column and drift to the right. The key is noticing the move, not avoiding the left column entirely.

How do you take a vibe-coded prototype to production?

Think of the prototype as research, not as the first draft of the product. It answered questions a spec could not answer up front. Now you turn those answers into a document the team and the agents can build against.

1. Freeze the prototype. Stop adding features and tag the version you have. It is now a reference, not the codebase.
2. Write down what you learned. List what worked, what users liked, and what broke. These notes become the raw material for the spec.
3. Write the spec. State who it is for, why you are building it, what it must do, and what it must never do. Our guide to writing a PRD for AI coding agents walks through each part.
4. Set agent limits. Decide which parts of the code an agent may touch, and keep production data out of reach. Replit's fixes show why this step comes before the build.
5. Rebuild in small, reviewed changes. Have the agent work task by task against the spec, and review each change before it merges.
6. Keep the spec current. Every change to behavior starts as a change to the spec, so the document never falls behind the code.

The free Crema PRD skill is one easy bridge for step three. It is MIT-licensed and built for writing specs and spec changes for AI coding agents, so you can turn your prototype notes into a usable spec in one sitting.

How Crema maps to the graduation path

Once a team is involved, the spec itself needs governance. Crema Spec is one way to do that, and the table shows how it lines up with each step.

You can follow this path with any tool. What matters is that the spec becomes the thing people review, the way a software factory runs on specs instead of chat logs.

A quick checklist before you ship vibe-coded software

Run through these questions before anyone outside your desk depends on what you built. If you answer "no" to any of them, you are not ready to ship.

1. Can you explain what every part of the code does to another person, as Willison's golden rule asks?
2. Has someone run a security scan or review on code that handles logins, payments, or personal data?
3. Are development and production data fully separated, so an agent cannot touch live records?
4. Is there a written spec that says who the software is for, why it exists, and what it must never do?
5. Are the limits on what agents may change written down in the repo, not just in a prompt?
6. Do you have a tested backup and a way to restore it quickly?
7. Will the next change start with an update to the spec?

Vibe coding gets you to the starting line fast. Specs are what keep you in the race once other people are counting on you.