Every engineering team using AI coding agents eventually hits the same question: do you let the model run free or do you slow it down with a written spec first? That question now has a name on each side of it. Vibe coding is the free-run approach. Spec-driven development (SDD) is the disciplined one.
Neither is right for every project and the teams that get burned are usually the ones that never chose — they just let vibe coding happen by default until it stopped working.
This piece breaks down what each approach actually means, where vibe coding earns its keep, why it tends to fall apart in production and how spec-driven development fixes the failure mode without dragging teams back to pre-AI development speeds.
What Is Vibe Coding?
Andrej Karpathy, the former Tesla AI director and OpenAI co-founder, coined the term in a February 2025 post on X. He described a workflow where he stopped reading the code an AI agent produced: he’d describe what he wanted, accept the changes, paste error messages back in without comment and keep going. His own words were blunt — he said he’d “forget that the code even exists.”
That’s the core of vibe coding: conversational prompting, fast iteration and minimal review of what the model actually writes. The developer’s job shifts from typing syntax to describing outcomes and reacting to what shows up.
It’s worth noting the term already has a sequel. By early 2026, Karpathy himself was calling vibe coding “passé,” arguing that as models got more capable, professional AI-assisted development needed more oversight than the original zero-scrutiny version allowed.
He’s since used the term “agentic engineering” to describe a version of the same idea with more structure baked in — which is really a step toward the same discipline spec-driven development formalizes.
Where Vibe Coding Genuinely Works
Vibe coding isn’t a mistake in every context. It has real, measurable upside in the right setting:
- Speed on defined tasks: In a controlled GitHub study, developers using an AI pair programmer finished a coding task 55% faster than a control group with no AI assistance.
- Prototyping and hackathons: A solo developer can produce a working demo, complete with boilerplate and basic tests, in a single afternoon.
- Disposable code: Internal scripts, one-off data pulls and throwaway proofs of concept rarely need to survive six months, so the long-term cost of skipping structure never comes due.
The common thread is a short lifespan. Vibe coding trades architectural discipline for velocity and that trade only pays off when nobody has to live with the code for very long.
Why It Breaks Down in Production
The problem shows up when a vibe-coded project has to survive past its first few weeks. Several engineering teams have described a similar arc: things move fast for the first month or two, then friction creeps in as new features start colliding with earlier AI-generated decisions and eventually progress stalls because no one — including the original developer — fully understands how the pieces fit together anymore.
Some in the industry now call this the “three-month wall”: a point where compounding technical debt quietly turns a fast-moving codebase into one that resists change.
The mechanism behind it is fairly well understood. Large language models generate code based on the immediate context window in front of them, not a global map of the whole system. Without that broader view, an agent asked to add a feature will often write a new, self-contained block instead of noticing that similar logic already exists elsewhere in the codebase.
Multiply that across dozens of features and the codebase fills up with near-duplicate logic that a human developer would normally have consolidated.
This isn’t a hunch — it shows up in the data. GitClear’s 2025 code quality research, which analyzed 211 million lines of changed code from 2020 through 2024, found that the frequency of duplicated code blocks rose eightfold during 2024 alone and that 2024 was the first year in the dataset where copy-pasted code outweighed refactored (moved) code.
Refactoring — the practice of consolidating and cleaning up existing code — fell from around a quarter of all changed lines in 2021 to under 10% by 2024. In plain terms: AI-assisted teams are writing more new code and cleaning up less of it and that gap is exactly what produces the wall.
What Is Spec-Driven Development?
Spec-driven development responds to that failure mode by putting the specification, not the chat history, at the center of the workflow. Instead of the code being the only source of truth, the spec becomes the source of truth and the AI agent’s job is to implement it faithfully within boundaries a human has already defined.
In practice, this usually means writing a small set of structured documents before any code generation happens. Different tools implement the idea slightly differently. Amazon’s Kiro, for example, produces a requirements.md file using EARS syntax (Easy Approach to Requirements Syntax — a structured “WHEN [condition], THE SYSTEM SHALL [behavior]” format for writing testable requirements), a design.md covering architecture and data models and a tasks.md breaking the work into discrete implementation steps.
GitHub’s open-source Spec Kit, one of the most widely adopted tools in this space, uses a similar but distinct set: constitution.md for standing project principles, spec.md for requirements, plan.md for technical design and tasks.md for the ordered task breakdown.
The naming differs, but the intent is the same — force the “what” and “why” into a reviewable document before the AI touches the “how.” Because these documents live in the repository rather than in a disappearing chat thread, they persist across sessions, survive developer handoffs and give the whole team a shared reference the AI agent can reload every time it starts new work.
The Spec-Driven Spectrum
Not every team applies spec-driven development with the same rigor, and that’s fine — the approach exists on a spectrum:
| Governance Level | How It Works | Trade-off |
|---|---|---|
| Spec-first | A spec is written before coding starts but isn't actively maintained afterward | Low overhead, but the document drifts out of sync with the code over time |
| Spec-anchored | Specs evolve alongside the code and are enforced through CI checks | Balanced governance; keeps documentation and code aligned |
| Spec-as-source | The spec is treated as the actual source of truth, and code is regenerated from it | Maximum consistency, but requires solid validation tooling to trust automated regeneration |
Most teams start at spec-first almost by accident — someone writes a PRD, then the spec quietly stops mattering. Spec-anchored is where the real discipline lives for most production teams today.
Vibe Coding vs. Spec-Driven Development at a Glance
| Factor | Vibe Coding | Spec-Driven Development |
|---|---|---|
| Best-suited timeline | First days of a project | Beyond day 30, for anything meant to last |
| Where context lives | A conversational chat history that doesn't persist | Version-controlled documents in the repo |
| Architectural consistency | Low — the agent reacts locally, not globally | Higher — interfaces and boundaries are defined up front |
| Developer's role | Prompt operator, reactive debugger | System architect and reviewer |
| Best application | MVPs, prototypes, hackathons | Production systems, core business logic |
Choosing the Right Approach
Treating this as an either/or choice misses the point. The two approaches solve different problems and mature teams tend to use both — vibe coding to explore an idea quickly, then a spec-driven pass once the idea is worth keeping.
Loved What You Just Read?
Let's Build Something Just as Great — For Your Business.
From web & mobile apps to UI/UX, AI solutions, and digital marketing — NGD Technolab turns ideas into scalable, real-world products. 14+ years, 550+ projects, one team you can rely on.
A reasonable rule of thumb: if the code needs to still make sense to someone six months from now, write the spec first. If it doesn’t — if it’s a throwaway script, a hackathon demo or a prototype you fully expect to discard — the speed of vibe coding is a legitimate advantage, not a shortcut you’ll regret.
The mistake isn’t using vibe coding. It’s not noticing when a project has quietly graduated into something that needed a spec three features ago.
Conclusion
Vibe coding and spec-driven development aren’t rival ideologies — they’re tools built for different stages of the same project. Vibe coding gets an idea into working shape fast; spec-driven development is what makes that idea safe to build a business on.
The teams managing quality well in AI-native SDLCs aren’t the ones who picked a side. They’re the ones who know exactly when a project has outgrown the chat window and needs a spec instead.
Frequently Asked Questions
What is the difference between vibe coding and spec-driven development?
Vibe coding starts with a conversational prompt and the resulting code becomes the only record of what was built and why. Spec-driven development starts with a written specification — covering requirements, architecture and tasks — and that document, not the chat log, becomes the source of truth the AI implements against.
Is vibe coding suitable for enterprise or production applications?
Generally, no. Vibe coding’s own creator, Andrej Karpathy, scoped it to small, fast-moving, low-stakes projects rather than production systems. For enterprise applications, the lack of persistent context and architectural planning tends to create the compounding technical debt described earlier as the three-month wall, which makes vibe coding a poor fit for anything mission-critical.
Why does vibe coding cause technical debt?
AI agents generate code based on the immediate conversation, not a full picture of the existing system, so they tend to write new, self-contained logic instead of reusing what’s already there. Repeated across many features, this produces the rise in duplicated and copy-pasted code that GitClear’s research has tracked as AI coding adoption has grown.
What are the core documents used in spec-driven development?
Most spec-driven frameworks generate a small set of markdown artifacts before code is written: a requirements document defining what the system must do, a design document covering architecture and interfaces and a task document breaking the work into ordered implementation steps. The exact filenames vary by tool — Kiro uses requirements.md, design.md, and tasks.md, while GitHub’s Spec Kit adds a constitution.md for project-wide principles alongside spec.md, plan.md, and tasks.md.
Can vibe coding and spec-driven development be used together?
Yes, and many engineering teams already do this in practice. A common pattern is to vibe code early on to explore an idea and figure out what’s worth building, then switch to a spec-driven workflow once the project is heading toward production, formalizing the working prototype into a documented, maintainable system before it’s relied on by real users.
