# Spec Driven Development isn't Waterfall

DevFeed: [Spec Driven Development isn't Waterfall](<https://devfeed.tech/articles/spec-driven-development-isn-t-waterfall-12593.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2026/04/09/waterfall-vs-spec.html>)

Author: Marc Brooker

Published: 2026-04-09T00:00:00Z

Content type: opinion

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Spec Driven Development](<https://devfeed.tech/topics/spec-driven-development.md>), [Agile](<https://devfeed.tech/topics/agile.md>), [Kiro](<https://devfeed.tech/topics/kiro.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>)

Tags: [agile](<https://devfeed.tech/tags/agile.md>), [ai](<https://devfeed.tech/tags/ai.md>), [blog](<https://devfeed.tech/tags/blog.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [spec-driven-development](<https://devfeed.tech/tags/spec-driven-development.md>), [writing](<https://devfeed.tech/tags/writing.md>)

## AI overview

The article argues that spec-driven development is not a return to waterfall development. It presents specifications as explicit, versioned, living artifacts that evolve through user feedback and iterative development, with implementation derived from changing requirements and design choices. In this view, AI can accelerate the iteration cycle without making the process rigid or top-down.

## Source excerpt

Spec Driven Development isn't Waterfall Write down what you mean. After spending a few months writing (e.g. on the Kiro Blog), and speaking (e.g. Real Python Podcast, SE Radio) about spec-driven development, I've noticed a common misconception: spec driven development is a return to a waterfall style of software development. Specification driven development (in Kiro, for example) isn't about pulling designs up-front, it's about pulling designs up. Making specifications explicit, versioned, living artifacts that the implementation of the software flows from, rather than static artifacts. This distinction is important, because software development (like all complex product development and engineering tasks) is a fundamentally iterative process. It is extremely rare for a software project to know all of the requirements up-front. It's much more common for one of the goals of the development process being to discover requirements, most frequently through engaging users in the cycle of feedback. This is a point that's missed in strict waterfall software development processes, and missed in critiques (like Dijkstra's) of natural language specification (as I have written about before). The Agile movement is often presented as a high-minded set of ideas, but I think it's more accurate to see it as a reflection of a simple fact: as software became more complex, and filled more roles in society, top-down approaches to design simply no longer work. From the Agile Manifesto: Customer collaboration over contract negotiation Responding to change over following a plan These are simple reflections of reality. Software specifications are complex, dynamically changing, internally conflicting, and invariably incomplete. In specification driven development, the specification is the thing being iterated on, rather than the implementation. The iteration cycle is the same as before, but potentially much quicker because of the accelerating effect of AI. So if specifications aren't up-front