Is Spec‑Driven Development a Savior or a Burden in the Age of AI‑Generated Code?

01 | What problem does SDD solve

By 2025, 25% of YC winter batch startups have 95% of their code written by AI, which accelerates delivery but also triggers a "technical debt explosion" as AI‑generated code introduces hidden risks that collapse quickly during refactoring. Spec‑Driven Development (SDD) is presented as a response: instead of letting AI write code from free‑form prompts, teams first create a testable, formal system specification that acts as a dynamic contract between humans and AI.

The key difference from traditional waterfall is the feedback loop: waterfall freezes the spec at a stage gate, while SDD continuously updates the spec through short cycles. ThoughtWorks places SDD in the "Assess" quadrant of its technology radar, signalling that it is worth evaluating but not yet ready for blanket adoption.

02 | Three levels of spec

Spec‑First (first layer) : The spec is a guiding document; code remains the primary deliverable. Developers use the spec to steer AI‑generated code but retain responsibility for the final code. This is essentially a modernized requirements‑document‑first approach with minimal added value.

Spec‑Anchored (second layer) : The spec becomes a living document that evolves with the project. Code and spec stay synchronized, and the spec serves as the central artifact for team collaboration, delivering genuine incremental value.

Spec‑as‑Source (third layer) : The most aggressive stance where humans maintain only the spec and the code is a disposable by‑product generated from the spec (marked with // GENERATED FROM SPEC - DO NOT EDIT). Deterministic generation is required for this to be viable, but no existing tool fully achieves it yet.

03 | Kiro: AWS's IDE experiment

Amazon launched Kiro Preview in July 2025 (GA in 2026) as a standalone IDE built on Code OSS, aiming to reshape the development workflow rather than just add a plugin.

Core mechanism – three‑stage gate :

Requirements(EARS format) → Design → Tasks
    ↓ approval          ↓ approval   ↓ execution

Kiro forces the use of the EARS format, requiring each requirement to include acceptance criteria. Each stage must be manually approved, turning the "think first" principle into a mandatory process.

Parallel task execution : Automatic analysis of task dependencies enables independent tasks to run in parallel, reducing large‑spec implementation time from over an hour to about a quarter of that.

Quick Plan mode : For clear requirements, Kiro can generate requirements, design, and tasks in one step, bypassing the three‑stage approvals.

Requirement analysis : A neural‑symbolic AI checks requirements for ambiguity, conflict, and omission.

Practical evaluation : Advantages include a 200k‑token context window (10× a typical IDE) and progressive indexing that loads documents on demand; acceptance criteria act as a natural decision filter, reducing over‑engineering. Drawbacks are a steep learning curve, excessive overhead for trivial changes (e.g., a single null‑check), criticism of the credit‑based pricing model, and lack of Chinese‑language support.

Kiro’s gate process aligns with Spec‑First, but its progressive indexing and spec‑evolution features give it Spec‑Anchored characteristics; it does not reach Spec‑as‑Source.

04 | spec‑kit: the open‑source rigorous route

GitHub’s spec‑kit is the only MIT‑licensed open‑source project among the three tools, with 1,119 commits and an active community. Its philosophy is "specification is law" and it implements a seven‑stage gate:

Constitution → Specify → Clarify → Plan → Tasks → Analyze → Implement
 (project constitution) (feature spec) (clarify) (technical plan) (task breakdown) (consistency analysis) (implementation)

The unique "Constitution" stage defines architectural principles, coding standards, and security rules that all development must obey. This ensures consensus in large teams but can be restrictive for agile teams where change is constant.

Practical evaluation : The tool is non‑intrusive—it can be introduced incrementally into existing projects and works with 15+ AI assistants (Claude Code, Copilot, Amazon Q, etc.). An XXL‑API case study showed successful refactoring of a 130‑file medium‑scale codebase. However, the seven‑stage workflow is heavy for small features, documentation is English‑only, and individual developers gain little benefit because the "team consensus" value of a spec disappears when working alone.

Spec‑kit is therefore positioned as a pure Spec‑First solution.

05 | Tessl: the most aggressive vision, deepest dilemma

Tessl, founded by Snyk’s Guy Podjarny, raised $125 M (valuation ≈ $750 M). It offers two components:

Spec Registry (open beta, free): an "npm for knowledge" hosting 10,000+ open‑source library specifications, aiming to eliminate AI‑agent hallucinations and version confusion.

Framework (closed beta, ~9 months, not GA): a CLI + MCP server where specs live in a specs/ directory and are marked with @generate. The build command tessl build generates code files annotated with // GENERATED FROM SPEC - DO NOT EDIT.

Non‑deterministic compiler – core challenge : Birgitta Bockeler (ThoughtWorks) measured that the same spec can produce different implementations across runs. This nondeterminism is intrinsic to LLMs and, for a Spec‑as‑Source paradigm, is fatal because the spec would no longer be a reliable source of truth.

In January 2026 Tessl re‑positioned the Spec Registry as a "Skills Registry" (versioned, evaluated skill packs) while keeping the framework in closed beta. The product shifted from a developer‑centric "Spec‑Centric Development" platform to an "Agent Enablement Platform" targeting CISOs and platform teams. The move acknowledges that the registry has independent value, whereas the non‑deterministic compiler remains unsolved.

Consequently, Tessl’s practical positioning is between Spec‑First and Spec‑Anchored; its Spec‑as‑Source vision remains unrealized.

06 | Direct comparison of the three paths

The three tools differ along several dimensions:

SDD level : Kiro – Spec‑First/Anchored; spec‑kit – Spec‑First; Tessl – aims for Spec‑as‑Source but currently at Spec‑First/Anchored.

Form factor : Kiro – independent IDE; spec‑kit – CLI + IDE plugin; Tessl – CLI + MCP + Registry.

Open source : Kiro – closed; spec‑kit – MIT open; Tessl – Registry open, framework closed.

Pricing : Kiro – $200 / month; spec‑kit – free; Tessl – Registry free, framework not GA.

Suitable projects : Kiro – new 0→1 projects; spec‑kit – 0→1 or incremental adoption; Tessl – currently limited to JS/TS.

Core pain points : Kiro – Vibe/Spec split; spec‑kit – heavy seven‑stage process; Tessl – nondeterministic compiler.

Maturity : Kiro – GA, continuously iterating; spec‑kit – active open‑source community; Tessl – closed beta > 9 months, in transition.

07 | Is SDD a new waterfall?

The community’s sharpest debate compares SDD’s large spec cycles to waterfall’s upfront freeze. ThoughtWorks warns that extensive upfront specifications can lead to waterfall‑style large releases and high change costs. The essential difference is that SDD specs are intended to be alive and updatable, whereas waterfall specs are frozen after sign‑off. In practice, organizational inertia often makes specs rigid once written.

The cognitive load shifts from writing code to writing specs; users report that fixing a single null‑check may require updating a constitutional spec, which can be ten times more effort than a direct code edit. Prezi’s engineering team notes that the main obstacle is not tool unfamiliarity but the steep learning curve, while the dominant barrier is the unfavorable ratio of process overhead to benefit in large‑scale daily development.

08 | When to use SDD and when not

Good fit :

New 0→1 projects for medium‑to‑large teams where spec‑driven consensus adds value.

Projects with vague or frequently changing requirements—specs expose hidden assumptions.

Teams generating large volumes of AI‑written code where specs provide review standards.

Long‑term projects demanding high code quality and maintainability.

Bad fit :

Small, fast‑iteration prototypes—SDD’s upfront cost is prohibitive.

Individual side projects lacking team consensus.

Urgent bug‑fixes where a quick code patch is needed before spec updates.

Teams unwilling to adopt a spec‑culture, risking wasteful "spec for spec’s sake".

Pragmatic advice : Start with Spec‑First; only evolve to Spec‑Anchored after the spec demonstrates tangible value. Spec‑as‑Source remains a vision and should not be relied upon for production systems.

09 | Final thoughts

All three tools confirm that "think clearly before coding" adds value, but the implementation is far more complex than originally imagined. Kiro shows that gate‑controlled workflows improve quality yet feel heavyweight for simple cases; spec‑kit proves that SDD can be free and tool‑agnostic but still suffers from process heaviness; Tessl offers the most radical vision but is stalled by nondeterministic compilation, prompting a shift toward a broader "Skills Registry" strategy.

Guy Podjarny predicts that by the end of 2027 most developers will no longer read code; this hinges on solving the nondeterministic compiler problem. Until then, SDD should be treated as an engineering discipline rather than a revolutionary paradigm.

Extended reading

Birgitta Bockeler’s deep evaluation of the three SDD tools (Martin Fowler site, Oct 2025).

SDD three‑stage academic classification paper (arXiv:2602.00180).

ThoughtWorks technology radar assessment of SDD ("Assess" quadrant).