Cedric Clyburn, speaking on IBM Technology, compares waterfall requirements with a short spec that evolves as a coding agent builds and a human validates the result.
The distinction is feedback
- A waterfall process finishes requirements, design, build and test in sequence. A frozen spec handed to an agent can reproduce that failure mode, only faster.
- Clyburn’s loop is spec → agent implementation → human validation → revised spec. He proposes hours or days for a feature, not months for a whole project.
- In his example, a password-reset spec says to email a single-use link that expires after 15 minutes. During testing, the team discovers it forgot to say what happens when a user requests two links; it adds “only the latest link works.”
Keep the decision near the code
- Version-control the spec alongside implementation and use it to guide both tests and review. A failing test can be a tiny executable spec for one behavior.
- Include constraints an agent might otherwise guess: existing architecture, acceptance criteria, authentication, logging rules and secret handling.
- The agent can draft revisions, but someone must check that the document still describes what shipped. Keeping it in a repository does not automatically prevent spec drift.
- Caveat: this is an explanatory workflow, not a measured comparison showing fewer prompts or lower cost. Clyburn also says a small bug fix need not have its own spec.
“If you write the entire spec up front and you freeze it and hand it off to an agent, yes, it is waterfall.” — Cedric Clyburn