Scout: The Drift-Control School — What the 2026 Spec-Driven Development Papers Actually Establish

Summary

Between January and late June 2026, five arXiv preprints converged on the same problem from five directions: how do you keep a specification and a codebase from silently diverging when an agent is writing most of the code? They propose a rigor ladder, a hook-instrumented multi-agent pipeline, per-line requirement citations, a blocking merge gate driven by static analysis, and a self-evolving loop policed by a regression oracle. Read side by side they look like a school. Read as a literature they are not one yet — none of the five cites any of the others, and the vocabulary they do share traces back to a Thoughtworks blog post published in October 2025. The evidence is thinner than the framing suggests: one paper reports no evaluation at all, one reports a quality gain its own blinded human raters did not prefer, and the set’s largest production claim is explicitly scoped to what its own test oracle can see. What is genuinely worth taking is the enforcement machinery — four cheap, mechanically distinct ways to make drift fail loudly — which can be lifted piecemeal without adopting any of the frameworks that wrap them.

Key Findings

Five papers, one problem, zero cross-citations

The corpus, in submission order:

Paper	Author(s)	arXiv	Submitted
Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants	Deepak Babu Piskala	2602.00180	30 Jan 2026
The Kitchen Loop: User-Spec-Driven Development for a Self-Evolving Codebase	Yannick Roy	2603.25697	26 Mar 2026
Spec Kit Agents: Context-Grounded Agentic Workflows	Pardis Taghavi, Santosh Bhavani	2604.05278	7 Apr 2026
The Spec Growth Engine: Spec-Anchored, Code-Coupled, Drift-Enforced Architecture	Hartwig Grabowski	2606.27045	25 Jun 2026
Citation Discipline in Spec-Driven Development	Subham Panda	2606.30689	28 Jun 2026

How these five were selected. arXiv cs.SE preprints submitted between 1 January and 30 June 2026, surfaced by searching spec-driven development, specification drift, spec-code divergence and traceability — and then narrowed by one rule: the paper’s primary contribution must be a mechanism for detecting or preventing spec↔code divergence. That rule is what makes the set a “drift-control school” rather than an SDD reading list, and it excludes in-window SDD work of other kinds. Two such papers are worth naming so the boundary is visible rather than implied:

Constitutional Spec-Driven Development (arXiv:2602.02584, 31 Jan 2026) embeds CWE-derived security constraints into the specification layer so generated code is secure by construction. It is squarely SDD and in-window, but its mechanism enforces a property at generation time rather than detecting divergence between spec and code over time. Its evidence is also a single author-run banking case.
One Developer Is All You Need (arXiv:2605.18461, 18 May 2026) reports a staff engineer plus four agents delivering a brownfield initiative under an SDD workflow. It is evidence about SDD’s organizational effect, not a drift mechanism — but it bears directly on the brownfield question below, and is cited there.

Stating the rule matters more than the two papers do. Without it, the set looks hand-picked and every additional in-window SDD paper reads as an omission; with it, the claims below are scoped to a reproducible corpus and can be checked by rerunning the same search.

All five are cs.SE preprints. All are single- or two-author. And the structural fact that matters most for how you read them: they do not cite each other. Grabowski’s twenty-nine-item bibliography names GitHub Spec Kit, Tessl, and AWS Kiro as tools, and Böckeler as the framing, but no arXiv SDD paper (arXiv:2606.27045). Panda’s twenty-three references cover requirements traceability, LLM hallucination, and code-generation evaluation, and name only traceSDD, Spec Kit, and OpenSpec as frameworks — no prior academic SDD framework work (arXiv:2606.30689). Taghavi and Bhavani’s references end at 2025 (arXiv:2604.05278).

Within these five, that is a convergent cluster rather than a conversation: none of them replicates or argues with another, and they share no benchmark. The qualifier matters, because the wider 2026 literature is further along than the five suggest. From Prompt to Process (arXiv:2606.04967, submitted June 3, inside this window) cites both Piskala and Taghavi and Bhavani and compares six operational frameworks — Spec Kit, OpenSpec, BMAD, GSD, Spec Kitty, and Reversa — against a six-dimension process taxonomy. Cross-citation and systematic comparison exist; they just do not run through the five papers selected here. Four of the five define drift or context failure in their own words, and no two definitions are quite the same object: Grabowski’s silent spec-code drift is a static-analysis divergence between two graphs, Taghavi and Bhavani’s context blindness is an artifact that is internally coherent but incompatible with the repository, and Roy’s Drift Control is a time-series quality-degradation signal that has nothing to do with a spec document at all. Treat each paper as an independent design proposal with an argument attached, and be skeptical of any framing — including the one implied by reading them in a batch — that presents them as cumulative.

The shared vocabulary is practitioner-sourced

The three-rung ladder every SDD discussion now runs on — spec-first, spec-anchored, spec-as-source — came from Birgitta Böckeler’s October 2025 piece on Kiro, spec-kit, and Tessl, where the definitions are: spec-first, “A well thought-out spec is written first, and then used in the AI-assisted development workflow for the task at hand”; spec-anchored, “The spec is kept even after the task is complete, to continue using it for evolution and maintenance of the respective feature”; spec-as-source, “The spec is the main source file over time, and only the spec is edited by the human, the human never touches the code.”

Piskala’s paper reproduces the same three levels with near-identical semantics — spec-anchored is the specification “maintained alongside the code throughout the system’s lifecycle”, spec-as-source is the specification as “the only artifact humans edit directly” (arXiv:2602.00180). Grabowski goes further and builds a comparison table that positions his framework against Spec Kit, Kiro, and Tessl on Böckeler’s spec-first → spec-anchored → spec-as-source axis, naming her as the source of the axis (arXiv:2606.27045).

So the field’s one piece of settled terminology entered through a practitioner blog and was adopted by the papers, not the reverse. If you are trying to decide whether to track this literature, that is the tell: the academic side is currently downstream of practitioner vocabulary, and the papers are contributing mechanisms rather than concepts. Adjust your reading budget accordingly — skim the framing sections, read the mechanism sections.

The enforcement machinery is the part worth stealing

Strip the methodology wrappers and four mechanically distinct drift detectors remain. Each is cheap, each is independent of the framework it ships inside, and each catches a different failure.

A blocking merge gate driven by two graphs. Grabowski’s drift gate compares an Intent Graph derived from the repository’s SPEC.md files against an Evidence Graph derived from static code analysis. Four conditions are hard errors that block the merge unconditionally: orphan code, undeclared cross-boundary dependencies, code reaching into another node’s internals, and missing public contracts. A softer tier warns without blocking — declared dependencies with no code evidence, public exports the contract never mentions, spec behaviors with no test evidence. The invariant is that spec and code “may never diverge silently”: the agent emits a spec delta in the same commit, and review authority scales to blast radius rather than to whether a contract is involved (arXiv:2606.27045). A HARD gate demands pre-merge approval for root invariants, breaking contract changes, and new container boundaries; a SOFT gate lets additive changes — including additive contract changes — proceed with human review requested asynchronously; an AUTO gate passes internal design changes through untouched. The distinction matters for anyone mapping this onto an existing change-management policy: a contract can be extended without waiting for a human.

A one-grep hallucination check. Panda’s traceSDD requires “mandatory inline citation annotations (# [REQ-XXX.Y.Z]) on every non-trivial line of generated code.” Detection is a set operation: extract every REQ ID cited in the code, subtract the valid IDs from the spec, flag the orphans. The paper describes it as running “in O(1) per file (a single grep)” with zero manual effort (arXiv:2606.30689) — that complexity claim is the paper’s, and it is loose: one command is not constant time, since grep still scans bytes proportional to file size. Read it as a single cheap pass, not an O(1) operation. Any requirement ID the model invented is now a grep hit.

Read-only probes before each phase, validators after. Spec Kit Agents wraps each stage of the Specify → Plan → Tasks → Implement pipeline with two hooks. Before the phase, a read-only prober gathers repository evidence using globbing, grep, and git history. After it, a validator checks the artifact for internal consistency and repository compatibility (arXiv:2604.05278). The design point is least-privilege: the grounding step can read but not write.

A regression oracle with graduated pause gates. Roy’s Drift Control watches a small set of time-series metrics — oracle pass rate, test pass rate, bug discovery rate, canary escape rate, blocked feature combinations — and five gates respond to them, but only one of the five actually stops the loop. Regression failure pauses it, and only after N consecutive failures (default three). Backpressure enters a polish-only drain mode and starvation enters monitor-only mode; both are fully automatic and neither halts. Drift thresholds and Tier-1 canary escapes only warn the operator — the paper is explicit that “drift and canary escape currently warn rather than pause” (arXiv:2603.25697). Read the mechanism as one conditional halt plus four graduated signals, not five stop buttons.

None of these requires buying the surrounding methodology. A team already running spec-anchored workflows can add the orphan-REQ grep in an afternoon and the dependency-boundary gate in a sprint.

The measured effects are small, and one of them points the other way

Spec Kit Agents runs the set’s only repository-level controlled evaluation of its own intervention, and its numbers deserve a careful read. Across 128 runs covering 32 features in five repositories (FastAPI, Airflow, Dexter, Plausible Analytics, Strapi), context-grounding hooks improved judged quality by “+0.15 on a 1-5 composite LLM-as-judge score (+3.0 percent of the full score; Wilcoxon signed-rank, p < 0.05)” while holding 99.7–100% repository-level test compatibility (arXiv:2604.05278) — a move from 3.51 to 3.66 on the composite (arXiv:2604.05278 full text). On SWE-bench Lite the hooks took Pass@1 from 56.5% to 58.2%, which the abstract reports as a 1.7 percent improvement over baseline (arXiv:2604.05278).

Then there is the blinded human preference study. It collected 60 votes across six paired pull-request tasks — not 60 independent evaluations — with raters preferring the un-augmented full workflow 19 times, tying 33 times, and preferring the augmented version 8 times (arXiv:2604.05278). Six tasks is the experimental unit that matters, and votes within a task are not independent of each other. The LLM judge liked the hooks; the humans, on this sample, leaned the other way. The paper reports the sample as a subset of outputs and flags the size as a limitation, so this is not a refutation — but a team evaluating this pattern should note that the headline metric and the human metric disagree in sign, and that a +0.15 shift on a 1-to-5 composite is the kind of effect that lives or dies on judge calibration.

The ablation is more informative than the headline. Discovery-only hooks bought +0.57%, validation-only +1.71%, and both together +4.27% (arXiv:2604.05278). The post-phase validators do roughly three times the work of the pre-phase probes, and the combination exceeds the sum of the parts — a superadditive result the paper reports without proposing a mechanism. If you are going to implement one half of this, implement the validators.

The costs are real and stated. Latency rose 1.1 minutes in the 40-minute budget family and 13.2 minutes in the 90-minute family (arXiv:2604.05278). Every experiment used MiniMax-M2.5 as the base model, and the authors are explicit that gains are uneven across SWE-bench repository families — less reliable on repositories such as django and matplotlib “where many failures originate in deeper application/library logic” (arXiv:2604.05278). Grounding hooks help with repository-shaped ignorance. They do not help with domain-shaped difficulty.

Traceability costs determinism — the corpus’s one clean trade-off

Panda’s study is the one paper here with two models, four conditions, and reported effect sizes with p-values attached — and it produces the finding most likely to survive replication: per-line requirement citations buy automated hallucination detection at a measurable cost in output consistency.

The design is two studies, four conditions, 840 implementations total — Claude Sonnet 4.6 (N=20 tasks, 240 implementations) and GLM-5-turbo (N=50 tasks, 600 implementations) — comparing traceSDD with citations, traceSDD with an identical spec minus the annotations, Spec Kit’s prose user stories and acceptance criteria, and OpenSpec’s external trace YAML (arXiv:2606.30689).

The results:

Detection is binary across frameworks. Only the cited condition enables automated hallucination detection at all — 0% for every alternative, at a 0% false-positive rate (arXiv:2606.30689). The presence/absence result is the robust finding; the headline rates it reports for the cited condition — 86.4% on Claude, 88.0% on GLM — should be read with care, because the same table records 100% detection for each of the three injected hallucination types individually. An aggregate below every one of its components cannot be reconciled without denominators the paper does not give, so treat the binary result as established and the specific percentages as unsettled.
Citations cost lexical consistency. Against the identical uncited spec, the cited condition scores lower on lexical similarity across independent sessions: d = −0.76 (p = 0.003) on Claude, d = −0.72 (p < 0.001) on GLM. Note that the paper is internally inconsistent on the Claude figures — the abstract gives d = −0.76, p = 0.003, while Table 2 gives d = −0.73, p = 0.004. The direction and rough magnitude hold either way; the exact values should not be quoted without resolving which the authors intend.
But traceSDD still beats Spec Kit on the same axis. d = 0.47 (p = 0.049) on Claude and d = 0.42 (p = 0.003) on GLM, while being statistically indistinguishable from OpenSpec (d = 0.18, p = 0.44; d = 0.14, p = 0.32). The structured REQ decomposition helps determinism; the inline annotations give some of it back.
Nothing breaks. All conditions achieved a 100% true-positive rate on functional correctness (arXiv:2606.30689) — citation discipline did not degrade whether the code worked.
The tax is regressive. The determinism penalty is strongest on easy tasks (d = −1.85) and small tasks (d = −0.95), and not statistically significant on hard tasks (d = −0.34, p = 0.22).

That last point is the actionable one, and it inverts the intuition. The citation overhead is cheapest exactly where you most want an audit trail — on the large, hard changes. Applying per-line REQ citations to every trivial helper function pays the full determinism cost for the least benefit. A tiered policy — mandatory citations above a change-size or risk threshold, optional below it — is directly supported by the subgroup data.

The caveats are stated and they matter. Hallucinations were injected as fake REQ-099 identifiers, so the 86–88% detection rate measures a synthetic failure the mechanism is well-suited to catch; organic hallucinations that reuse valid REQ IDs incorrectly would bypass the grep entirely. Tasks were Python, 50–1,000 lines. Two models. The similarity metric is lexical, not behavioral — two implementations can be semantically identical and score as divergent. And the Claude arm is underpowered at N=20 for some comparisons (arXiv:2606.30689).

The two most ambitious claims carry the least evidence

The Spec Growth Engine has no evaluation. Grabowski’s paper is design work: a spec graph at four C4 levels with orthogonal contract and design views, a Spine context assembler that deterministically delivers root invariants plus the ownership path plus the current node’s spec plus one-hop declared dependencies (deliberately excluding siblings, dependency internals, transitive dependencies, and ad-hoc search results), a hardest-first vertical-slice growth protocol, the drift gate, and the blast-radius governance model. It is demonstrated on a worked checkout-system example. There are no benchmarks, no deployment data, and no comparison against an unenforced baseline (arXiv:2606.27045). The design reasoning is careful and the positioning is honest — the paper deliberately refuses the spec-as-source line, stating “we keep code as primary and treat the spec as a verified contract – never as the generative source” — but a blocking merge gate is precisely the kind of intervention whose cost only shows up in practice, in the form of false-positive blocks that teams route around. Nothing here tells you what that rate is.

The Kitchen Loop’s headline number is scoped by its own authors. Roy reports 285+ iterations producing 1,094+ merged pull requests with zero regressions, across two production systems: a DeFi strategy framework (122+ iterations, 728+ PRs) and a signal intelligence platform (163 iterations, 366 PRs) (arXiv:2603.25697). Section 6.1 does the thing more papers should do and defines the claim so it can be falsified: it covers regressions detected by the oracle, and “does not claim the codebase is bug-free, nor that latent regressions undetectable by the oracle do not exist.”

Read that way, “zero regressions” is a statement about oracle recall as much as about code quality. The oracle’s coverage is stated — 10,913 unit tests and 62 demo strategies for the SDK; 77 signal types across 22 verifier families, and 2,171 tests across 152 test files, for the second system — which is a substantial suite, and also a bounded one. The paper’s own scope conditions say the framework only applies where the specification surface is enumerable and testable and where a regression oracle can ground-truth verify outcomes; it explicitly excludes domains where that oracle cannot exist (arXiv:2603.25697).

There is a second thing to notice, and the paper is admirably direct about it. The loop “auto-merges PRs after multi-model review and CI,” and “no human is in the critical path during normal operation” — the human role reduces to initial specification-surface definition, occasional strategic steering, and supervisory intervention when the loop hits failure modes it cannot self-correct (arXiv:2603.25697). So the 1,094 merges were not human-approved by design, and the multi-model review tribunals and adversarial UAT gate are what stand in for that review. This is not an evidentiary gap; it is a stated governance position. The question it hands you is not did a human sign off but does mechanical adversarial verification satisfy your change-management policy in place of a human signature — a harder question, and one to answer before a pilot rather than after.

Where the corpus and the practitioner tooling actually meet

Piskala’s paper is the least mechanistic of the five and the most directly usable as a decision aid, because it is explicit about when SDD is the wrong call. Its guidance: “Use the minimum level of specification rigor that removes ambiguity for your context. Spec-first for AI-assisted initial development; spec-anchored for long-lived production systems; spec-as-source only when generation tooling is mature and trusted.” It names four anti-patterns — throwaway prototypes, solo short-lived projects, exploratory coding where premature specs constrain learning, and simple CRUD with unambiguous requirements (arXiv:2602.00180).

Its case-study evidence is weaker than its framing. The financial-microservices case reports that “Teams reported a 75% reduction in cycle time for API changes” — self-reported, from one organization, with no methodology attached. Read it as an anecdote, not a benchmark. The paper is listed as eight pages, submitted to AIWare 2026 (arXiv:2602.00180), which is the appropriate weight class for a positioning-and-guidance contribution.

The tooling side has not moved as far as the paper volume suggests. Thoughtworks’ Technology Radar Volume 34, April 2026, places OpenSpec in Assess — the ring Thoughtworks reserves for things worth exploring to understand their effect, not things it recommends adopting — describing it as a lightweight specification layer that aligns human developers and AI agents on what to build before code is generated, and noting its emphasis on “spec deltas rather than defining a complete specification upfront, making it well-suited for existing systems” (Thoughtworks). That brownfield-first framing is the gap in this corpus: four of the five papers assume a spec surface that either already exists or gets grown greenfield. Deriving one from an existing codebase is the problem most teams actually have, and none of the five attacks it — but the wider window does. Reversa (arXiv:2605.18684, submitted May 18) is a reverse-documentation pipeline for exactly this, converting legacy software into traceable operational specifications, with an exploratory COBOL-to-Go ATM migration producing 517 confidence-classified claims, 10 registered gaps, and 53 Gherkin parity scenarios. It is a single exploratory case rather than an evaluation, so treat it as a design proposal — but the problem is being attacked, and the gap is in the selection here rather than in the literature. The operational half of the brownfield question has in-window evidence too: One Developer Is All You Need (arXiv:2605.18461, submitted 18 May) reports a staff engineer with four agents delivering, under an SDD workflow, a brownfield initiative scoped for a four-person squad — in half the planned time, with 90% of AI-generated code accepted on first review. Its own conclusion is the one that matters for this corpus: specification quality and institutional knowledge, not model capability, were the binding constraints. It is a single case study inside one enterprise and reads as such, but combined with Reversa it means brownfield SDD is under-examined rather than untouched.

Practical Implications

Lift the mechanisms, skip the frameworks. All four enforcement mechanics are separable from the methodologies that carry them. In rough order of cost-to-value: the orphan-citation grep (an afternoon), post-phase validation hooks (the ablation’s best single lever), a dependency-boundary drift gate wired into CI, and a regression-oracle pause gate for anything running unattended. None of these obligates you to a spec graph, a REQ hierarchy, or a multi-agent pipeline.
Tier your citation discipline by change size. The determinism penalty is concentrated on easy and small tasks and was not statistically detectable on hard ones — though “not detectable” is not “absent”: the hard subgroup is 13 tasks and the point estimate stays negative (d = −0.34, p = 0.22). Mandate per-line requirement citations above a risk or size threshold, leave them optional below it, and you buy the audit trail where it pays for itself.
Don’t trust an LLM-as-judge delta this small without your own calibration. A +0.15 shift on a 1-to-5 composite, in a study whose blinded human raters leaned the other way, is not a result you should port into a business case. If you evaluate context-grounding hooks internally, run the human comparison alongside the automated one and expect them to disagree.
Treat “zero regressions” as a claim about your oracle. Before adopting an autonomous-evolution loop, write down what your regression oracle can and cannot see, and price the claim accordingly. The Kitchen Loop’s own framing is the right template — a regression count is only as meaningful as the suite that produced it, and a suite that grew alongside the agent’s output has an obvious blind spot.
Decide whether mechanical review substitutes for a human signature — before the pilot, not after. The most production-scaled framework in this set states plainly that no human sits in the critical path during normal operation; its 1,094 merges were gated by multi-model review tribunals and an adversarial UAT pass instead. That is a coherent position, not an oversight, and the question it puts to you is whether your change-management policy accepts the substitution. Whatever you adopt, encode the answer in the gate — Grabowski’s blast-radius model (human approval for contract and root-invariant changes, automatic for internal design changes) is a reasonable starting shape.
Budget grounding latency per workflow family, and instrument selectively. Hooks added 1.1 minutes in the 40-minute-budget family (14.4 → 15.5 min, 15 pairs) and 13.2 minutes in the 90-minute-budget family (24.0 → 37.2 min, 16 pairs) (arXiv:2604.05278). The paper attributes the larger cost to “the longer workflow and repeated hook execution” and is explicit that latency is compared only within each budget family, not across them — it never varies phase count as an independent variable. So instrumenting selectively rather than uniformly is a sensible engineering default, but treat it as a hypothesis to test on your own workflow rather than as a measured scaling law.
Assume brownfield is your problem and the literature’s gap. If your codebase predates the spec, none of these five papers tells you how to derive the spec surface. OpenSpec’s spec-delta model is the nearest thing on offer, and it sits in the Assess ring rather than a recommendation ring.

Open Questions

What is the false-positive rate of a blocking drift gate in a real repository? Grabowski’s gate rejects merges on orphan code, undeclared dependencies, and missing contracts. Every one of those conditions has legitimate instances during refactoring. Without deployment data, the cost of the gate — measured in blocked-but-correct merges and the workarounds teams invent — is unknown.
Do orphan-ID citation checks catch organic hallucinations? The 86–88% detection rate was measured against injected fake REQ IDs (arXiv:2606.30689). A model that miscites a valid requirement — attaching REQ-014.2.1 to code that implements something else — produces no orphan and no grep hit. Whether the mechanism generalizes past its synthetic test case is unestablished.
Why are discovery and validation hooks superadditive? +0.57% and +1.71% individually, +4.27% together (arXiv:2604.05278). The paper reports the effect without proposing a mechanism. If the answer is that validation failures are only recoverable when discovery has already grounded the artifact, that would be a useful design principle; right now it is an unexplained number.
Does drift enforcement survive a codebase the agent didn’t write? Every enforcement mechanism here assumes spec and code grew together under the gate. Retrofitting one onto an existing repository means either accepting a large initial violation backlog or generating specs from code — and generating a spec from code that then blocks changes to that code is a circularity nobody in this set addresses.
Will this corpus consolidate or fragment? Five frameworks, five vocabularies, no cross-citation among them, and — the thing none of them supplies — no shared benchmark to disagree over. Comparison work has started: From Prompt to Process already sets six frameworks against a common taxonomy (arXiv:2606.04967). What is still missing is the harder artifact — an evaluation running two of these frameworks against each other on the same tasks with reported outcomes, rather than a taxonomic comparison. Until that appears, this remains a cluster of design proposals rather than a field.