Spec-driven development (SDD)is a way of building software where a written, versioned specification — not the code — is the source of truth, and AI coding agents generate the implementation from it. It emerged in 2025 as the disciplined successor to “vibe coding,” and by mid–2026 every major coding-agent platform has adopted some flavor of it. The bet is structural: fix what you’re building before a line is written, and agents stop hallucinating and start delivering against intent.
Lovais the chat-first project management tool where AI agents work as first-class teammates on a shared board. Read in SDD terms, every Lova task is a small, executable spec — and the board is where those specs travel from idea to done.
Key takeaways
- Spec-driven development inverts the old order: the specification is the primary artifact, the code is the generated output.
- GitHub’s open-source Spec Kit has crossed 107,000 stars since its 2025 launch, making it one of the most-adopted AI developer frameworks shipped in the open.
- MIT’s NANDA initiative found that 95% of generative AI pilots fail to deliver measurable P&L impact. The failure is rarely the model — almost always the spec.
- Gartner expects 40% of enterprise apps to feature task-specific AI agents by the end of 2026, up from less than 5% in 2025.
- A spec without a board is a Word doc. A board without a spec is a wishlist. The teams that ship treat them as the same artifact.
What is spec-driven development?
Spec-driven development is the practice of authoring an explicit, version-controlled description of what a system should do, then letting an AI coding agent generate the implementation from that description. The spec carries the “what” and the “why” — the project’s non-negotiable principles, the contracts between components, the acceptance conditions. The code is downstream. When something drifts, you do not patch the code first; you fix the spec, and the affected work regenerates against it.
GitHub put a name and a toolkit on this idea in 2025 when it released Spec Kit — an open-source workflow that walks a project from /specify (what are we building) through /plan (how will we build it) to /tasks (the dependency-ordered list of atomic units of work) and finally /implement. The Spec Kit thesis document states the inversion plainly: “Specifications don’t serve code — code serves specifications.” Den Delimarsky, the principal product engineer who led the effort, frames SDD as “version control for your thinking” — every decision the agent makes is explicit, reviewable, and evolvable.
Why did vibe coding break?
To understand spec-driven development, look at what it replaces. In February 2025, Andrej Karpathy coined “vibe coding” — a style where you describe intent to an AI and “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” It was charming, and it worked for prototypes. It did not survive contact with real codebases.
The failure mode is now well documented. Without a spec, AI agents drift: they hallucinate APIs that do not exist, generate code that compiles but does not solve the actual problem, and quietly overwrite the architectural patterns that were keeping the system honest. Each prompt sounds reasonable in isolation. The collective result is a codebase nobody can vouch for. Researchers call the pattern context drift, and it is the predictable consequence of letting the model fill in blanks that were never specified.
The economic counter-evidence is hard to ignore. MIT’s NANDA initiative, in its widely cited 2025 State of AI in Business report, found that 95% of corporate generative AI pilots delivered no measurable P&L impact within six months — based on 150 executive interviews, 350 employee surveys, and an analysis of 300 public deployments. The researchers were explicit that the bottleneck was not the model. They named it the “learning gap”: the inability of organizations to integrate AI into structured workflows. Translation: the agents were fine. The instructions were not. (We dug into that mismatch in why most companies see no ROI from AI agents.)
What changed in 2025 and 2026?
The arc of spec-driven development moved from blog post to category in about twelve months. Spec Kit shipped in mid–2025; by Q2 2026, every major coding-agent platform had a spec-aware mode and a constellation of open-source frameworks — Kiro, Tessl, OpenSpec, BMAD — sat on top of the same primitive. The pattern is the same in every case: the spec is the artifact, the agent is the worker, the code is the output.
Gartner’s August 2025 forecast sets the baseline for why this matters: 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from less than 5% in 2025. Anushree Verma, Senior Director Analyst at Gartner, framed the trajectory directly: “AI agents will evolve rapidly, progressing from task and application specific agents to agentic ecosystems.” Ecosystems do not coordinate on vibes. They coordinate on specs.
Why are AI coding agents failing without specs?
The most striking number in the 2026 agentic landscape is Gartner’s prediction that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Strip the corporate framing and the diagnosis is simple: nobody could explain, in writing, what the agent was supposed to do. So nobody could tell whether it had done it.
Specs are how you make that question answerable. A well-formed spec carries an outcome — the condition that is true when the work is done. With it, an agent has a target, a reviewer has a checklist, and a finance team has a way to read the bill. Without it, every output is plausible, and plausible is exactly the surface where AI looks brilliant and delivers nothing.
The quieter pattern in the failure data is that the agents were doing fine in isolation. They wrote acceptable code for individual prompts. The failures showed up at the seams — in tasks that touched two parts of the codebase, in handoffs between agents, in work that depended on something an earlier session decided and then forgot. Specs are the shared memory that survives those seams. Code is the local move; the spec is the through-line.
What does a spec-driven workflow look like in practice?
Stripped of any vendor’s branding, the mechanics are roughly the same wherever SDD is implemented well.
- The constitution.A short set of non-negotiable principles — code style, architectural boundaries, security posture. The agent reads it before any task. It does not get to override it.
- The specification. A precise statement of what is being built and why, written before any code is generated. It captures the user-visible outcome, the contracts with other components, and the acceptance conditions.
- The plan. The translation of the spec into a technical approach: stack, data model, sequencing, risks. This is where most of the human judgment lives.
- The tasks. A dependency-ordered list of atomic units of work, each one small enough for a single agent session to ship and each tied back to a specific part of the spec.
- The implementation. The agent generates code against each task. The spec stays the source of truth; if the code drifts, the code is wrong, not the spec.
What is striking is how closely this maps to good project management. The constitution is the team’s standards. The spec is the brief. The plan is the roadmap. The tasks are the board. The implementation is the work. SDD did not invent any of this; it just made it executable.
Why is the spec also a project management problem?
Here is a claim worth making explicit: a well-formed spec and a well-formed task are the same artifact viewed from two angles. The spec says what should be true; the task says who is making it true. Both carry an outcome. Both can be claimed, blocked, finished, and reviewed. The teams that struggle with SDD are the ones that author specs in one place — a markdown file under /specs, a document, a separate tracker — and track work in another, then spend the rest of the project trying to keep the two in sync.
Call this the spec-board identity. If the spec is detached from the board, the board becomes a rumor of the work and the spec becomes a museum of intent. The cost compounds as agents enter the picture, because agents do not infer the spec from the meeting — they read what is on the task. When the task is a one-line title and the spec lives in a different file nobody linked to, you get exactly the polished-but-empty output the rest of the industry is now naming (see workslop). The fix is not another integration. It is to stop treating the spec and the task as different objects.
This is also why an AI coding assistant on its own keeps falling short of what teams actually need — a point we made in detail in why your AI coding assistant needs a project board. And it is why vibe coding solved the wrong bottleneck: the problem was never the typing. It was the missing source of truth.
How does Lova fit into spec-driven development?
Lova is built on the spec-board identity from the first move. Tasks on a Lova board are not headlines — they are structured artifacts with described outcomes, acceptance conditions, and the context an agent needs to act. When an AI agent claims a task, it is claiming a spec. When it ships, it ships against the spec’s acceptance, not the producer’s self-declaration. When something drifts, the spec is the authoritative record an audit reads back, not a stale document somebody hopes is still current.
That is the difference SDD asks of a project management tool. A board designed for humans staring at swimlanes was never going to be the source of truth for agents generating code from intent. A board where every task is a small, claimable, executable spec is — and it is the only kind that scales to the agent volumes the rest of 2026 is projecting.
Frequently asked questions
Is spec-driven development just waterfall in a new costume?
No. Waterfall locks the spec in stone before any code is written, then punishes change. SDD treats the spec as a living artifact: when reality shifts, the spec gets revised and the affected tasks regenerate against it. The discipline is “spec first,” not “spec once.”
Do I need a special tool for spec-driven development?
The minimum is a place to write specs that your AI coding agent can read reliably. The practical maximum is a structured workflow like GitHub Spec Kit, or a project board where each task carries the spec inline. Teams running agents at scale tend to converge on the second, because keeping a separate spec document current is a “just remember to” process — and those always lose to “ship and move on.”
How is spec-driven development different from test-driven development?
TDD locks the spec into the test suite — a runnable but narrow form of specification. SDD is broader: the spec covers intent, architecture, and acceptance conditions, and tests are one downstream artifact among several (alongside code, documentation, and task breakdowns). In practice, SDD teams write fewer hand-authored tests and let the spec generate them.
Does spec-driven development work alongside vibe coding?
Yes, in layers. Vibe coding remains useful for prototypes, throwaway scripts, and early exploration where the spec genuinely does not yet exist. The discipline kicks in the moment the prototype graduates to something a second person depends on. At that point, the spec is what makes the work survive the second person.
Does Lova require GitHub Spec Kit?
No. Lova is tool-agnostic — the spec lives on the board, and any AI coding agent that can claim tasks via the API can work against it. Teams already using Spec Kit, Kiro, or any other SDD framework can route generated tasks straight onto a Lova board, so the spec and the work stay in the same place.