Spec-Driven Development vs Waterfall: Key Differences

Spec-driven development differs from waterfall in one structural variable: spec mutability during implementation. Waterfall locks specifications through phase gates; SDD treats them as living artifacts updated through implementation feedback loops.

Why the "SDD Is Waterfall" Objection Keeps Surfacing

"It's waterfall in Markdown." This objection surfaces in nearly every discussion about spec-driven development. The reasoning is intuitive: writing a specification before writing code sounds like Big Design Up Front, and BDUF is what made waterfall fail. Engineers who lived through the era of 200-page requirements documents have earned their skepticism.

The objection matters because part of it is true. Spec-driven development practiced badly, with frozen specifications handed off to implementers, does reproduce waterfall's failure modes. ThoughtWorks warns against "heavy up-front specification and big-bang releases" within SDD workflows.

The structural difference comes down to what happens after the spec exists. Waterfall resists changing the spec once implementation begins. Spec-driven development, as described in iterative workflows and in tooling workflows like Intent, assumes implementation will teach the team something, and the spec should change accordingly.

This guide breaks down the three structural differences that separate SDD from waterfall, addresses the Beck-Fowler critique directly, and provides a comparison framework for evaluating where SDD sits relative to both waterfall and traditional agile.

Waterfall Specs Are Frozen Documents; SDD Specs Are Living Artifacts

Waterfall's specification model treats documents as phase-gate artifacts: each phase produces an output that becomes the binding input for the next phase, and the process architecture structurally resists returning to completed phases. Martin Fowler describes this as a "convenient fiction", noting that even eager waterfall proponents acknowledge rework happens, yet the process still enforces freezing by design.

Spec-driven development emphasizes creating specifications up front and using them to guide implementation. The specification is a version-controlled artifact, not a phase output that gets locked after sign-off. Living specs update whenever implementation reveals new information.

Three concrete patterns show what "living" means in practice, each suited to different workflow needs:

1. The AI loop: A developer defines a use case, refines behavior and rules, generates code bounded by the spec, validates results, then updates the spec and repeats if something is unclear or wrong. The spec is an input to a repeating loop, not a locked handoff document. This pattern is most resistant to spec drift because the spec updates on every pass, but it works best for single features where one developer controls the full cycle.
2. The acceptance approach: Before development starts, the spec is frozen as the basis for implementation. During acceptance after implementation, the spec enters an adjustable state where provisional changes are permitted based on what was discovered. If acceptance fails, the spec is revised, code is adjusted, and the acceptance cycle re-runs. This pattern suits teams that need a stable target during implementation but want structured revision afterward, and works well for teams transitioning from waterfall.
3. Collaborative drafting: Addy Osmani, Google Chrome engineering lead, describes a workflow where the spec itself is built iteratively before any code is written, through a dialogue loop with the AI. The spec emerges from conversation rather than arriving fully formed from a prior phase. This pattern front-loads the ambiguity resolution into spec creation rather than distributing it across implementation, which reduces mid-build surprises but requires the developer to anticipate implementation constraints before seeing running code.

These three patterns compose rather than compete. A team might collaboratively draft a spec, implement against it using AI loops on individual functions, and apply acceptance-style review before merging. The choice depends on how much implementation uncertainty exists: high uncertainty favors the AI loop's tight revision cadence; lower uncertainty favors the acceptance approach's stability during build.

A Microsoft Developer Blog post on Spec-Driven Development describes SDD as "version control for your thinking," and Spec Kit materials emphasize making specifications central and iterative rather than traditional upfront exhaustive requirements.

In Intent's workflow, specifications update bidirectionally: when requirements change, updates propagate to all active agents; when an agent completes work, the spec updates to reflect what was actually built. The spec keeps agents aligned without treating the document as fixed.

Waterfall Treats the Spec as the Plan; SDD Treats It as a Feedback Mechanism

The second structural difference concerns what the spec is for. In waterfall, the spec is a governance artifact: conformance is measured against it, and changing it requires a formal process. In SDD, the spec is a dialogue medium: implementation signals flow back into the spec, and revision is the expected response to learning.

The format row in this table carries more weight than it appears. When a spec is a PDF or wiki page, validation against it is manual: a human reads the spec, reads the code, and judges whether they match. When a spec is machine-readable Markdown or YAML consumed by tooling, validation can run automatically on every commit. That difference turns the spec from something the team checks periodically into something the CI pipeline checks continuously. InfoQ's analysis of enterprise SDD describes exactly this bidirectional feedback: when validation agents identify gaps between specifications and implementations, those insights feed back into harness refinement and improve future specifications.

ThoughtWorks reinforces the feedback framing: "SDD is not creating the huge feedback loops of waterfall" but providing shorter and more effective feedback loops than unstructured AI-assisted coding. Teams considering SDD should evaluate whether their spec format actually supports automated validation. A Markdown spec that no tooling reads is functionally equivalent to a Word document in a SharePoint folder.

Waterfall Separates Writers from Implementers; SDD Keeps Developers in Both Roles

Waterfall's role separation is a deliberate design choice. Fowler explains that plan-driven methods engineer processes to be role-agnostic, which requires knowledge to be fully externalized into documents before role handoffs occur. Implementers consume spec artifacts produced by prior roles in prior phases.

Spec-driven development collapses this separation. GitHub and Microsoft's SDD practices make technical decisions explicit and reviewable, but the specifications themselves are generated by coding agents from high-level prompts rather than being necessarily authored by the same engineers who make the technical decisions. Enterprise workflows described in InfoQ's analysis show engineers increasingly defining specifications and validating that generated implementations align with them. Bugs become opportunities to improve both the code and the specification layer.

This role collapse has a practical consequence: spec quality improves because the person writing the spec is also the person who discovers its gaps during implementation. In waterfall, that feedback loop crosses organizational boundaries and phase gates, so spec authors may never learn that their specification was ambiguous until months later. In SDD, the feedback is immediate: a developer writes a spec, watches an agent misinterpret it, and revises the wording within the same session.

The tradeoff is that collapsed roles introduce blind spots that separated roles can catch. A dedicated spec author (a business analyst, a product manager) brings domain knowledge and user perspective that a developer writing their own spec may skip. When the same person writes the spec and implements the code, they tend to specify what they already know how to build rather than what the user actually needs. SDD does not inherently solve this; it requires developers to actively seek external input during spec creation, or to use the collaborative drafting pattern with stakeholders before implementation begins.

Intent's workflow keeps those roles close together while maintaining a structural check. A developer writes the living spec, reviews the Coordinator agent's decomposed plan, and validates Implementor agents' output against the original specification through the Verifier agent. The Verifier functions as an independent reviewer, catching mismatches between the spec's stated intent and the implementation's actual behavior. That removes the handoff delays that define waterfall's phase-gate architecture without eliminating the verification step entirely.

Full Comparison: Waterfall vs. SDD vs. Agile (Minimal Spec)

The operative variable separating these three methodologies is scope and mutability: how much gets specified before implementation, and how easily that specification changes once work begins.

The confusion between SDD and waterfall comes from treating when a spec is written as more important than how it gets used during implementation. A spec written before code that updates hourly based on implementation learning is structurally closer to agile than to waterfall, despite the upfront authoring.

TDD Is SDD at the Unit Level: The Lineage That Disproves the Waterfall Claim

The strongest rebuttal to "SDD is waterfall" comes from SDD's genealogy in test-driven and behavior-driven development. If SDD is waterfall because a specification appears before implementation, then TDD's red-green-refactor cycle is also waterfall: the developer writes a specification (the failing test) before writing the implementation. BDD faces the same accusation with Given-When-Then scenarios. Both TDD and BDD are recognized agile practices.

An arXiv paper by Piskala (submitted to AIWare 2026) states that "Test-Driven Development (TDD) is SDD at the unit level," framing a failing test as a micro-specification that defines expected behavior before implementation. The paper positions BDD as "the most direct ancestor of modern SDD," noting that Gherkin scenarios are executable specifications bridging business requirements and technical implementation. Martin Fowler describes Given-When-Then as "a style of representing tests, or as its advocates would say, specifying a system's behavior using SpecificationByExample."

What SDD inherits from TDD and BDD is the core discipline: define expected behavior before writing implementation, then use the gap between expectation and reality as the primary feedback signal. What SDD adds is scope. TDD specs cover a single function. BDD specs cover user-facing behavior. SDD specs cover features, systems, and architectures, including acceptance criteria, data models, and API contracts. That scope expansion introduces the risk that Beck identified: the larger the spec, the more likely implementation will reveal something the spec got wrong. SDD addresses this through the same mechanism TDD uses (revise the spec when it fails), but the revision cost is higher at system scope than at unit scope, which is why living specs and short feature-level cycles matter.

Gojko Adzic traces the concept through Specification by Example, where examples that are automatically tested keep specifications up-to-date as living documentation. David Evans coined the term "Living Documentation" to describe this. The concept predates the current SDD debate by more than a decade and sits inside established agile practice.

The same paper states that "SDD is not a replacement for existing development practices, it builds on and extends them in the context of AI-assisted development." Intent's living specs fit that layered model: the Verifier agent validates implementations against the spec in the same way a test suite validates code against expected behavior, but at system scope rather than unit scope.

The Beck-Fowler Critique: What It Actually Says

Martin Fowler's 08 Jan 2026 Fragments post references Kent Beck's critique of spec-driven development. The precise wording matters.

Beck wrote: "The descriptions of Spec-Driven development that I have seen emphasize writing the whole specification before implementation. This encodes the (to me bizarre) assumption that you aren't going to learn anything during implementation that would change the specification."

Fowler argued that worthwhile specification depends on learning and understanding during development. He then connected this to Extreme Programming's core values: "When Kent defined Extreme Programming, he made feedback one of its core values. It strikes me that the key to making the full use of AI in software development is how to use it to accelerate the feedback loops."

Two observations clarify what this critique targets:

• Beck objects to writing the whole specification before implementation. Level 2 SDD (spec-anchored approaches where specs are retained and kept synchronized with the codebase as features evolve) treats the spec as a living document throughout implementation and iteration. Beck's critique maps most directly to Level 3 spec-as-source approaches and any workflow that freezes assumptions.
• Birgitta Böckeler's analysis on martinfowler.com critiques the end of the SDD spectrum with the weakest feedback loops. Her companion article examines three SDD implementation levels: spec-first, spec-anchored, and spec-as-source. The sharpest critique is directed at the spec-as-source end, where humans never touch code. Fowler's emphasis on accelerating feedback loops rather than eliminating specs aligns with the iterative model described throughout this article: write a spec, implement against it, learn from implementation, update the spec.

The ThoughtWorks Technology Radar confirms part of that nuanced position: the organization placed SDD in Assess, not Hold. SDD is treated as a distinct emerging practice with an embedded antipattern risk, not as an antipattern by definition.

Where the Objection Has a Valid Point

Intellectual honesty requires acknowledging where critics are right, and several of the structural risks in SDD are real enough to deserve more than a dismissive paragraph.

Spec drift is a real failure mode, and SDD's design makes it easier to trigger. One practitioner account argues that specifications and code diverge without active maintenance discipline. Gojko Adzic made a similar point about BDD's living documentation promise: it breaks down when teams stop treating specifications as a maintained single source of truth. In waterfall, specs drift because nobody updates them. In SDD, specs drift because everyone can update them, but nobody takes responsibility for reconciling concurrent changes. The editability that makes SDD flexible also makes it fragile without clear ownership conventions: who reviews spec changes, when do conflicting updates get resolved, and what happens when an agent updates the spec with something the developer disagrees with?

Overhead cost scales with task size, and small tasks suffer most. Some critics argue that spec-driven development adds friction compared to iterative prompting in practice. The overhead question is not binary. Writing a spec for a two-hour bug fix likely costs more time than it saves: the developer already understands the problem, the fix is localized, and the spec becomes documentation of something already completed.

Writing a spec for a two-week feature that spans multiple services is a different calculation: the upfront cost amortizes across every implementation decision, and the spec prevents the kind of mid-build ambiguity that causes rework. Teams adopting SDD should establish a complexity threshold below which direct implementation makes more sense than spec-first workflows.

Spec-as-crutch replaces understanding with documentation. This failure mode receives less attention but is structurally dangerous. When a developer reads a spec's description of a service boundary and trusts it without verifying the implementation, they are making the same mistake that waterfall made: treating a document as a reliable proxy for reality. The risk compounds in AI-assisted workflows, where agents generate specs from codebase analysis that may be accurate on average but wrong in specific cases. A developer who defers to the spec's description of an API contract instead of reading the actual endpoint code can ship integration bugs that the spec structurally cannot catch. SDD mitigates this through verification agents and automated testing, but those mechanisms only catch the gaps they are configured to test.

Teams that treat specs as frozen plans will recreate waterfall. The ThoughtWorks Radar explicitly flags this risk: SDD practiced without iterative updates reproduces the failure mode Kent Beck identified, the assumption that implementation will teach the team nothing that changes the specification. The methodology is structurally different from waterfall; whether a team's practice is different depends on whether the team actually updates specs during implementation.

Within Intent's workflow, bidirectional spec updates address spec drift directly: as agents complete work, the spec updates to reflect what was built, and when requirements change, updates propagate to active agents. That reduces, but does not eliminate, the maintenance discipline required to keep specs alive. The gap between vibe coding and SDD often sits exactly here: whether the team imposes enough structure to keep specs current without imposing so much that iteration stalls.

Run One Feature Through SDD Before Debating Labels

The practical next step is to run one small feature through an SDD workflow and inspect the mechanics: whether the spec changed, whether validation happened inside the cycle, and whether implementation feedback improved the spec instead of bypassing it. That test exposes the real tradeoff between frozen planning and iterative learning faster than another methodology debate.

Intent implements that model directly: the Coordinator agent drafts and decomposes a living spec, Implementor agents execute in parallel, the Verifier agent checks results against the spec, and the spec updates as work completes.

FAQ

Related

• Spec-Driven Development & AI Agents Explained
• Living Specs vs Static Specs
• How to Write Living Specs for AI Agent Development
• Vibe Coding vs Spec-Driven Development: When to Use Each
• 8 Best AI Coding Assistants