Spec-Driven Development, Prescribed vs Practiced: What AI Teams Should Change

If your team is deciding whether to adopt spec-driven development around AI coding agents, the first systematic study of the practice points to a narrower answer than the tool vendors do: adopt it selectively, not wholesale, and budget for spec maintenance before you write the first spec. A Carnegie Mellon and Google research team’s new paper, “Spec-Driven Development as Prescribed and as Practiced” (author-reported and unreplicated as of October 2026), found that experienced practitioners already behave this way. They write specs mainly for new features, skip the method for small tasks and bugs, and spend real effort detecting when a spec has drifted away from the code it is supposed to govern.

The practical consequence is a shift in where your review budget goes. When an agent writes the code from a spec, the spec becomes the last artifact a human can review before anything exists to test. A stale or wrong spec does not just sit there; it steers every subsequent agent run that trusts it. So the decision is not “SDD yes or no.” It is which work earns a spec, who reviews it before the agent runs, and how you keep it honest afterward.

What the study actually did

This matters because most of what has been written about spec-driven development is vendor how-to material. The CMU/Google study describes itself as “the first systematic study of SDD as it is practiced”: it combined a thematic analysis of Reddit discussions, interviews with 21 practitioners, and an analysis of 266 active and popular repositories in SpecMine, a corpus of 470,795 spec files, per the paper’s full text, to characterize spec content, workflows, benefits, and challenges.

Two context numbers show why the study exists at all. In SpecMine’s July 2026 snapshot, 99.7% of specs were first committed in 2025 or later and 92% in 2026. The EPIC framework paper, by different authors, cites the same corpus at “more than 70,000 public GitHub repositories,” noting the practice “barely existed before 2025”; the scale figure is relayed, not an independent count. This is a young practice, barely a year into widespread use, which is both the reason to pay attention and the reason to hold the conclusions loosely.

The workflows the researchers observed were consistent in shape. Per Appendix H of the study: “agents drafted specs while participants supplied the intent and reviewed the result, specs were refined iteratively, and code was verified mainly through tests that agents wrote.” Three workflow types emerged, differing by where a human checks the agent’s work. That placement question, where the human checkpoint sits, turns out to be the load-bearing decision for a team lead.

Where practice departs from prescription

The study’s central lens is the gap between what SDD tools prescribe and what practitioners actually do. The largest departure is selectivity. From Finding 2:

Most practitioners used SDD selectively, and only a few used it for every task. They commonly skipped SDD for small tasks, bugs, and one-off scripts: “If you’re using [an SDD framework] for smaller changes, you’re going to have a bad time. It’s too verbose and produces too much overhead and documentation” (R33).

A second study, a 13-respondent trial of an AI-assisted development lifecycle in an applied education setting, points the same direction: four respondents called the process unnecessary overhead, and “the free-text answers locate this criticism specifically in small tasks, where several respondents found the process disproportionate to the change being made” (AI-SDLC paper). That sample is small and the authors themselves note the results concern perceived rather than directly observed behavior, so treat it as corroborating texture, not proof.

The second departure is maintenance. The prescribed story is that specs pay for themselves by preventing rework. The practiced story is blunter: “SDD shifted cost to planning rather than removing it (Finding 9),” and “specs cost effort to write, go stale as code changes, and remain hard to trace to the code that satisfies them,” per the study. Practitioners “relied on custom checks to detect divergence after implementation,” which is another way of saying the tools did not solve drift for them; they built their own gates.

The third departure is social. Practitioners “reported collaboration benefits mainly where a team adopted SDD together” (same source). A solo engineer adopting SDD inside a team that has not is mostly buying the overhead without the coordination payoff.

A decision framework by task size and blast radius

Combining the study’s selective-adoption finding with practitioner heuristics gives a usable triage rule. DataLLM Lab’s guide (a vendor source, advocacy-toned but useful here) states it plainly: “A common triage heuristic: the moment another human touches the code, or it touches money or user data, write the spec first. Below that blast radius, vibe coding is often the rational choice.”

The brownfield row deserves emphasis because most teams are not starting greenfield projects. The OpenSpec walkthrough (a community report, single-source) describes specs in an existing repository as “recovered, one capability at a time,” and insists that “naming those [classes of work to skip] is as much a part of the method as writing a delta.” If your codebase has no specs today, the evidence supports growing them alongside agent-driven changes rather than commissioning a spec-writing project.

What a spec review must check

The argument for reviewing the spec before the agent writes code rests on a documented agent behavior: agents do not reliably ask when information is missing. Per the EPIC paper: “Ask an AI coding agent, and it may fill the gap with its own assumptions and return code that appears to answer the request. Agents struggle to recognize when information is missing, even when asking would improve their solutions.” One interviewed practitioner put it as “making a decision even if I don’t.”

Since agents in the observed workflows drafted the specs themselves, the human review of that draft is the moment to catch silent assumptions. A practical review checklist, synthesized from the evidence:

1. Unstated decisions. Read the spec asking “what did the agent decide that I never said?” Defaults, error behavior, and edge cases are where silent assumptions live.
2. Verifiable acceptance criteria. If the workflow verifies code mainly through agent-written tests, the criteria must be concrete enough that a test can fail against them.
3. Blast-radius fit. Does the spec’s ceremony match the change? The Spec Growth Engine paper, citing Böckeler, notes Kiro can be “disproportionately verbose for small problems (turning a minor bug into sixteen acceptance criteria).” If the spec is longer than the fix, the process is wrong, not the spec.
4. Maintenance plan. Who updates this spec, and when? If the answer is nobody, prefer a throwaway-spec workflow over a persistent one that will rot.

A caution from an adjacent study: an SDPBL classroom trial found agent use “increased implementation throughput” but “tended to encourage students to proceed with development without fully understanding the code,” leading the authors to require regular comprehension checks (SDPBL paper). That is an education setting and may not transfer to industry teams, but the mechanism, throughput masking comprehension, is worth watching wherever junior engineers review agent output.

Maintenance is the real cost

The strongest statement about why maintenance matters comes from the Spec Growth Engine paper:

The agent changes code; nobody updates the specification; the system still passes tests; the divergence is never flagged. Over time, the specification becomes a historical artefact rather than a living contract, and future agent runs are guided by a lie.

That is the second-order effect of adopting SDD around agents: drift is silent because nothing fails. Tests written against the old spec, or by the same agent that made the change, keep passing. The proposed remedy in that paper is a drift gate that makes spec-code divergence a blocking merge error, with spec deltas committed alongside code changes. Whether or not you adopt that architecture, the principle is cheap to copy: spec updates go in the same commit as the code change, or an automated check flags the divergence. The practitioners in the CMU/Google study had already converged on “custom checks to detect divergence after implementation” (Finding 10), which tells you the demand exists even where tools do not supply it.

One more data point on why this cannot be assumed away: the EPIC paper cites a Cursor adoption study in which velocity gains were temporary while increases in static-analysis warnings and code complexity persisted. Agent-generated code left unreviewed appears to accrue the same kinds of debt as any rushed code.

Tool trade-offs are persistence trade-offs

The three developer-adopted leaders, per the study’s per-tool counts: Kiro, 12,497 corpus repositories, 13 in the analyzed sample; Spec Kit, 10,619, 71; OpenSpec, 8,926, 165. The interesting axis is not popularity but what each tool does with the spec after the code lands:

• Kiro is the contested case. The Spec Growth Engine paper, relaying Böckeler’s 2025 account, calls Kiro “squarely spec-first: the specs guide generation but are not maintained afterward – they are deleted once the feature is complete, and a fresh set is created for the next change.” The CMU/Google study reads Kiro’s documentation the other way: “Kiro keeps a living spec for each feature,” and its tool comparison lists Kiro’s prescribed maintenance as “Living spec” (Finding 4, Appendix C). If the throwaway account is right, discarding specs eliminates the maintenance problem by refusing it, at the cost of losing the spec as an ongoing contract.
• Spec Kit follows a Specify → Plan → Tasks → Implement slash-command workflow (EPIC paper) that bolts onto existing agents including Copilot, Claude Code, and Gemini CLI, per DataLLM Lab’s guide.
• OpenSpec keeps archived deltas, which the brownfield walkthrough uses as the persistent record.

My judgment, as an inference from the evidence rather than a measured finding: match the persistence model to your maintenance budget. If nobody will update specs, throwaway specs are honest; a persistent spec nobody updates is worse than none, because agents will trust it. If you want specs as living contracts, you are signing up for same-commit updates or a drift gate, and the observed divergence in how practitioners maintained specs suggests tooling alone will not enforce that for you.

Two caveats on the corpus numbers themselves. Some template types draw more than 95% of their files from a single repository, in two cases the tool vendor’s own, so per-tool results for those types, as the study’s limitations note, “describe how one or two projects apply a template, not a practice observed across many projects.” And Kiro is closed source with unversioned documentation, which limits what repository mining can say about prescribed practice.

What is measured and what is marketing

The one controlled experimental result comes from Google researchers: an agent that first extracts a semi-formal contract (pre- and post-conditions, undefined behaviors) before writing tests “reaches a detection rate of 63.2%, yielding a 9.8% absolute improvement over the baseline agent (53.4%),” per the SpecOps ‘26 workshop paper, on 90 historical production bugs from Google’s issue tracker. That is a real, measured benefit for spec grounding in test generation. It is also one internal dataset of 90 bugs at one company; it does not measure team velocity or defect rates for SDD adoption generally.

Against that, the widely circulated benefit numbers do not hold up. MySpec.dev, itself a vendor in this market, reports: “a widely repeated claim that human-refined specs cut LLM code errors by up to 50% did not hold up under scrutiny. Treat the benefits as qualitative and intended, not as empirically proven gains in defect rate or velocity.” DataLLM Lab similarly traces the several-times-higher first-pass-success claims to vendor and early-adopter reports without verified telemetry. When a vendor’s own blog debunks the headline number, the honest position is that SDD’s team-level productivity benefit is currently unproven, not negative, just unmeasured.

The limits of this evidence, and the verdict

The peg study covers SDD’s first year. In its own words: “Interviews took place in 2026, and the repository histories span less than a year of adoption. Tools, models, and organizational practices changed during the study, so the findings characterize this period” (study scope note). Add the single-repository concentration in some corpus template types, the author-reported and unreplicated status of the findings, and the fact that no source here measures team-level velocity or defect outcomes from adopting versus skipping SDD, and the conclusions should be held as strong directional evidence rather than settled results.

Within those limits, the convergence is hard to ignore. Interviews, repository mining, a small education trial, vendor self-criticism, and one controlled experiment all point the same way: write and review specs for new features and high-blast-radius work, skip them for small tasks, bugs, and throwaway prototypes, and fund maintenance explicitly, through same-commit spec updates or automated drift checks, because a stale spec misleads every agent run that trusts it.

If I were piloting this on a team today, I would start with one workstream that touches money or user data, adopt team-wide rather than letting one enthusiast go solo, run the spec review as a blocking step before the agent writes code, and set up even a crude divergence check in CI from day one. And I would name, in writing, which classes of work skip the method. That naming is not a failure of adoption; per the practitioners doing this in production, it is the method working as practiced.