Development

Spec-Driven Development Can't Spec the Governance That Matters

A 420-KLOC case study challenges spec-driven coding's premise, arguing real governance is discovered from failures mid-project, not written into a spec upfront.

Write the specification first, make it the one document everyone — human and agent — has to answer to, and let the code follow: that’s the pitch spec-driven development has made through 2026. GitHub’s Spec Kit , a CLI that walks a project through “Spec → Plan → Tasks → Implement,” has passed 93,000 stars and supports more than 30 coding agents, alongside AWS’s Kiro, BMAD and Tessl — each betting a clear enough definition of “done” lets an agent build toward it, with vendors citing three-to-tenfold first-pass-correctness gains. A new case study pushes back on that premise. Posted to arXiv on 1 July 2026, Davis, Amusuo, Singla and colleagues followed one expert engineer building a document-accessibility remediation system over 12 weeks with frontier coding agents, logging 88 field notes across 420,000 lines of production code and 1.16 million lines of tests. Its finding: the controls that kept that code inspectable weren’t written down in advance.

Spec-driven development bets the plan is the deliverable

The theory, as Martin Fowler contributor Birgitta Böckeler lays out in her survey of Kiro, Spec Kit and Tessl , is that a spec — precise enough for both a person and an agent to check work against — becomes what Böckeler calls “the source of truth for the human and the AI,” in place of code itself. Tessl puts the aspiration bluntly: “Specs describe intent in structured, testable language, and agents generate code to match them.” When code is this cheap, the spec is what’s scarce; get it right once and every implementation downstream inherits its discipline. Humans decide what “done” means, agents do the typing — division of labor tidy enough to carry a narrow CLI like Spec Kit to tens of thousands of stars in a year.

When code is nearly free to produce, the scarce skill is the judgment that turns a recurring failure into a rule.

The mature version of this argument already expects specs to bend

The fairest response is that spec-driven development was never meant to be static. Böckeler’s own maturity ladder runs from “spec-first,” a one-time kickoff artifact, up through “spec-anchored” and “spec-as-source,” where the spec is a living document revised as failures surface new obligations. A practitioner at that tier could call governance conversion just spec-driven development done properly: find the gap, fold it into the spec, keep going. Böckeler herself hedges the other way too, warning that treating the spec as source of truth “might end up with the downsides of both MDD and LLMs: Inflexibility and non-determinism,” replaying failure patterns from Model-Driven Development. The arXiv authors are candid about their own limits: one engineer, one project, offered as “a candidate middle-range theory,” not a validated finding — no published trial pits spec-first teams against emergent-governance teams. No empirical refutation has surfaced — the case study is simply too new for one to exist.

Governance conversion locates the scarce skill in judgment, not documentation

What the case study adds isn’t a rebuttal so much as a different account of where control comes from. Its central claim: “In contrast to existing governance models that derive controls from known obligations, governance conversion explains how controls are discovered from failures that become visible only during agentic work.” That differs from updating the spec when something breaks: the controls worth having were never derivable from foresight — not from insufficient planning, but from failure modes that only surface once you’re deep into building: an agent quietly reintroducing a bug, a test suite passing while missing the real requirement. That judgment, not the plan, is the scarce resource, which matters for teams expecting a spec to front-load the hard part. The spec captures what you already know to ask for; the governance keeping 420,000 lines of agent-written code maintainable arrives as a byproduct of shipping, not a precondition for it — the same lesson Amazon and Meta learned when their AI-usage leaderboards got gamed into meaninglessness and had to redesign only after the failure showed itself.

Read against a year of tools promising the plan would carry the weight, this is a more modest, sturdier claim: the spec earns its keep for the obligations you can see coming, and the harder discipline — the one code review has been relocating toward rather than abandoning as agents take on more of the typing — is the one no document written before the first line of code could have contained.