Building complex applications with AI requires more than good prompts. It requires a structured framework — and that framework has a name.
What Is Spec Driven Development?
Spec Driven Development (SDD) is a structured AI coding workflow where AI agents generate code based on formal specifications rather than freeform prompts. It's how engineering teams manage AI when building large, complex systems — the same way you'd onboard a human developer by giving them proper documentation, architectural guidelines, and a structured backlog before they write a single line of code.
The core principle is simple: context before code.
Before any code is generated, the AI agent is given:
- What the application does and who it's for
- The full technology stack (language, framework, database, libraries)
- Architectural patterns and coding standards
- Business rules, edge cases, and acceptance criteria
- A breakdown of features into Epics, User Stories, and Tasks
This isn't a long prompt. It's a structured set of documents — typically markdown files — that live in your repository, persist across sessions, and evolve alongside the project.
The result: the AI doesn't guess. It doesn't make wrong assumptions. And the developer doesn't spend hours correcting output that missed the mark.
Watch Video
https://youtu.be/0atkW_janVg?embedable=true
The Other Approach: Vibe Coding
Vibe coding is the natural, instinctive way most developers use AI. You have a feature, you describe it in plain language, code comes out. Iterate, repeat.
For small projects, quick prototypes, and isolated features, it works well. It's fast, it feels productive, and the feedback loop is tight.
The problem isn't the approach itself. The problem is applying it to systems that are too large and too complex for it to handle.
Why Vibe Coding Breaks Down at Scale
Imagine building a car classifieds web application — user accounts, listings, search filters, pricing logic, saved searches, dealer profiles, messaging. A realistic, medium-to-large project. Vibe coding this means tackling one small prompt at a time, across many sessions, over many days.
Here's where it falls apart:
AI has no persistent memory across sessions. Every new chat is a blank slate. You're constantly re-establishing context that should already exist. Tomorrow morning you'll open a new session and spend the first ten minutes explaining what you're building — again.
AI can't track project state. It doesn't know what's been built, what's still outstanding, or what architectural decisions were already made. You do. Until you forget.
AI fills gaps with assumptions. When context is missing, the model guesses. Sometimes correctly. Often plausibly but incorrectly — and plausible-but-wrong is the most dangerous kind of wrong in a growing codebase.
Technical debt compounds invisibly. Each session adds code that's slightly misaligned with the broader architecture. Individually harmless. Collectively, a mess that eventually costs more time to fix than the AI ever saved.
Some developers try to compensate with pseudo-code, detailed comments, or basic markdown files — a well-intentioned effort to provide more context. These are patches on a process that was never designed for complexity.
Spec Driven Development: How It Actually Works
Most SDD frameworks follow a consistent execution model. Here's what the workflow looks like in practice:
Step 1 — Initialize You feed the framework your high-level requirements. It generates a foundational context document — sometimes called a "constitution" — that captures everything the AI needs to know about this project before touching any code. Stack, architecture, business rules, dependencies. As much detail as possible.
Step 2 — Generate specs The framework produces structured artifacts: application overview, full feature list, user stories, tasks. These live in your repository as markdown files — not in a chat window that disappears when the session ends.
Step 3 — Human review Before execution starts, a developer reviews and approves the specs. This is the checkpoint that vibe coding skips entirely — and it's where most AI misunderstandings get caught before they become real problems.
Step 4 — Execute from specs The AI agent works from approved specifications. Not from your memory of what you typed last Tuesday. Not from a fresh interpretation of a vague prompt. From structured, versioned, human-approved specs.
Step 5 — Track progress As tasks complete, the framework maintains state. The AI knows what's done, what's in progress, and what's next. This persists across sessions — across days, weeks, and months.
The Mental Model Shift
Here's the reframe that makes SDD click:
In vibe coding, the AI is a tool. Stateless. Contextless. You invoke it, it responds, the session ends.
In Spec Driven Development, the AI is a team member. It has onboarding documents. It follows architectural standards. It works from a backlog. It knows the history of the project. It doesn't need to be reminded every morning what you're building.
This isn't a philosophical difference. It's an architectural one — and it changes what you can realistically build with AI assistance.
The Frameworks Worth Knowing
Several SDD frameworks have matured to the point of being production-ready:
Speck Kit — GitHub-native. Generates and manages spec files directly in your repo. Clean integration with existing git workflows.
OpenSpec — Open standard approach. More framework-agnostic, good for teams that want flexibility in integration.
BMAD Method — Breaks requirements into Epics, Features, Stories, and Tasks. Opinionated structure, which is a feature not a bug.
Kiro — Specification-first with AI agent execution built in. Less DIY assembly required.
Tessl — Focuses on progress tracking alongside spec management. Well suited for longer-running projects.
When to Use Each Approach
This isn't an argument that vibe coding is bad. It's an argument that it's often misapplied.
Use vibe coding when:
- You're prototyping or exploring an idea
- The project scope is small and well-defined
- You're building an isolated feature with no complex dependencies
- Speed matters more than long-term maintainability
Use Spec Driven Development when:
- The project will take more than a few days to complete
- Features have interdependencies
- The codebase involves complex business logic
- Long-term maintenance matters
- More than one developer will touch the code
The threshold is simple: if losing AI context between sessions would meaningfully hurt the project, you need SDD.
Getting Started Without a Full Framework
If you want to experiment with SDD before committing to a framework:
- Write a proper project brief before opening any chat window. Stack, architecture, key business rules.
- Break your requirements into structured markdown files — features, user stories, tasks — and keep them in your repo.
- Start each AI session by loading the relevant spec file, not by retyping context from memory.
- After each session, update your spec files to reflect decisions made and work completed.
This is manual SDD. It requires more discipline than vibe coding. It's significantly less painful than refactoring a codebase that was built without it.
The Bottom Line
Spec Driven Development is what happens when you treat AI-assisted development as an engineering discipline rather than a series of chat sessions. It gives the AI agent everything it needs to behave like a focused, context-aware contributor — one that retains project knowledge, follows architectural guidelines, and tracks progress across the full lifecycle of a build.
The developers who will build the most sophisticated systems with AI aren't the ones with the best prompts. They're the ones with the best workflows.
Next up: why vibe coding isn't actually bad, and how both approaches fit into a mature AI development practice.