AI-assisted coding has changed software development faster than most developers expected.
In just a short time, many developers went from experimenting with prompting an AI to generate small snippets of code to attempting to build entire applications with AI agents.
Two major approaches have emerged from this shift:
- Vibe Coding — directly prompting an AI model and iterating quickly
- Spec-Driven Development — using structured frameworks that break requirements into specifications, user stories, and tasks before the AI writes code
Spec-Driven Development is increasingly being promoted as the professional way to build applications with AI. Compared to vibe coding, the idea is to bring structure, planning, and traceability back into the development process.
But after experimenting with these frameworks on real projects, my experience has been more mixed.
Spec-Driven Development is a compelling idea, but the current implementations still come with trade-offs that are often overlooked.
Watch Full Video
The Core Idea Behind Spec-Driven Development
Traditional AI coding often looks like this:
You give an AI a large prompt describing what you want, and the model attempts to generate the entire solution.
That works surprisingly well for small projects, but problems appear quickly as complexity grows:
- context gets lost
- architecture becomes inconsistent
- features interfere with each other
- prompts become increasingly complicated
Spec-Driven Development attempts to solve this by introducing structured artifacts between the developer and the AI.
Instead of directly generating code, frameworks first generate documentation such as:
- system specifications
- feature descriptions
- user stories
- development tasks
The AI agent then executes these tasks sequentially.
This makes the workflow resemble traditional software development processes, where requirements are decomposed before implementation begins.
In theory, this should make AI-generated software more reliable.
The Reality: A Lot of Documentation
The first thing that becomes obvious when using a Spec-Driven framework is how document-heavy the workflow becomes.
Tools like OpenSpec generate large numbers of markdown files that describe every feature and task.
Before the AI agent even begins writing code, developers are expected to review these artifacts to ensure they accurately reflect the intended design.
This introduces two types of cost.
Human review overhead
Developers now spend time reading through AI-generated specifications, tasks, and user stories.
In smaller projects, this review process can sometimes take longer than simply writing a well-structured prompt.
AI processing overhead
Every one of those markdown files must also be processed by the AI agent.
That means additional:
- tokens
- API calls
- subscription costs
And all of this happens before the AI starts generating any code.
In some scenarios, the specification layer can become so verbose that it starts to feel like unnecessary bureaucracy.
The Framework Is Not the Bottleneck
Another important realization is that Spec-Driven frameworks don’t actually solve the most important problem in AI coding.
The real bottleneck is still the AI model itself.
Spec frameworks mainly perform one function:
They decompose large prompts into smaller tasks.
But if the AI model executing those tasks is slow or inaccurate, the final result will still be limited.
In my testing, the difference between models was dramatic.
Some models required constant approvals and were slow to complete tasks. Others executed the same instructions much faster and with fewer errors.
Because of this, it becomes difficult to determine where a problem originates:
- Was the prompt too complex?
- Was the specification breakdown incorrect?
- Or was the AI model simply not capable enough?
Spec-Driven frameworks cannot fix limitations in the underlying model.
They only change how instructions are organized.
Different Frameworks, Different Philosophies
The Spec-Driven ecosystem is still young, and several frameworks are experimenting with different approaches.
Some aim to remain lightweight and developer-friendly.
Others introduce more rigid processes designed for team environments.
For example, OpenSpec tries to keep the workflow relatively simple and approachable, which makes it appealing for solo developers.
Other frameworks, such as GitHub’s SpecKit, appear to target larger development teams and incorporate more structured processes.
Because the space is evolving quickly, it’s difficult to say which approach will ultimately become the standard.
Multi-Agent Development Is an Interesting Direction
One of the more intriguing ideas emerging in this space is multi-agent orchestration.
Instead of a single AI agent executing tasks sequentially, multiple agents can work on different parts of a specification simultaneously.
Some frameworks experiment with orchestrating multiple agents across different sections of a project.
This idea is particularly compelling because it mirrors how human development teams operate.
Interestingly, some development environments are already introducing similar capabilities by allowing developers to run multiple AI agents at the same time.
If coordinated properly, multi-agent workflows could significantly speed up large AI-driven projects.
The Extreme Vision: Specification as Code
Some projects push the concept of Spec-Driven Development even further.
One example is Tessl, which promotes the idea that the specification itself should be the primary artifact of the application.
In this model:
Developers maintain the specification rather than the code itself.
The system generates the code automatically, and the entire application can theoretically be reconstructed from the specification.
It’s a fascinating concept, but it still feels somewhat futuristic for most real-world projects today.
The Workflow That Feels Most Practical Right Now
After experimenting with Spec-Driven frameworks, I found myself gravitating toward a simpler approach.
Not pure vibe coding.
Not full Spec-Driven Development.
Something in between.
A workflow I would describe as structured AI coding.
The idea is straightforward:
- organize features in folders
- maintain clear markdown instructions
- give the AI detailed context
- let the agent generate a plan before implementation
This avoids the heavy pipeline of automatically generated user stories and tasks while still providing the AI with structured guidance.
Many modern coding agents already support this style of workflow through planning modes.
In practice, this feels faster and more flexible while still maintaining clarity.
Final Thoughts
Spec-Driven Development is an important step toward bringing structure to AI-assisted software development.
The concept itself is strong, especially for large projects where vague prompts quickly break down.
However, the current hype sometimes overlooks the cost-benefit balance.
Spec frameworks introduce significant overhead:
- more documentation
- more review steps
- more tokens consumed by AI
And even after all of that, the final result is still limited by the capabilities of the AI model.
At the moment, the most practical workflow may lie somewhere between vibe coding and full Spec-Driven Development.
A lightweight structured approach that provides clear context without introducing excessive process.
Interestingly, that middle ground still doesn’t have a widely accepted name.
But given how quickly AI-driven development is evolving, it probably won’t stay that way for long.
