SDD and TDD aren't competing methodologies — they answer different questions, and the spec-driven testing post earlier in this series already showed how naturally they combine.

Both tools put a spec between you and the agent. They disagree on where it should live, how rigid it should be, and who owns the workflow around it.

Kiro's EARS-derived requirements notation looks unusual coming from prose-style specs. Walking through why the structure exists and what it buys you over free-form requirement writing.

The constitution-writing advice earlier in this series is easier to apply with concrete examples. Three annotated excerpts showing the difference between a weak line and a strong one.

AWS's Kiro takes a different route to spec-driven development than Spec-Kit — specs, steering files, and hooks built into the IDE itself, using a requirements notation borrowed from aerospace engineering.

Colocating specs with code works cleanly in a single repo. Once a system spans several repos, the same discipline needs a cross-repo strategy or specs drift apart from each other, not just from the code.

The scariest refactors are exactly the ones with no spec to work from — old, load-bearing code with undocumented behavior that everyone's afraid to touch. Spec-driven refactoring makes that fear tractable.

Not every ambiguity is a spec-writing failure. Some requirements are genuinely, irreducibly ambiguous until a specific case is encountered — and the spec needs a way to handle that honestly.

A spec-driven PR review needs a different focus than a standard code review — the spec did some of the checking already, and the reviewer's attention should go where the spec can't reach.

A spec describes what should be built; hooks are what make sure the agent's actual output gets checked against mechanical standards before a human ever looks at it.