Over the past year, AI-assisted coding has exploded. Tools like Copilot, Claude Code, and GPT-based agents have made it possible to generate large amounts of code simply by describing what you want.
As this space evolves, two very different approaches have started to emerge:
- Vibe Coding — directly prompting the AI and iterating quickly
- Spec-Driven Development — using frameworks that generate structured specifications, user stories, and tasks before code is written
Spec-Driven Development is currently being promoted as the correct way to build serious applications with AI. The idea is that instead of randomly prompting an AI model, you give it a structured environment where requirements are broken down systematically.
But after actually trying it on a real project, I found that the reality is more nuanced.
This article shares my first impressions after experimenting with Spec-Driven Development, using OpenSpec as the framework.
Watch Full Video
What Spec-Driven Development Actually Is
The simplest way to understand Spec-Driven Development is this:
Instead of telling an AI agent “build this feature”, you start by generating a structured set of documents describing the application.
These typically include:
- Specifications
- User stories
- Detailed tasks
- Architecture notes
- Feature definitions
The AI agent then executes those tasks one by one instead of responding directly to a single prompt.
Frameworks such as OpenSpec and GitHub SpecKit are designed to automate this breakdown.
In theory, this should produce more reliable and maintainable AI-generated code, especially for larger projects.
Compared to vibe coding, the workflow looks more like a traditional software engineering process.
Why Vibe Coding Gets Criticized
Many developers argue that Vibe Coding only works for prototypes.
The common criticisms are:
- Prompts are too vague
- Context gets lost quickly
- AI can generate inconsistent architecture
- Large projects become chaotic
Spec-Driven Development attempts to fix this by introducing structured requirements and controlled execution.
Conceptually, that makes a lot of sense.
But once you start using these frameworks, you quickly notice some trade-offs.
The Hidden Cost of Spec-Driven Workflows
The first thing that stands out is how document-heavy the process becomes.
Frameworks like OpenSpec generate large numbers of markdown files containing:
- specifications
- user stories
- task lists
- development notes
Before the AI agent even starts writing code, the developer is expected to review these artifacts.
This introduces two new costs that people rarely talk about.
1. Human review time
Someone still needs to read through the generated tasks and verify that they make sense.
2. AI token usage
All of these markdown files must be processed by the AI agent.
That means tokens, API calls, and subscription credits are being used before any code is even written.
In some cases, the specification layer can become so verbose that the overhead starts to outweigh the benefit.
The Real Bottleneck Is Still the AI Model
One of the most important realizations when experimenting with Spec-Driven Development is this:
The framework is not the main bottleneck.
The AI model itself is.
Spec frameworks simply break down prompts into smaller steps. But the model executing those steps still determines whether the output is good or bad.
During my testing, the differences between models were very noticeable.
Some models were:
- slow
- required constant approval
- struggled to execute task chains
Others were dramatically faster and more capable.
This means that when something goes wrong, it's not always obvious what the real issue is:
- Was the prompt too large?
- Was the specification poorly generated?
- Or was the AI model simply not good enough?
Spec frameworks don't solve this problem.
They only reorganize how instructions are delivered to the AI.
Comparing Spec-Driven Frameworks
There are already several frameworks trying to define this workflow.
Two of the most visible ones right now are:
OpenSpec
- Lightweight
- Less process-heavy
- Easier for solo developers
GitHub SpecKit
- Much more structured
- Feels designed for larger teams
- Stronger emphasis on process
At the moment, SpecKit probably feels like the most complete implementation.
But the ecosystem is moving incredibly fast, so it's hard to predict what will dominate long term.
Interesting Experiments: Multi-Agent Systems
One of the more interesting ideas appearing in this space is multi-agent orchestration.
Frameworks like BMAD experiment with the idea of multiple AI agents working in parallel on a single specification.
Instead of one agent executing a long list of tasks sequentially, different agents can handle separate sections of the project.
Interestingly, modern tools like VS Code are already beginning to support similar ideas by allowing developers to run multiple AI agents simultaneously.
This concept may become a major part of AI-driven development in the future.
The Extreme Version: Spec as Code
Another fascinating project in this space is Tessl.
Tessl pushes the concept of Spec-Driven Development to its logical extreme.
The philosophy is simple:
The specification is the application.
In this model:
- Developers primarily edit specifications
- The code is generated from those specs
- The entire application could theoretically be rebuilt from the specification alone
It's a powerful idea, but it also feels very futuristic for most real-world development teams today.
The Approach I Currently Prefer
After experimenting with these frameworks, I found myself preferring something slightly different.
Not pure Vibe Coding.
Not full Spec-Driven Development.
Something in the middle.
A workflow I would describe as Structured AI Coding.
The idea is simple:
- Organize feature requests into folders
- Write detailed instructions in markdown
- Give the AI agent clear context
- Let the agent generate a plan before writing code
What this approach avoids is the heavy pipeline of:
- generated user stories
- automated task breakdowns
- large specification trees
Instead, the developer directly provides clear structured instructions for each feature.
Many modern AI coding agents already support this workflow through planning modes, where the AI shows its intended steps before making changes.
In practice, this feels:
- faster
- more direct
- less bureaucratic
while still giving the AI enough structure to work effectively.
My Overall Take on Spec-Driven Development
Conceptually, Spec-Driven Development is a very strong idea.
It addresses a real limitation of Vibe Coding: AI needs context and structure when projects become large.
However, the current hype around Spec-Driven workflows sometimes ignores the cost vs benefit trade-off.
These frameworks introduce additional layers:
- specification files
- task breakdown systems
- documentation pipelines
All of this adds complexity that both humans and AI must process.
And even after going through that entire workflow, the final output can still be limited by the capabilities of the AI model.
So while Spec-Driven Development is definitely an interesting direction, it doesn't magically solve every problem in AI-assisted development.
Right now, the most practical approach may simply be a lightweight structured workflow somewhere between Vibe Coding and full Spec-Driven Development.
And interestingly enough…
That middle ground hasn't really been formally defined yet.
Watch Playlist on YouTube
Spec Driven Development - YouTube
Spec-Driven Development is an emerging approach to AI-assisted software development, where AI agents generate code based on structured specifications instead...
youtube.com
Top comments (0)