How is AI Changing Spec Driven Development (SDD)?
By
Samara Garcia
•
Early vibe coding with generative AI felt magical because a vague prompt could turn into quick prototypes in minutes. That same approach exposed serious problems when a project grows complex, especially in legacy codebases where architectural patterns, business context, and edge cases are not obvious.
Spec-driven development, or SDD, emerged as a response. Instead of steering AI coding through ad hoc prompts, teams make the spec the primary artifact that guides planning, code generation, review, and validation.
Key Takeaways
AI is shifting SDD from static documents into executable workflows that directly guide code changes.
Modern SDD uses natural language, markdown files, schemas, and a coding agent to turn project requirements into working code.
Tools like GitHub Spec Kit, Claude Code, Kiro, and similar AI tools separate the planning phase from implementation with slash commands and structured artifacts.
Strong context engineering, a good spec, and clear architectural constraints usually matter more than raw model size or large context windows.
Teams in 2026 are using SDD for a new feature, existing codebase changes, and brownfield refactors, with human review at every critical checkpoint.
Spec Driven Development in the Age of Generative AI
Spec-driven development (SDD) is a development paradigm that uses well-crafted software requirement specifications as prompts, aided by AI coding agents, to generate executable code. A specification is a structured, behavior-oriented artifact that expresses software functionality and serves as guidance to AI coding agents.
The core benefit of spec-driven development is separating the stable “what” from the flexible “how.” The specification defines requirements, inputs and outputs, constraints, and acceptance criteria, while the implementation can evolve as technologies, architectures, or business needs change.
SDD builds on practices like behavior-driven development, API contracts, and design docs. AI coding agents can read specifications, inspect repositories, and generate code across multiple files, making clear documentation more valuable than ever. Rather than relying on vague prompts, teams provide AI with structured context, requirements, and guardrails.
Modern SDD workflows often combine natural language, markdown, OpenAPI definitions, JSON schemas, Gherkin scenarios, and design system rules within a single specification. This approach keeps development flexible while ensuring teams and AI tools stay aligned with the intended functionality.
What Counts as a Spec?
A modern spec typically includes:
Business context and goals
User stories and functional requirements
Performance, security, and compliance constraints
Data models, APIs, and integration points
Acceptance criteria, edge cases, and test scenarios
Key technical details and implementation assumptions
In spec-driven development, specifications are living documents that evolve alongside the code. Many teams use executable specs that can generate tests, schemas, contract checks, or CI validations, ensuring the specification remains the source of truth throughout development.
How AI Coding Agents Consume Specs
A coding agent may ingest the spec, a project constitution, steering documents, and relevant code through system prompts, repository search, or local indexing. Tools connected to GitHub, local CLIs, and cloud IDEs now combine specifications with semantic search so agents can operate over large existing codebases without loading every file at once.
Multi-agent workflows often split responsibility. One agent handles requirements analysis, another creates the technical plan, another writes code, and a verifier checks whether the implementation follows the original intent. AI-driven specifications enhance the software development process by serving as a source of truth that guides coding agents, ensuring that the generated code aligns with the intended functionality.
Effective AI-driven specifications require clarity and structure, as vague prompts can lead to incorrect assumptions by AI coding agents, resulting in suboptimal code generation.
GitHub Spec Kit, Slash Commands, and Coding Agents
SDD in real teams usually runs through explicit workflows, not ad hoc chats. GitHub Spec Kit is a concrete example of this trend, with phases that move from specification to plan, task breakdown, and implementation.
Spec-kit is a CLI tool that creates workspace setups for various coding assistants, allowing users to interact with it via slash commands to generate specifications, plans, and tasks. Kiro is a lightweight SDD tool that guides users through a workflow consisting of requirements, design, and tasks, with each step represented by a markdown document. The Tessl Framework, still in private beta, aims to provide a spec-anchored approach where specifications serve as the main artifact maintained and edited, with generated code linked to the specifications.
These workflows are not limited to AI-assisted coding. Teams use them to add a new feature, refactor legacy systems, update existing code, and enforce architectural rules in an existing system. Fonzi-style marketplaces may also help teams find engineers who already know these workflows, especially when the goal is to bring SDD into an AI startup without slowing delivery.
Example SDD Workflow with GitHub Spec Kit
A team might initialize the GitHub Spec Kit through the specified CLI, which creates a .specify folder with templates and prompt definitions. The process often begins with a Constitution document that records non-negotiable rules such as security constraints, logging standards, code review expectations, and design system usage.
From there, slash commands move the workflow forward:
/specify captures the “what” and “why” of the feature, while leaving technical decisions open.
/plan produces a technical plan with architecture notes, API endpoints, data schemas, integration details, and reasonable assumptions.
/tasks turns the plan into small, verifiable work items that humans or AI agents can implement in separate branches.
The iterative nature of spec-driven development allows teams to continuously refine requirements, update the specification, regenerate the plan, and let the coding agent handle implementation as the project evolves.
Using Claude Code and Other Tools in SDD
Claude Code can act as the main coding agent, using context windows to load specs, steering documents, and key repository files. Many teams spend significant time iterating on the spec and plan before generating a single file of code because the cost of fixing the specification is usually lower than fixing scattered implementation mistakes later.
This can include planning an AWS Lambda interceptor, defining request and response schemas, writing Gherkin-style acceptance criteria, and listing edge cases before writing code. Other AI tools, including GitHub Copilot and Gemini CLI, can participate through shared spec formats and the same slash command vocabulary.
Spec-driven development separates stable requirements from flexible implementation details, allowing teams to experiment and refine without incurring high costs from rewrites.
Here is a quick comparison of traditional development and AI enabled SDD.
Aspect | Traditional Development | AI-Enabled Spec-Driven Development |
Source of truth | Tickets, design docs, and developer memory | A living spec that guides code, tests, and review |
Planning artifacts | Requirements, diagrams, and sprint notes | Spec, technical plan, task breakdown, and executable artifacts |
Role of AI | Assistant for snippets or quick suggestions | AI coding agents generate and verify implementation against the spec |
Feedback loops | Human review after implementation | Spec review, plan review, task review, CI checks, and code review |
Typical tools | Issue trackers, IDEs, docs, and CI | GitHub spec, Claude Code, Spec Kit, slash commands, and CI gates |
Handling of existing codebases | Manual exploration and tribal knowledge | Repository indexing, steering docs, and spec anchored changes |
How to Give Coding Agents the Right Information
Context engineering is the discipline of selecting, structuring, and delivering the right project knowledge to AI agents at the right time. It is different from classic prompt engineering because it involves multiple documents, repository structure, long-term memory, design constraints, and project history.
In SDD, a coding session may include the spec, constitution, design docs, AGENTS.md, structure.md, product.md, and selected code files. The goal is not to give the model everything. The goal is to give it the right information so tasks feel bounded and the output stays aligned with the existing code.
Some teams use semantic dependency graphs over 400,000+ file repositories to give agents precise, task-scoped context instead of full repo dumps. This helps prevent hallucinated APIs, duplicated modules, and accidental violations of architectural constraints.
Memory Banks, Steering Docs, and Existing Codebases
Memory banks often include product vision, domain terms, prior technical decisions, examples of correct code, and common mistakes. Steering documents such as product.md, tech.md, and structure.md summarize an existing codebase so models can navigate without exhausting context limits.
Brownfield SDD starts by reconstructing the current behavior. Teams write specs for existing services, add tests around current behavior, then spec incremental changes. CI pipelines can enforce these executable artifacts through schema validation, contract tests, snapshot checks, and security checks, preventing uncontrolled drift from the intended architecture.
Why Precision Matters More Than Raw Context Volume
Simply dumping entire repositories into large context token windows is far less effective than providing a precise subset aligned to a specific task. Strong teams often use a tiered approach, where a stronger model writes or updates the spec, a mid-tier model handles implementation, and a faster verifier compares the result against only the spec and related files.
This is where MCP server integrations are useful. For example, a Figma MCP integration can let an agent read a design system, page hierarchy, layout rules, and tokens before generating frontend specs. That makes context engineering practical, not theoretical.
Design Systems, Executable Specs, and Frontend SDD
Frontend development has become a leading use case for SDD because it ties together design system rules, interaction patterns, accessibility requirements, and component libraries. In 2026, tools can connect to Figma or similar platforms, pulling design tokens, component specs, and constraints into the spec before coding begins.
A frontend spec might decompose work by page or feature, then tell each coding agent which components, variants, responsive states, and accessibility rules to implement. Shared components such as navigation bars, footers, and sidebars can be spec’d as separate tasks, then reused across pages to keep the codebase consistent.
Pulling the Design System Into Context
A coordinator agent can read Figma files, extract layout rules, spacing scales, brand colors, and component constraints, then embed them into the spec as non-negotiable rules. This prevents divergence because every generated page must align with the central design system described in the spec.
Design updates now increasingly start at the spec level. Designers can update tokens or component patterns, then engineering can regenerate plans and targeted code changes without propagating manual updates across the frontend.
From Passive Design Docs to Executable Specs
Traditional design docs require developers to interpret intent manually. Executable specs give an AI agent enough structure to generate and verify code.
Examples include Gherkin scenarios for user flows, JSON schemas for forms, OpenAPI definitions for endpoints, and CSS token tables for theming. SDD workflows can turn these sections into Storybook stories, visual regression tests, layout checks, and linters. This reduces the gap between product, design, and engineering because everyone works from a shared source.
Benefits, Limits, and Practical Tips for AI-Enabled SDD
AI-enabled SDD improves speed, consistency, maintainability, and clarity of intent. It also has limits: model behavior is non-deterministic, specs can drift, and review overhead can grow if markdown becomes sprawling.
SDD does not remove the need for system design, testing discipline, or code review. It amplifies them. Teams usually get the biggest gains when they treat specs as conversation artifacts and living documents, iterating heavily before code generation begins.
SDD is also not a waterfall in a new outfit. Short specs, small tasks, CI feedback, and continuous refinement keep it adaptive. A practical starting point is one service or one contained feature, using GitHub Spec Kit or a similar tool to define the spec, plan, and tasks before implementation.
What Makes a Good Spec for AI Coding Agents
A good spec uses unambiguous language, clear acceptance criteria, explicit constraints, and realistic edge cases. It should use domain vocabulary that matches the existing code and design docs, so the agent can connect new work to old patterns.
Mix freeform text with lightweight structure. Headings, numbered lists, Given/When/Then blocks, tables, and schema snippets are usually enough. Shorter, focused specs per change request tend to work better than giant documents that try to describe the entire system.
Common Failure Modes and How to Avoid Them
Common issues include spec drift, hallucinated APIs, duplicated modules, and agents ignoring constraints. The answer is not only a bigger model. Better templates, sharper prompts, smaller task scopes, and verification gates usually work better.
Build CI checks that compare code changes against specs using schema validation, contract tests, snapshot comparisons, and security checks. Also log where agents ignored or misread the spec, then refine prompts, constitutions, and steering documents so the next run improves.
Hiring Engineers for AI-Enabled Spec-Driven Development
As spec-driven development becomes more common, companies increasingly need engineers who can translate requirements into structured specifications, design effective context engineering workflows, and work productively with AI coding agents. Platforms like Fonzi help teams connect with engineers who have hands-on experience implementing SDD practices, integrating tools such as GitHub Spec Kit and Claude Code, and managing AI-assisted development workflows across complex codebases.
Fonzi Match Day can be particularly useful for organizations adopting AI-enabled development because it helps surface candidates with experience in specification design, agent orchestration, developer tooling, and modern software architecture. As teams move from prompt-driven coding toward spec-driven workflows, finding engineers who understand both software engineering fundamentals and AI-assisted development processes becomes an increasingly valuable advantage.
Summary
AI is transforming spec driven development by making specifications the primary source of truth for planning, code generation, testing, and validation. Instead of relying on vague prompts, teams use structured specs to guide AI coding agents and reduce implementation errors.
Tools like GitHub Spec Kit and Claude Code help turn requirements into plans, tasks, and working code. Success depends on clear specifications, strong context, and human review, allowing teams to build and update software faster while maintaining quality and consistency.
FAQ
How is spec-driven development different from traditional requirements documents?
Can I use spec-driven development with an existing legacy codebase?
Do I need a design system before adopting SDD?
Which tools are useful for getting started with AI-enabled SDD?
How much time should my team spend on the spec before coding starts?
