Three well-funded, well-adopted tools converged on the same idea within about a year of each other, from three different starting points. GitHub Spec Kit made it free and open source. AWS Kiro made it formal, with EARS-notation requirements built for Bedrock-native teams. Augment Cosmos made it enterprise infrastructure, with SOC 2 and ISO 42001 certification behind a shared-memory engine spanning the whole SDLC. Different companies, different approaches, same underlying conclusion: specs should be living, structured, and persistent — not prose written once and abandoned.
That’s a real signal. When three independent, well-resourced teams arrive at the same architecture from different directions, it usually means the old approach had a genuine, provable failure mode, not just a stylistic weakness.
The failure mode all three are fixing
Before spec-driven development, the typical pattern was: write a spec, hand it to an AI coding agent, get code back that looks plausible but drifts from actual intent over a longer session, then debug the gap by hand. The fix, across all three tools, is the same: keep the spec alive, force the agent to check its own work against it, and don’t let scope silently expand past what was actually decided.
Why this hasn’t reached product teams yet
Here’s the part that should be uncomfortable for anyone running a product org: the exact same failure mode exists on the product side, and almost nobody has fixed it. A PRD gets written once, handed off, and by the time the feature ships, the original reasoning has drifted from what got built — the same drift spec-driven development was invented to prevent, just one layer upstream, with no equivalent fix.
What “living” needs to mean for a product decision
For a product decision, living means the same three things it means for an engineering spec: it stays connected to something that changes (the evidence and the code), it can be checked against reality after the fact, and it doesn’t quietly let scope drift without anyone noticing. None of that requires new invention — it requires applying a discipline that’s already been proven at scale, one level higher in the stack.
The prediction worth making
Spec-driven development didn’t stay a niche practice — it became the default in about a year, spreading through open source, cloud infrastructure, and enterprise platforms simultaneously. Product management is about twelve months behind where engineering was when this started. The teams that adopt a living, evidence-grounded decision layer now — rather than waiting for it to become the obvious default — are the ones who’ll spend less time next year re-litigating decisions nobody wrote down properly the first time.