# Spec-driven development with AI agents

> Treat a human-readable, testable specification as the primary artifact, and split the work into small spec, plan and task cycles that an agent implements against.

- **Source:** https://ainativesoftware.engineering/pillars/spec-driven-development
- **Site:** AI-Native Software Engineering — https://ainativesoftware.engineering/book

- **Published:** 2026-08-08
- **Updated:** 2026-08-08
- **Reading time:** 19 minutes
- **Series:** Pillar 3 of the pillars of AI-native engineering
- **Tags:** spec-driven development, SDD, vibe coding, BMAD, Spec Kit, Kiro

In this pillar we look at what spec-driven development (SDD) is, how it emerged from vibe coding, what problems it solves and how it works. Then we go through the tools in the space so you can judge which one fits your use case. At the end, since SDD is a new concept, we look at the challenges and open topics standing between it and a mature methodology.

## The rise of vibe coding

It's February 2025. Andrej Karpathy, one of the most influential AI scientists of our time, publishes a post on X. Karpathy has just invented the term "vibe coding".

![Andrej Karpathy's post coining the term vibe coding](https://ainativesoftware.engineering/images/pillars/sdd_1.png)

The idea is simple: you describe in plain English what you want, the AI interprets the request and tries to build code that satisfies it. You don't do planning or research. You don't evaluate tradeoffs or account for risks. You just describe your functional needs, and the AI fills the gaps and implements it.

In just a few months, vibe coding platforms emerged. The promise was simple: from now on, everyone — not just engineers — will be able to create fully working applications.

Demos were great, examples were shiny, websites created with these tools were cheap to build and started to generate revenue.

Everyone forgot one important thing, though. Karpathy, in the end, mentions that this form of interaction with AI is not really coding.

>   You see stuff, say stuff, run stuff, copy paste, fix when things don't work and it mostly works.

— Andrej Karpathy

If you're reading this, you're probably a software developer, an architect, or in general someone who knows how to code. As you may guess, this approach is very limited and cannot be used for production-grade applications.

## Vibe coding limitations

Vibe coding looks magical in demos, but when people started using it for real projects a long list of problems appeared. The core issue is simple: the AI guesses. And when you build software on guesses, things break in surprising — and sometimes painful — ways. People even started advertising themselves as "vibe coding cleanup specialist".

![A job listing for a vibe coding cleanup specialist](https://ainativesoftware.engineering/images/pillars/sdd_2.png)

Let's go through the biggest limitations, with real stories that circulated online in early 2025.

### AI doesn't always respect your instructions

**You write 'don't change production', 'freeze code', 'ask me first', and the AI may ignore it. In a production environment that has catastrophic consequences.**

In mid-2025 the platform Replit Agent reportedly [deleted a live production database](https://hackaday.com/2025/07/23/vibe-coding-goes-wrong-as-ai-wipes-entire-database), despite explicit code-freeze instructions. The CEO of Replit [publicly apologised](https://www.businessinsider.com/replit-ceo-apologizes-ai-coding-tool-delete-company-database-2025-7): "unacceptable and should never be possible."

> **Warning**
>
> If you're treating vibe-coded output as fully autonomous production-grade code, you're playing with fire.

### Code quality, readability and maintenance suffer

**When AI generates large chunks of code from your prompts, you may not fully understand what it did, or why. That is a long-term maintenance problem, not a short-term one.**

According to one large-scale study, AI-generated snippets had a high proportion of [security weaknesses](https://arxiv.org/abs/2310.02059) — 29.5% of Python snippets had issues — when using tools like GitHub Copilot. Many tools skip standard security practices, compliance checks such as GDPR, or proper code review.

**Common issues**

- Old or outdated libraries used via AI-generated code
- Missing parameter validation and injection risk
- Policies not enforced because the AI "just wrote something that worked"

**Risk areas**

If you're working in a regulated environment — education tech, healthcare, finance — this is a red flag.

### Debugging and traceability challenges

**Since you didn't author every line, when something breaks you might struggle to trace it. The AI's reasoning is hidden in prompts and model behaviour, not in documented architecture.**

If you have real engineering knowledge, you'll recognise the mismatch:

**What vibe coding skips**

Much of planning, architecture and risk analysis.

**Trust issues**

It puts trust in an agent that may not understand your domain, and may not respect constraints.

**Quick but brittle**

It delivers working code quickly — but maybe wrong, insecure or brittle.

**Missing engineering**

In production-grade systems you still need design, review, governance, testing and monitoring.

> **The takeaway**
>
> Vibe coding is _cool_, and it is useful for prototyping and rapidly iterating on ideas — yes, you can build a side project over pizza. But it is not a replacement for proper software engineering when the stakes are high.

## From vibe coding to AI-native engineering

Vibe coding is not well suited for actual production-grade code. What if, instead of abandoning AI, we step back, remove the hype, and think about how to use AI as a real engineering tool across the software development lifecycle? That is the move from vibe coding to **AI-native software engineering**.

When we treat AI as a partner rather than an all-knowing magic box, interesting opportunities — and challenges — open up:

**Better code quality**

AI can take the repetitive, error-prone work and free humans for design, architecture and edge cases. It can generate test cases or suggest documentation.

**Faster throughput**

Studies show AI tools help engineers save hours per week and increase productivity when used well.

**More focus on value**

Engineers spend less time on boilerplate and more on the parts that really matter: business logic, reliability, maintainability.

**Better collaboration**

Instead of "AI did this, hope it works" you get "AI helped me do this, I reviewed it, we built it together".

How do you move from vibe coding to AI-native engineering, though? The risk is to say "fine, I'll just write code manually again". There has to be a better way: a middle ground where the human and the AI collaborate to build high-quality software. Here are the key principles.

![The principles of AI-native engineering](https://ainativesoftware.engineering/images/pillars/sdd_3.png)

### Context-rich input instead of a simple prompt

**In vibe coding you might just say 'build a user-login page'. In AI-native engineering you provide the system with context: existing architecture diagrams, coding standards, dependency graph, module boundaries, style guidelines.**

This is also called a **memory bank** in some tools.

Without that context the AI generates code, but you're left deciphering it, integrating it, and maybe discovering it violates your conventions. The research around AI-native engineering emphasises that "just prompt" is not enough. Usually, when we give only a prompt, agents perform **dynamic context discovery**: they read your files, search your codebase and try to understand how you normally write code.

> **Try it**
>
> If you want to test the power of proper context, give the AI your API spec, target frontend and backend stack, and SLA or throughput targets, then ask "create the endpoints for user management" rather than "make a login page".
>
> To go deeper, read the [context engineering pillar](https://ainativesoftware.engineering/pillars/context-engineering).

### Human-in-the-loop, and no full autonomy

**One of the biggest issues of vibe coding is letting the system run without human oversight. AI-native engineering uses AI as a collaborator, and humans remain accountable.**

Architecture review, security review, integration and deployment still involve people. This layered approach reduces risk.

Think of AI as the friendly intern who can whip up drafts, while you're still the senior engineer who says "yep, sign it off" — or "nope, go back and fix this".

To go deeper, read the [human-in-the-loop pillar](https://ainativesoftware.engineering/pillars/human-in-the-loop).

### Divide and conquer

**Break the system down and use AI where it helps most.**

Instead of asking for "build the whole system", vibe-coding style, you break the project into modules or phases — epics and stories, if that sounds familiar — assign AI-assisted tasks to particular scopes, then integrate.

**Manageable reviews**

Divide and conquer makes reviews manageable and reduces the risk of chaotic AI output.

**HITL integration**

Together with HITL it is a powerful way to review AI-generated code.

**Gradual expansion**

It lets you pick safe bets for AI first — low-risk modules — and gradually expand.

Once you are using AI as a collaborator, the next question is: how do you define **good specs** the system can work against? How do you formalise your context and integrate AI into your SDLC in a controlled manner? That is where spec-driven development comes in.

## Spec-driven development

![Spec-driven development — the specification as the driving artifact](https://ainativesoftware.engineering/images/pillars/sdd_4.png)

At its core, spec-driven development is about flipping the old "code first, document later" workflow by letting specifications become the driving artifact for AI-native engineering.

The key idea is simple: we treat the **specification** — what we want, why, and under which constraints — as the source of truth. We give the AI that spec plus context, then let it generate the code, and maybe tests and tasks too. Humans validate, evolve the spec and steer the AI. We do _not_ hand over fully autonomous control.

A spec earns its keep twice. Once on the way in, as the context the agent builds from; and once on the way out, because acceptance criteria written down in advance are the thing a reviewer, human or machine, can check the diff against. That second use is where [verification and quality gates](https://ainativesoftware.engineering/pillars/verification-and-quality-gates) picks the thread up.

SDD tries to overcome vibe coding's limitations by leveraging all the concepts mentioned above.

### SDD is still evolving

**As ThoughtWorks researcher Birgitta Böckeler puts it, the definition of spec-driven development is still in flux.**

She [describes it explicitly](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html): "Like with many emerging terms… the definition of 'spec-driven development' (SDD) is still in flux." Put another way: we're still figuring out how exactly to do SDD. The tools are appearing and the vocabulary is emerging, but it is not yet a matured methodology.

Because the methodology is new, each tool developed so far has its own flavour and practices. There is no one-size-fits-all version of SDD yet: your organisation will need to tailor it.

This approach is similar to what FAANG engineers are doing in the industry, as reported in this thread on Reddit:

![A Reddit thread describing spec-first workflows at large tech companies](https://ainativesoftware.engineering/images/pillars/sdd_5.png)

## Tools and frameworks

Since SDD is emerging, a number of tools and frameworks are being built to support it. They reflect different ways of implementing the same intuition: spec becomes truth, AI generates, human reviews. In this section we look at how different tools implement different versions of SDD.

![An overview of the spec-driven development tool landscape](https://ainativesoftware.engineering/images/pillars/sdd_6.png)

### Kiro

### Kiro: an agentic AI IDE from AWS

**Instead of writing a prompt, you write a goal, and Kiro helps you plan, design and build across multiple files and tasks.**

If standard AI code tools are like "here's a code snippet", Kiro is more like "let's map out what we're building, how we'll build it, then generate the list of tasks and write code for each one."

![The Kiro interface, showing specs, tasks and diffs side by side](https://ainativesoftware.engineering/images/pillars/sdd_7.png)

Many developers using AI assistants complain: "it generated code, but I don't know how it made decisions, it doesn't fit my architecture, I lose track of changes." Kiro addresses those UX issues by:

**Planning first**

The UI gives you markdown specs — `requirements.md`, `design.md`, `tasks.md` — to review and edit before code is generated. That gives clarity and reduces surprises.

**Structured workflow panels**

Side panels for specs, tasks, hooks and agent chats. The familiarity reduces friction.

**Diff and review mentality**

Instead of blind generation, you see the changes Kiro wants to make and approve or reject them. That gives control and removes AI surprise.

**Persistent context (steering and hooks)**

You define project-wide rules in steering files so the AI aligns to your architecture, naming conventions and test strategy. Agent hooks automate repetitive work — updating tests, docs — when certain files change.

### How to use Kiro: from idea to code rollout

**Here is how you might use Kiro in a real project.**

**1. Install and set up**

Visit the Kiro website and download the version for your OS — macOS, Linux or Windows. Install it and sign in. Optionally, import your existing VS Code settings so the UI feels familiar.

**2. Define your feature or goal**

In the chat or command panel, describe what you want to build: "I want to add authentication and password reset to our web app." Kiro takes that intent and generates a `requirements.md` with user stories and acceptance criteria, which you review and edit.

**3. Design phase**

Once requirements are approved, Kiro analyses your codebase — or a scaffold — and proposes a `design.md`: architecture, data flows, interfaces, tech stack decisions. You review the design and refine the nuance: "use Postgres, not MySQL", "use React and TypeScript for the frontend".

**4. Task breakdown**

Kiro breaks the design into `tasks.md`: discrete, actionable steps such as create the user model, implement the login API, write unit tests, update docs. Each task links to the requirements or design parts it covers. You then pick a task to execute, or run them in sequence.

**5. Execution and review**

When you click "start task", Kiro applies changes to your codebase. It supports two modes: supervised, where you review each diff, and autopilot, where it proceeds but you still review the final result. You inspect diffs and test results, and evaluate whether the code meets the spec. If something doesn't align you adjust the spec, design or task list and re-run — or chat with the panel on the right to fix the code.

### Hooks and automation

**Agent hooks are triggers that run automatically when certain events happen: a file save, a new file, a commit.**

For example: "when a new React component is added, auto-generate a unit test skeleton and update the docs." These hooks keep the workflow consistent and reduce manual boilerplate.

### Steering and project context

**Steering files are markdown documents holding your project's conventions, architecture decisions and style guides.**

Kiro refers to them to guide its output, so naming, patterns and testing style follow your rules. Example steering files: `steering/tech_stack.md`, `steering/tests_convention.md`. Over time Kiro learns your project style and fits new code to it.

> **Strength**
>
> One of the big strengths of Kiro is the UI and UX, and how it implements spec-driven development. Because Kiro offers so much guidance during the workflow, it is easy to use and has a very gentle learning curve.

### Spec Kit

Want to see Spec Kit in action? Watch the [video overview](https://www.youtube.com/watch?v=a9eR1xsfvHg).

![The Spec Kit video overview title card](https://ainativesoftware.engineering/images/pillars/sdd_8.jpg)

### Spec Kit: a flexible, open-source, command-based framework

**Think of it as a lightweight shell around your favourite AI coding assistant.**

You install a small CLI, use slash commands in the IDE, and the toolkit helps you scaffold **specs → plans → tasks**, rather than diving straight into telling the AI to write code.

> **Tool-agnostic**
>
> Spec Kit works with multiple AI agents and doesn't lock you into a vendor or a proprietary platform.

Here is how it works, in plain developer terms:

**1. Install and bootstrap**

Install the `specify-cli` into your existing environment. Run `specify init <PROJECT_NAME>` — or use slash commands inside your AI assistant — and pick your coding agent of choice, such as GitHub Copilot or Claude Code. The tool scaffolds a directory structure: a `.specify` or `specs/` folder, plus prompt templates.

**2. Define your constitution (optional but recommended)**

Use `/speckit.constitution` to document your non-negotiable rules: project conventions, styles, testing mandates. This becomes part of the AI's context so it doesn't go rogue and pull in random libraries or ignore your style.

**3. Write the spec**

Use `/speckit.specify` to declare _what_ you want and _why_. Not the nitty-gritty of how, but the feature or requirement — "build a user photo album with date grouping and drag-and-drop". This spec becomes the artifact the AI uses as its starting point.

**4. Generate the implementation plan**

Use `/speckit.plan` to convert the spec into the "how": tech stack, architecture decisions, module breakdown, dependencies. You can review and edit this plan.

**5. Break down into tasks**

`/speckit.tasks` creates granular actionable items — user stories, tasks and sub-tasks, test cases, docs updates — based on the plan. This lets your AI, and you, pull one task at a time rather than having the AI do everything in one shot.

**6. Execute implementation**

Use `/speckit.implement` to instruct the AI to draft code, tests and docs for those tasks within the context of spec plus plan plus tasks. You still review, test, merge and integrate as normal.

### BMAD Method

![The BMAD Method workflow, from analysis through planning and solutioning to implementation](https://ainativesoftware.engineering/images/pillars/sdd_9.png)

### BMAD: a full end-to-end SDD workflow

**Arguably the most powerful current methodology for SDD. It offers a full, end-to-end workflow for engineering with AI assistance, and it gives you expandability.**

You can customise agents and workflows, and tailor the system to your own domain or organisation.

In short: BMAD treats specification and planning as **first-class artifacts**, defines distinct agents — Analyst, Product Manager, Architect, Developer, Scrum Master — each with a clear function in the workflow, and guides code generation, integration, testing and review in a structured way.

The methodology takes you from analysis to planning, from solutioning (architecture and design) to implementation, so you're not skipping design and context.

> **Open source**
>
> BMAD is fully open source and can be installed and used in your favourite IDE or agentic environment. No vendor lock-in, and no new tool that breaks compatibility with your current workflow.

Here is how BMAD typically plays out. Think: you're still in charge, AI helps, you still review, you enforce quality.

**1. Analysis phase**

The Analyst agent helps gather and clarify high-level intent: business goals, market and competitive context, the user problem. You work with the agent to define the _why_ and the _what_ at a broad level, not yet coding. The output is a brief but clear business case, feature description or scope document. The benefit is that it reduces ambiguity early and avoids asking AI to write code without framing.

**2. Planning phase**

The Product Manager agent converts the business case into a complete PRD. The Architect agent takes that and produces system-level design: high-level architecture diagrams, module boundaries, data flows, interface definitions. You review and refine — choose the tech stack, define constraints such as libraries to use or avoid, coding standards, deployment model.

**3. Solutioning and task breakdown**

The Scrum Master agent breaks the design into granular work items: epics, tasks, sub-tasks, dependencies, test cases, docs to update. Each task comes with background context and relevant spec pointers, so the AI working on it knows _why_.

**4. Implementation phase**

The Developer agent — or the agent and you — implements the tasks: code, tests, docs, possibly CI/CD changes. AI makes the first draft; you review diffs, test results, and adherence to spec and architecture. If something doesn't align, you loop back, adjust the spec or task, and regenerate. At each merge or release you still apply standard engineering practice: code review, security scan, performance review. The output is working code, tests and docs, all traceable to the spec.

### BMAD limitations

**BMAD is incredibly powerful, but it is not a magic shield that prevents all errors.**

#### There is no strict enforcement layer for the agents yet

BMAD defines clear roles — Analyst, Architect, Developer, QA — but the system will not _force_ an agent to behave exactly within that role. If you or the model drift outside the intended workflow, and the Scrum Master starts writing code, BMAD won't automatically stop you. You can still accidentally misuse an agent or skip essential steps if you are not careful.

#### BMAD has a learning curve

For teams new to spec-first thinking, the mental shift can feel uncomfortable at first. You must learn how to:

- write actionable specs rather than jumping straight into coding
- choose the right agent for the right step
- maintain clean context for the AI
- review output with stricter discipline

After a few cycles teams get used to the rhythm and the structure becomes natural. Once that happens, BMAD's benefits become much more obvious and consistent.

### Other players

These tools evolve quickly and new approaches emerge almost weekly, so this is not meant to be a comprehensive list — more a set of pointers to start your own investigation.

### Tessl: an AI-native development platform

**The idea is to shift from writing a lot of code manually to defining specifications — what you want — and letting AI or a framework generate and maintain the code under clear guardrails.**

Tessl offers two main pieces:

**Spec registry**

Pre-built specs — 10,000 and counting — for common libraries and patterns.

**Framework, CLI and toolchain**

Integrates specs into your codebase, and lets you generate code, test it and maintain it.

A simplified flow:

1. You write a spec file describing a component: what it does, its public API, maybe constraints or tests. In Tessl this might use `@generate`, `@describe` and `@test` annotations.
2. The framework uses that spec to generate code — or link to existing code — and produce tests.
3. The code is part of your project, and the spec remains the source of truth, so future modifications reference the spec first rather than free-hand code.
4. If you upgrade a library or make a change, the spec and registry help ensure agents don't hallucinate APIs or introduce unintended side effects, one of the problems Tessl explicitly cites.

Learn more at [tessl.io](https://tessl.io/).

### OpenSpec: an open-source CLI tool

**OpenSpec is an open-source CLI tool and workflow framework supporting spec-driven development for AI coding assistants.**

In plain terms: before you ask the AI to code, you _agree_ with the AI and your team on what will be built — the spec — then you execute, then you archive the spec.

It supports many AI coding tools (Claude Code, Cursor, CodeBuddy and others) via slash commands or CLI commands, so you don't need to commit to a specific vendor, similarly to Spec Kit or BMAD.

Learn more at [Fission-AI/OpenSpec on GitHub](https://github.com/Fission-AI/OpenSpec).

## What should I use?

Choosing between Kiro, Spec Kit and BMAD comes down to how much structure you want, how much change your team is willing to adopt, and how deeply you want AI woven into your engineering workflow.

**Kiro**

A guided, visual experience embedded directly inside an IDE. The UI helps you plan, design and execute features with AI side by side, almost like a built-in project navigator. Ideal if you like strong guardrails and a clear workflow in a friendly interface. **The tradeoff:** you'll likely need to work inside a new IDE, which means a small disruption to your habits.

**Spec Kit**

Simple to install, simple to use, easy to layer on top of your current AI agent. It uses a set of commands to generate specs, plans and tasks without forcing you into a new tool. Low vendor lock-in, gentle learning curve. **A great lightweight SDD starter kit** for teams who want spec-driven thinking without changing how they code day to day.

**BMAD**

The full power of a complete, customisable SDD workflow. It manages the entire lifecycle, assigns distinct AI roles, and lets you create tailored agents or processes that fit your domain. Highest flexibility and depth, but the most discipline and onboarding. **You trade simplicity for control and extensibility.**

> **In the end**
>
> The tradeoffs typically revolve around four things: UI and UX, vendor lock-in, learning curve, and customisation.
>
> If you want a smooth visual experience, pick **Kiro**. If you want simplicity and compatibility with your current AI assistant, pick **Spec Kit**. If you want full control, full workflow management and room to experiment with custom agents, **BMAD** is the strongest option.

## Current limitations of spec-driven development

![The open problems still facing spec-driven development](https://ainativesoftware.engineering/images/pillars/sdd_10.png)

Even though SDD holds a lot of promise — formal specifications plus AI plus human-in-the-loop — it is still very much an emerging methodology. There are several practical limitations teams and organisations are facing right now.

I deeply believe these limitations are temporary and will be fixed in a relatively short amount of time, through technical solutions, tooling, or new team practices and improved workflows.

### Mismatch between spec size and task complexity

**The size and depth of a specification, and of the other generated artifacts, don't yet scale smoothly with the size and complexity of the task.**

When the work involves a large module, many dependencies or complex integrations, writing a full spec plus plan plus task breakdown makes sense and brings real value.

But for smaller features or quick changes, the overhead of a full specification workflow becomes **burdensome**, often outweighing the benefits. In effect there is no streamlined "lightweight spec" path yet: teams either skip the spec approach for minor work, losing consistency, or apply it and spend more time upfront than they gain downstream.

This imbalance means spec-driven development currently works best for mid-to-large efforts, but struggles to fit comfortably into quick, small-scoped tasks.

#### Emerging solutions

Tools like [BMAD](https://github.com/bmad-code-org/BMAD-METHOD) have started to implement features such as Quick Flow, tailored for bug fixes and small features.

Other tools are trying to smooth out the imbalance. Editors like Cursor and GitHub Copilot introduced a Plan mode, which gives the AI just enough space to think before coding without forcing the developer through a full, heavyweight specification workflow. Instead of a large formal spec, the model produces a brief one-page plan: a bit of research, a short outline of steps, and a clear explanation of what will change.

This lighter structure keeps small tasks consistent and intentional without slowing teams down with unnecessary ceremony. It is not a full solution yet, but it is a promising middle ground that makes spec-driven thinking practical even for quick fixes.

### Team settings and collaborative workflows are under-defined

**Most SDD tools and workflows are oriented toward individual developers or small prototyping contexts, rather than full team, multi-role, enterprise workflows.**

Many toolkits assume a single developer writes the spec, then the AI generates code, then the same developer reviews. But real development teams have product owners, business analysts, architects, QA, operations and security.

What this means practically:

**Role alignment**

Who owns the spec? How do roles align across product, architecture, dev and QA?

**Collaboration**

How do multiple team members contribute to and edit the spec?

**Versioning and branching**

How are versioning, branching and collaboration handled in the spec layer?

**Integration**

How does the workflow integrate with sprints, agile ceremonies, code reviews and CI/CD?

Because these aspects are not yet mature, teams risk creating process friction when adopting SDD. Some tools are making progress, but there is not yet a standard for working in multi-repo contexts.

### Legacy systems, brownfield code and integration challenges

**SDD works best when you are building something new. Most organisations maintain large legacy systems.**

Some SDD tools currently struggle with:

**Understanding context**

Understanding existing codebase context and dependencies.

**Integration**

Generating specs and code that integrate cleanly with existing modules, rather than assuming a fresh start.

**Alignment**

Aligning generated code with existing architecture, patterns, conventions and non-functional requirements.

Using SDD for legacy systems is possible, but often involves additional overhead — reverse-engineering context, refactoring before writing the spec — which takes time, needs review, and may still miss requirements and business needs the AI cannot reverse-engineer.

### Tooling maturity, consistency and reproducibility

**One of the biggest hurdles in practice is the maturity and predictability of the tools and AI agents involved.**

#### Reproducibility

Unlike a traditional compiler, where the same input and settings reliably produce the same output, AI-based generation guarantees nothing of the sort. As one practitioner puts it: "output varies across tools and models. The same spec will produce different code from different agents."

#### Context and scope

Large or complex specifications, big codebases, numerous files and dependencies can exceed an agent's effective context window, or lead to context blindness where the AI misses earlier constraints or architectural rules. The result: generated code that works but does not meet the underlying intent or integration requirements.

#### Evolving ecosystem

Many of the frameworks and agents branded for SDD are experimental, with frequent breaking changes, limited support and few established best practices. Teams adopting SDD face tool fatigue, migration pain, inconsistent workflows and thin documentation.

#### Measurement and feedback

How do you quantify the benefit of SDD plus AI tooling? What metrics show defect reduction, velocity improvement or spec-to-code alignment? These questions remain largely unanswered in published practice.

> **Warning**
>
> Without robust feedback loops, teams may adopt SDD out of hype rather than clarity.

### Skills, culture and change management

**Adopting SDD changes how teams work: writing specs becomes a central task, humans shift roles, and AI becomes part of the flow.**

The skills and culture of teams may need to adapt. Some limitations here:

**Writing skills**

Writing good, actionable specs is hard. Not all product owners, architects or developers currently have that skill set.

**Resistance to change**

Teams may resist the perceived overhead of spec writing.

**New roles**

New roles or responsibilities — spec owner, AI-agent reviewer — might not yet exist in many organisations.

**Over-reliance risk**

There is a risk of over-reliance on AI output, or of under-review.

There is a learning curve for a team to adopt these tools and learn to use them properly, so teams or specific members might resist the change.

## Summary

Spec-driven development is a compelling evolution of how we work with AI in software engineering. We move from ad-hoc vibe coding toward a structured workflow — **specify → plan → tasks → implement** — with AI as collaborator and humans as reviewers. But it is not yet fully matured.

**Where we are**

Even though there are limitations, the future is bright: we can expect lightweight modes, better collaboration tooling, living specs and contracts, brownfield integration, agile-friendly workflows, mature metrics, and teams fully trained in the new way of working.

**The path forward**

SDD represents a fundamental shift toward more intentional, structured and collaborative software development. As the methodology matures and the tools evolve, we can expect these limitations to be addressed, making SDD accessible and practical for teams of all sizes.

## Frequently asked questions

### What is spec-driven development?

Spec-driven development flips the "code first, document later" workflow. The specification — what we want, why, and under which constraints — becomes the source of truth. The AI receives that spec plus context and generates code, tests and tasks against it, while humans validate the output and evolve the spec.

### How is spec-driven development different from vibe coding?

Vibe coding means describing a desire in plain English and letting the model fill every gap: no planning, no tradeoff analysis, no risk assessment. Spec-driven development keeps the speed but restores the engineering — an explicit spec, an implementation plan, task breakdown and human review at every gate.

### Should I use Kiro, Spec Kit or BMAD?

Pick Kiro for a guided, visual experience inside a dedicated IDE. Pick Spec Kit if you want a lightweight, tool-agnostic layer over the AI assistant you already use. Pick BMAD if you want a full, customisable end-to-end workflow with distinct agent roles and are willing to absorb the learning curve.

### What are the current limitations of spec-driven development?

Spec size does not yet scale down to small tasks, team and multi-role workflows are under-defined, brownfield and legacy integration is hard, AI generation is not reproducible across tools and models, and there are no established metrics for proving that SDD is paying off.

---

_AI-Native Software Engineering by Alfonso Graziano (O'Reilly Media, Early Release; print edition February 2027). Every page of ainativesoftware.engineering is also served as Markdown: append `.md` to any URL. Index: https://ainativesoftware.engineering/llms.txt — whole site in one file: https://ainativesoftware.engineering/llms-full.txt._