Over the last few months, AI-powered software development has moved from early curiosity experiments to a daily practice for many teams. Tools like Copilot and other LLMs for developers let you generate code from increasingly rich prompts, but as projects grow, the clear limits of plain vibe-coding start to show. This is where Spec Driven Development (SDD) comes in: a paradigm that tries to bring order to the way you use artificial intelligence to write software.
Let's look at a typical scenario. You write a prompt for your AI assistant:
"Implement a React registration form with real-time validation for email and password, error handling, a POST request to /api/register, a modern Tailwind style, state management via Zustand, and HTTP calls with Axios."
In a matter of seconds the LLM generates a complete component. It looks well-structured, has validations, visual feedback, even a small success toast. You integrate it, test the happy path, everything works. Commit and deploy. Then reality comes knocking, and the quality team flags an endless list of issues.
This is an example of AI-driven software development based entirely on gut-feel prompts (in other words, vibe-coding). The concrete limits of vibe-coding become obvious pretty quickly:
In short, vibe-coding has played (and still plays) an important role: it accelerated prototyping, lowered the barrier to entry, and helped many teams discover the real potential of AI coding agents and AI at the service of developers. But it's no longer sufficient when it comes to software that needs to operate in enterprise contexts.
To go beyond gut-feel prompt engineering, you need a shift in paradigm. The perspective has to change: from code driven by intuition and appearance, to code driven by explicit, verifiable, and shared specifications. That's exactly where Spec Driven Development fits in.
Spec Driven Development (SDD) means treating specifications as the central and most important element of a project (the true source of truth) rather than the generated code. But this isn't about classic specs written in Word, PDFs, or Confluence pages that go stale the moment a release ships.
We're talking about executable specifications, built for AI-powered software development, written in a language understandable by both humans and machines, that describe the system's purpose, usage scenarios, and constraints in a precise and unambiguous way.
If you're familiar with Test Driven Development (TDD) and/or Behavior Driven Development (BDD), here's how the analogy works. Think of SDD as TDD taken to the next level and made collaborative with AI:
In other words, the developer's intent (your intent) becomes the real "spec" that governs the LLM.
To understand how this approach changes the way you work, it helps to map out the typical workflow of a developer adopting Spec Driven Development. The phases below give you a useful mental model.
In the specification phase, the developer describes the expected behaviour of the system in structured natural language: the user journey step by step, business goals, the main use cases alongside relevant edge cases, and all non-negotiable validation rules or constraints.
Your work here is primarily one of analysis and intent formalisation, not code writing.
Starting from this narrative, the AI generates a formal, detailed specification: JSON schemas for requests and responses, validation rules with concrete examples, expected and failure cases in Given-When-Then format, business invariants, and mocks for any external services.
Importantly, this is not a one-shot activity. It's not simply a matter of the developer defining things upfront and the AI then refining and structuring them. Rather, it's an iterative process in which the developer works alongside the AI, defining the specifications: the what and the why of the project.
Equally important, specifications must be maintained over time so they don't become stale as the actual implementation progresses and the project naturally evolves.
In the planning phase, the developer defines the non-negotiable technical constraints: the technology stack, preferred architecture, libraries to use for validation, state management, HTTP calls and testing, plus any performance or bundle size limits.
The AI then produces a complete and realistic technical plan, covering the folder structure, the main components with their respective responsibilities, the data flow, the chosen libraries and the reasoning behind them, the error and loading state management strategy, and the mocks needed for testing.
At this stage, prompting becomes genuine prompt engineering: you're no longer asking "do X for me", but guiding an AI agent with clear, verifiable constraints.
In the task breakdown phase, the AI takes the approved plan and splits it into atomic, ordered, and independent tasks. Each task is designed to be small, independently testable, and tied to clear acceptance criteria, often linked directly to one or more examples from the specification.
This step makes the work feel much closer to a classic agile backlog, but one generated and kept consistent with the spec.
Finally, there's the implementation phase. The AI generates code one task at a time, always respecting the agreed specification and plan. The developer reads and validates small, targeted code chunks: checking that the code handles both typical cases and the expected edge cases, running local tests or previewing the result, and either approving the output or requesting targeted corrections. The cycle is fast, usually 5 to 15 minutes per task.
This way, the LLM becomes a collaborator you're in control of, not a generator of monolithic blocks that are hard to understand.
At this point you have a complete flow: from specification to implementation, with the AI following clear rules instead of improvising. The next step is choosing the right tools to support this way of working.
GitHub Spec Kit remains the open source reference point. It's a modular toolkit that lets you write specifications in structured markdown (with JSON schemas, Given-When-Then examples, and invariants), validate them automatically, and generate code via contextualised prompts to any LLM.
Its strength lies in its simplicity, transparency, and the fact that it doesn't lock you into a single provider: you can use it with Claude, GPT, Gemini, or local models. It's the ideal starting point for teams that want to experiment with SDD without vendor lock-in.
OpenSpec is an open source framework for SDD with coding agents. What makes it stand out is how well it suits brownfield contexts with legacy code. Rather than high-level requirements, its strength is defining operational requirements for individual agents, starting from the context of an existing codebase and feeding it a single issue.
It's easy to get started with: just run openspec init to integrate it into a codebase, and it installs only three commands: proposal (proposes a new change), apply (implements it), archive (archives it and updates the specs). One interesting aspect is how it keeps current specifications (the "source of truth") separate from proposed changes, in two distinct folders that are reconciled when changes are archived.
This keeps diffs manageable and tracked at all times, a key requirement in many contexts. It's also very lightweight, using only markdown files, and supports all the major coding assistants you're probably already using (Claude Code, GitHub Copilot, OpenCode, Cursor, Windsurf...).
There are also numerous other, more niche SDD frameworks with specific capabilities. One example is Spec-Kitty, designed for those who want high orchestration capabilities (parallel execution of multiple agents without conflicts) combined with full visibility into what's actually happening and what each agent is working on. Its most distinctive feature is a visual dashboard that automatically tracks all progress, letting you view planned, in-progress, under review, and completed tasks in a kanban-style board, as well as see which agents are working on which task.
In the video "So you think you know Copilot?", we also go into a practical deep dive showing the interaction with the AI agent, highlighting how a well-executed Spec Driven Development approach changes the way you use tools like GitHub Copilot.
For those looking for a more integrated experience than classic Copilot, the most interesting alternatives are Kiro and Tessl. Kiro focuses on a collaborative workflow with "constitutions" (style and architecture rules enforced at the project level) and automatic checklists for every generation. It's particularly useful in large teams where consistency is critical.
Tessl, on the other hand, represents the most radical approach: it's the first true spec-as-source tool. The specification is the only modifiable artefact, code is regenerated from scratch with every change, and the project's history lives almost entirely in the spec itself. It's the choice for those who want to push to the maximum the idea that code is a derived output, not the source of truth.
If you want to see how AI can also support the DevOps and delivery side, you can explore the topic further in this article on AI, DevOps and Platform Engineering.
SDD doesn't reduce the developer to a simple "reviewer of AI-generated code". On the contrary, it elevates them to a strategic, high-value role: from someone who wrote every line, to someone who defines, orchestrates, and guarantees the quality of the entire system.
In the traditional model, the developer was often an executor of requirements, translating technical details and business logic into code once those had been partially formalised. With Spec Driven Development, the focus shifts decisively upward:
In practice, you write far less boilerplate code, but invest significantly more in critical thinking, system design, clear communication of requirements, and deep validation skills. These are rare competencies, difficult to automate, and increasingly in demand on the market.
At SparkFabrik, we see this shift as a tremendous opportunity. Our mission isn't to replace development teams with artificial intelligence, but to help your team evolve toward roles of greater impact and value.
Spec Driven Development comes with several concrete advantages:
Of course, not every context benefits equally. SDD delivers its maximum value in three main scenarios.
Greenfield refers to projects started from scratch, with no legacy constraints, pre-existing architectures, or accumulated technical debt. In this context, Spec Driven Development reaches its full potential: specifications become the true origin point of the system and guide the entire process from the very first commit.
The architecture is born already aligned to functional and non-functional requirements, technical decisions are traceable and motivated, and the risk of divergence between project vision and concrete implementation is drastically reduced.
Specifications are not just initial documentation: they become a structural backbone that reduces surprises, prevents evolutionary inconsistencies, and limits the build-up of early technical debt, creating solid foundations for the system's future scalability.
Brownfield refers to contexts where you're working on existing systems: legacy platforms, architectures layered over time, complex ecosystems already in production. In these scenarios, Spec Driven Development isn't about "building from scratch", but about making explicit what is often only implicit: architectural constraints, dependencies, integration contracts, emergent behaviours, and structural limits of the system.
Specifications become a tool for formalising the real context, precisely defining touch points, compatibility rules, and functional boundaries. This enables the AI to generate code that is truly contextualised, reducing the risk of regressions, integration errors, and systemic inconsistencies.
The result is increased evolutionary throughput, greater confidence in releases, and a tangible simplification of long-term maintenance, even in highly complex software ecosystems.
In this case, SDD makes the transition gradual and controlled: the desired behaviours of the new code are described first, reverse engineering is tackled in a structured way, specifications are redefined or updated, and obsolete portions are replaced. This way you can reduce regressions, manual overhead, and the risk of breakage, while requiring an initial investment to contextualise the existing system.
Like any emerging paradigm, Spec Driven Development brings real benefits but also concrete risks. Here are the most common traps to watch out for.
Elaborate workflows with dozens of markdown files, checklists, and constitutions can create overhead that outweighs the benefit, turning a small fix into a heavy bureaucratic process. Or worse, the attempt to improve can end up making the initial situation worse (literally "worsening-improvement").
AI-generated specs tend to be redundant, repetitive, and tedious to review. Instead of providing clarity, they increase cognitive load: more text to read than code to write.
It's important to avoid treating SDD as the exhaustive but "hollow" writing of requirements that nobody reads, as a form of bureaucracy creation, or as "waterfall planning": a sterile exercise in extensive upfront planning that tries to account for every eventuality and the entire future of development.
Instead, Spec Driven Development is about making technical decisions explicit and reviewable, as well as easy to understand (not just for machines, but especially for people) and straightforward to evolve.
Too vague, and the AI misunderstands and generates incorrect code. Too rigid, and the process becomes inflexible, impossible to adapt to rapid changes or brownfield contexts. Finding the right balance takes practice and iteration.
Even with detailed specs, checklists, and large context windows, AI often ignores instructions, duplicates existing code, or over-applies rules. Non-determinism persists: the same spec can produce different output on every regeneration.
This is the central challenge of the new programming paradigm, no longer deterministic, but tied to probabilistic AI tools. This paradigm shift is explored in depth in the talk by Enrico Zimuel at our GenAI x Business event.
In complex codebases or particularly long working sessions, agents can lose track of part of the context: implicit relationships between components, decisions already made, or changes previously applied. Without a continuous anchor to the specifications, this can lead to inconsistencies, duplications, or unintentional regressions.
For trivial fixes, the overhead is disproportionate; for very complex or ambiguous features it often isn't enough; and introducing it on legacy codebases requires a high initial investment. Moreover, if the specification isn't kept up to date it becomes a more dangerous source of confusion than the code itself, repeating the historical mistakes of model-driven development: rigidity combined with unpredictability.
Being aware of these limits lets you apply Spec Driven Development where it actually makes sense, and avoid turning it into a new dogma.
Spec Driven Development represents a new frontier of AI-driven development, a direction in which many teams are experimenting with different approaches. Within this context, an even more radical evolution is taking shape: spec-as-source development.
Under this approach, the specification becomes the only stable and modifiable artefact. When requirements change, the tech stack shifts, or a better LLM model comes along, you update only the spec → the plan, tasks, and code are regenerated accordingly, automatically. The project's history lives in the spec itself, including the "commit history". Code loses its central role: it becomes a derived output, temporary and regenerable.
Tools like Tessl are already pushing in this direction, though they are still very experimental (currently limited to a one-to-one spec-to-code relationship), while Agent Skills (originally from Claude and now open source, donated to the Agentic AI Foundation) point to a parallel trend: autonomous agents executing complex tasks under guardrails defined by specifications. One example is Superpowers by Obra on GitHub for development tasks, while Skills.sh brings together thousands of Skills covering the widest range of areas, from frontend design to brainstorming to copywriting.
This paradigm profoundly changes the developer's role. An inexperienced person stays in vibe-coding mode, relying on generic prompts (and getting generic results). A senior developer, on the other hand, unlocks explosive potential: providing precise specifications, rigorous guardrails, and solid architecture, transforming AI from a random generator into a reliable and tireless executor.
SDD in the context of AI is still young, with nuances still evolving and best practices still being discovered. The direction, however, is clear: it won't be "here's my prompt, run it, I'll wait" anymore, but "here are the tasks, the rules, and the direction, keep working".
Looking further ahead, we'll see a "workforce shift", with machines and agents operating 24/7 while humans supervise, define intent, specifications, architecture, and other high-value aspects. Writing code will become less central; writing clear, verifiable, and durable specifications will become a core skill for the modern developer.