An assessment of spec-driven development
Spec-driven development (SDD) is the software industry’s first structured answer to coding agents. The idea is to write a specification first and let agents build against it. Tools such as GitHub Spec Kit, AWS Kiro, and Tessl put this idea into practice, and many teams use them today.
What SDD gets right
Three ideas inside SDD hold up well, and aigile builds on all of them. Agents work much better with clear, written, lasting context than with ad hoc chat prompts. Some project knowledge really is foundational, such as architecture rules, domain invariants, and key decisions, and writing it down helps everyone. And breaking work into small, well-described tasks improves both what agents produce and what humans can review.
Where the process shape causes problems
The difficulties come from the workflow that surrounds these ideas. In the common SDD workflow, requirements produce a plan, the plan produces tasks, and the tasks produce code, with each stage treating the previous stage’s output as settled. Teams that have tested this on real projects report a consistent pattern: delivery becomes much slower than iterative work with review (up to ten times slower in some evaluations), the generated documents pile up faster than anyone can read them, and the number of bugs at the end stays about the same.
A concrete example
Consider a team that builds order software for business customers. They ask an agent for a consolidated invoicing feature. The agent produces an eleven-page requirements document, a plan, and forty tasks. The team skims the documents and approves them. Two days later, the demo reveals a problem: the invoices were grouped by shipping address instead of billing entity.
The interesting part is where the mistake lived. It was introduced while the requirements were generated, and every later stage inherited it. By the time the code existed, it was internally consistent and covered by passing tests, so nothing inside the pipeline could flag it. Research on multi-agent pipelines describes the same effect: an early misreading gains coherence and apparent confidence at every stage, which makes it harder to spot rather than easier.
There is also an older lesson underneath. Heavy SDD relies on a bet the industry has made before, namely that a sufficiently clear document can replace shared understanding. Large-scale outsourcing tested that bet over many years, with poor results, and a language model does not change the underlying reason. A document carries text; the reader reconstructs the intent behind it; and checking that reconstruction is exactly the job of a feedback loop.
The same example, with a loop
Under aigile, the same feature starts with a walking skeleton: one invoice, two orders, grouped and rendered, shown to a human within hours. The grouping mistake surfaces at that first small demo and costs one slice of rework instead of forty tasks. The team works with the same care in both versions of the story. What differs is the process shape: the loop surfaces the misunderstanding while it is still cheap, and the pipeline carries it to the end.
The history, stated correctly
Two historical points often get stated wrongly in this debate, and both matter for the method.
First, waterfall was never defined by its sequence. Any construction work involves deciding, doing, and checking, in roughly that order. What defined waterfall was that outputs were frozen: once requirements were approved, they became fixed inputs to design, and anything the team learned afterwards had no accepted way to flow back. The common objection that iterative development is just repeated waterfall misses this point. The reverse observation is more useful: a team that iterates but never lets its findings change the plan is effectively running waterfall, whatever its sprint length.
Second, Royce’s 1970 paper, usually named as the origin of waterfall, presented the famous diagram as a warning rather than a recommendation. His main safeguard was documentation at very large scale, and the character of that documentation matters: it existed to prove that analysis had happened. Nothing executed against it, and nobody’s daily work depended on it being accurate. This is the kind of document the Agile Manifesto pushed back on. Agents introduce a different kind of document, one they read as working input at the start of every session, and its economics work differently. The method builds on this distinction.
Summary
What SDD gets right is content: clear context, foundational knowledge, small tasks. What causes the problems is the missing path for learning to flow back into the specifications. Aigile can be read as a different way to use the same tools, with the same kinds of artifacts arranged in a loop instead of a pipeline. The full argument, with sources, is in Why feedback beats upfront specs.