AI coding agents are powerful, but they drift without constraints. Spec-driven development (SDD) solves this by making specifications—not code—the primary artifact.
After hitting the limits of unstructured prompting, I spent time with three SDD frameworks to find what works. Here’s what I learned.
What is spec-driven development?#
Spec-driven development splits the workflow into two distinct phases: planning and implementation.
In the planning phase, human and coding agent collaborate to capture intent. You discuss what you’re building, why it matters, and how it should behave. The output isn’t code—it’s a collection of markdown files that form a memory bank. The memory bank consists of a project mission, a set of accepted feature specs, and a set of rules governing how the agent should behave.
In the implementation phase, the coding agent works from this memory bank to generate source code. The specs constrain what gets built. The rules constrain how it gets built. The agent has everything it needs without hallucinating requirements or drifting from intent.
Maturity levels#
Birgitta Böckeler’s exploration identifies three maturity levels for SDD:
-
Spec-first: Specifications precede code generation for each task. The spec guides the AI, then gets discarded or archived.
-
Spec-anchored: Specs persist after implementation, evolving alongside features. They become living documentation the agent references in future sessions.
-
Spec-as-source: The most ambitious level—specs replace code as the primary maintainable artifact. Humans edit specs, never code. The AI regenerates implementation from specs.
Most tools today operate at levels one or two. Level three remains largely aspirational.
What tools exist?#
The tooling landscape is young and moving fast. Here’s what I found after exploring three open-source SDD frameworks with Claude Code.
GitHub Spec-Kit#
Spec-Kit is GitHub’s open-source toolkit for SDD. It implements a phased workflow where human-written specifications define the “what” and “why” before code generation begins.
What it provides:
- CLI for managing specs and phases
- Templates for structuring specifications
- Prompts designed for AI coding agents
- Integration with Copilot, Claude, and Gemini
How it works: Spec-Kit organizes development into explicit phases. You write specs first, get them reviewed, then hand off to the AI for implementation. The CLI guides you through each phase.
Standout feature: With 60k+ stars, it has the largest community. The structured phases enforce discipline without being overly prescriptive.
Fission-AI OpenSpec#
OpenSpec is a lightweight SDD framework with a similar philosophy to Spec-Kit but a different execution model. It emphasizes a permanent memory bank of accepted specifications.
What it provides:
- Structured specification workflow
- Change proposals with explicit task breakdowns
- Dedicated folders for specs, proposals, and tasks
- Deterministic, auditable outputs
How it works: You create change proposals that reference existing specs. Each proposal breaks down into tasks. When implementation completes, accepted specs get merged into the permanent memory bank. This creates a growing knowledge base the agent can reference.
Standout feature: The permanent memory bank. As your project grows, the agent always has access to accepted specifications. This works well for brownfield projects where context accumulates over time.
AgentOS#
AgentOS takes a broader approach, defining patterns and best practices for AI agent workflows. Specs act as documentation and guardrails rather than the sole source of truth.
What it provides:
- Rich workflow patterns for AI agents
- Built-in support for front-end development
- Visual specification support (mockups, diagrams)
- Audit trail of implemented changes
How it works: Unlike OpenSpec, AgentOS doesn’t maintain a permanent spec library. Instead, it keeps implemented changes in folders, making the development process auditable after the fact. You can include visuals as part of your intent specification.
Standout feature: AgentOS comes with a strong set of pre-defined rules and best practices. It also offers visual specification support. If you’re building UI-heavy applications, being able to include mockups alongside text specs is valuable.
Comparison table#
| Aspect | Spec-Kit | OpenSpec | AgentOS |
|---|---|---|---|
| Philosophy | Phased workflow | Permanent memory bank | Audit trail |
| Spec persistence | Per-project | Accumulating library | Change-based |
| Visual specs | No | No | Yes |
| Community size | 60k+ stars | 16k+ stars | 3k+ stars |
| License | MIT | MIT | MIT |
Which should you choose?#
I started with AgentOS and made good progress, but after a few sessions I found myself missing a permanent memory bank. This led me to OpenSpec, which immediately resonated: it’s lightweight, requires no additional API keys, and breaks change proposals into persistent spec files—each describing a single capability of your software.
But I also found: The Tool Matters Less Than the Discipline
These tools differ in implementation details, but they share what matters: forcing you to write down intent before implementation begins.
The space is young. Tools will evolve, merge, or disappear. What won’t change is the underlying principle: AI agents need structured constraints to produce consistent results.