Spec-driven development uses upfront documentation to drive implementation. That looks, on the surface, like Waterfall. It isn’t. The difference comes down to four behaviors, which are observable, not philosophical.
The Short Answer
Waterfall treats documents as gates: write, approve, freeze, hand off, build against. Spec-driven development treats documents as a working tool: written and rewritten alongside the code, never frozen, owned by the people doing the work. The artifacts can look identical. The behavior around them is not.
Why They Look Alike but Behave Differently
Waterfall was designed in 1970 for a world where the implementation bottleneck was human developer time, handoffs between specialized teams were expensive, and changing a document late in the cycle meant rework that could blow up a project. Freezing the spec was a rational response to those constraints.
Spec-driven development was designed for a world where AI does much of the implementation, change is cheap, and the bottleneck has shifted to clarity of intent. Same artifact, a written spec. Different process. Practices that would have been reckless in 1970, rewriting the spec at 2 PM and shipping by 4 PM, are now the default.
The terminology is starting to catch up. Some teams (ours included) have started using Agentic Delivery Process, a broader label that names the full shift, not just the artifact. Spec Driven Development describes what changed about the documents. But Agentic Delivery Process describes what changed about everything around them, and specs are central to that.
4 Behaviors that Distinguish Them
1. When the spec changes
Waterfall: specs change at defined milestones, with formal approval. Mid-cycle changes trigger change-control processes.
Spec Driven Development: specs change the same day, often the same hour, as new information arrives. A product owner meeting wraps at 11. By end of day, the transcript is processed and the spec commits in alongside code.
If your specs only change at sprint boundaries, you’re doing waterfall. Also, if your sprints last more than a few days, you may be doing waterfall, but let’s chat about that in a different blog post.
2. How design and specs relate
Waterfall: design follows requirements. The requirements doc is upstream; design is downstream.
Spec Driven Development: design and specs evolve in parallel, each reshaping the other. The prototype reflects conversations the spec hasn’t formalized yet. Specs formalize what the prototype implies, the why, the edge cases, and the behavior a prototype can’t communicate.
3. How “done” is defined
Waterfall: a separate sign-off step reconciles the build against the original requirements doc.
Spec Driven Development: the Must/Should/May requirements inside the spec are the acceptance criteria. When they’re met, the feature is done. There’s no separate doc to reconcile, no ambiguity about what was agreed to.
Approval lives inside the document, which can be changed or added to at any time. It is not a gate around it.
4. Who edits the spec
Waterfall: requirements flow downhill, from analysts to developers. Developers consume the spec; they don’t change it.
Spec Driven Development: the developer who hits an ambiguity at 2 PM updates the spec at 2:05 PM. Spec edits commit alongside code.
The spec is a working tool, not a contract.
How to Apply This
To tell whether a team is doing waterfall with a new label or genuinely practicing spec-driven development, check for these signals:
- Spec commits in the last seven days, authored by developers. The single most diagnostic signal. If specs only get edited by analysts, PMs, or delivery leads, the spec is being treated as a deliverable, not a working tool.
- Acceptance criteria that live in the spec, not in a separate ticketing system. If the team is reconciling Jira tickets against a spec, there are two sources of truth — and that’s waterfall, even if everyone calls it something else.
- No “requirements approved” gate before code starts. If a stakeholder needs to sign off before any code is written, the team is operating under waterfall constraints regardless of what the practice is called.
- Specs and code committed in the same pull request. The operational test. If a feature change requires the spec to update too, both should land together. If specs lag code, the spec is documentation, not source of truth.
- A process for catching stale specs. Spec rot is the leading indicator that the practice is failing. Teams that catch it actively (diff reviews and spec health checks) are practicing Agentic Delivery Process. Teams that don’t will end up with a wall of stale documents and quietly revert to verbal agreements.
Where to Start
The smallest move into Agentic Delivery isn’t a process change; it’s a single commit. Pick one feature on the current backlog, write its spec in the repo as a Markdown file, and commit it alongside the next code change to that feature. Then watch what happens to the next change after that. If it touches both files, the practice is taking hold. If the spec goes untouched while the code keeps moving, the team is treating the spec as documentation, and the practice will not stick without a deliberate intervention.
The structure looks similar to Waterfall because the artifact looks similar. The behavior is what tells you which one you’re actually doing.