Formal requirements specs — the IEEE 830 / ISO 29148 lineage a generation of Agile culture learned to skip — are re-entering practice, and the reason is structural, not nostalgic. A coding agent is a non-deterministic contractor, and a spec is the contract. With human developers, an unstated assumption got resolved once, in conversation, and stuck. With an agent, every regeneration re-rolls the dice on every piece of intent you never wrote down — the cost of unwritten intent went from one-time to recurring. And the half most write-ups skip: the spec only becomes a contract when there's a verification loop to enforce it.
Spec-driven development (SDD) puts a formal, machine-readable specification — written before implementation — at the centre of the workflow as the single source of truth. Code is generated and maintained against the spec; when intent changes, the spec changes first. The idea is old: its roots run through 1960s NASA workflows, Hoare's logic, Dijkstra's formal methods, and Meyer's design-by-contract, with an academic formalisation in 2004.
The standards lineage matters because it maps so cleanly onto the present. IEEE 830 defined the software requirements specification; it was superseded by ISO/IEC/IEEE 29148 in 2011 (current revision 2018). A BRS captures stakeholder intent — the why. An SRS pins down system behaviour an engineer can implement against — the what. Those two documents map almost exactly onto the two artifacts every serious agentic workflow now regenerates: intent capture and constrained task decomposition. What's returned is not the IEEE document itself — nobody is writing an 830-style SRS again — but its function, in new forms: markdown specs, constitution files, eval suites. The standard didn't go away. It waited for a consumer that couldn't infer intent from a hallway conversation.
The best evidence that something is off in unstructured AI-assisted work isn't a benchmark — it's a perception gap, measured under controlled conditions.
Sixteen experienced developers, 246 real tasks from repos they knew deeply. Allowed AI tools, they took 19% longer (METR RCT, July 2025 — early-2025 tools; METR labels the result historical, and a February 2026 follow-up showed some speedup).
The same developers predicted AI would speed them up by 24% before starting.
Even after finishing slower, they estimated they'd been about 20% faster. The clock and the feeling pointed in opposite directions.
Be precise about what that study proves and what it doesn't. It proves the perception gap is real — unstructured AI-assisted work feels faster than it is. It did not test spec-vs-no-spec, and METR attributed the slowdown to several factors, only some of which a spec addresses. The spec is the candidate fix, not the proven one — and the mechanism behind the candidacy is specific to how LLMs generate code. The same prompt produces functionally different output across invocations, so any gap in your intent resurfaces unpredictably every time the agent regenerates. A human resolves ambiguity once and remembers; an agent makes you pay for the same unwritten assumption on every run. Externalising intent into an artifact is the move that changes that cost curve.
This is also where the harness model earns its keep. CLAUDE.md, AGENTS.md, and a SKILL file tell the agent how to build; the spec tells it what. Skip the second and you're vibe coding with extra steps. The operator's real leverage isn't prompting faster — it's specifying tighter.
GitHub Spec Kit (September 2025, MIT-licensed) is the reference implementation. The specify CLI bootstraps a project, and the workflow is a command chain where each phase produces artifacts the next consumes: /speckit.constitution (the non-negotiables) → /speckit.specify (intent) → /speckit.clarify → /speckit.plan (the tech decisions) → /speckit.tasks → /speckit.analyze (consistency) → /speckit.implement. It runs across 30+ agents including Claude Code, Copilot, Cursor, Gemini CLI, Windsurf, and Codex. The constitution file strand — versioned, non-negotiable constraints mapped to the CWE/MITRE Top 25, sitting above every generation — has one arXiv case study ("constitutional" SDD, Marri, February 2026) reporting a 73% reduction in security vulnerabilities and 56% faster time to first secure build. Single case study; weight accordingly. The direction, corroborated by IBM, Microsoft, and Thoughtworks publishing on the same pattern, is the signal.
Spec Kit the method demonstration and Spec Kit the dependency are different bets. Eleven months after launch it is still on a 0.x version line (0.14.x as of late July 2026), moving fast enough that v0.10 removed the --ai flag family outright — tutorials written before June 2026 show commands that no longer work — and "is this actually maintained?" is a live thread on its own discussion board. Practitioner reviews are genuinely split: reports of a heavy ceremony cost ("a sea of markdown documents", a single plan phase generating 2,000+ lines), materially higher token consumption on the full pipeline, and at least one published review finding plain iterative prompting faster for their work.
The sharpest criticism — from Spec Kit's own community — is also the most instructive: the documents govern the code by convention, not enforcement. That is this leaf's verification point, made concrete by the flagship tool's critics. The honest posture: adopt the workflow shape (constitution → spec → plan → tasks → implement), treat the tool itself as a 0.x dependency you pin and expect to churn, and wire your own enforcement — tests generated from the spec, CI gates — regardless of which toolkit produced the markdown.
The part most SDD write-ups undersell: a spec an agent cannot be checked against is just a longer prompt. The contract is really two artifacts — the spec, and the verification loop that enforces it: acceptance tests generated from the spec, eval suites, CI gates, and constraint files the pipeline actually runs. That loop is what converts "I wrote down what I wanted" into "the agent provably built what I specified" — and it's what makes regeneration safe, because a re-rolled implementation that still passes the spec's checks is a non-event. Write the spec; then write (or generate) the checks that make it binding.
The spec is not a productivity hack, and over-specification is the named antipattern — Thoughtworks put SDD on the Technology Radar and flagged the failure mode in the same breath: a bias toward heavy up-front specification and big-bang releases. Over-specify a throwaway prototype and you've built a cathedral to house a shed.
For anyone building under POPIA or GDPR, this stops being a style preference. Compliance reviews increasingly treat the specification as evidence: if an agent generated the code, the spec is the audit trail for what it was instructed to do and which constraints it was held to — the difference between "the model wrote it" and a defensible record of intent, constraint, and validation. In a regulated Johannesburg fintech, that record is the thing that survives a review. Keep the spec and its checks in the repo, run the agent on in-country infrastructure, and the governance story and the residency story become the same story.
The economics land locally too. The code was never the scarce thing — any agent can produce a thousand lines. What's scarce is a precise, verifiable statement of what those lines are supposed to do. For an SA team, that scarcity is good news: the durable, billable skill in agent-era delivery is exactly the one that doesn't depend on owning the biggest model — specifying tightly, and verifying what comes back.
The RCT, the standard, the toolkit, and the case study — with the caveats carried inline where they belong. Last reviewed 2026-07-28.