The bottleneck in AI-assisted development has shifted. Writing code is no longer the hard part. Verifying that the code is correct, secure, and does what it should is. A new study accepted at GAISS 2026 tested whether treating specifications as governance artifacts, not just prompt decoration, solves that verification problem. The results are more nuanced than the spec-first crowd wants to hear.
The study measured two things: recall, how many real bugs reviewers found, and attribution, whether each finding could be traced to a specific requirement rather than a vague sense that something looked wrong. Spec-driven governance did not improve recall. Reviewers caught statistically indistinguishable numbers of bugs with and without a specification baseline. What it did improve was attribution. Baseline reviewers tied 81% of their findings to named requirements. Code-only reviewers, with no contract to reference, attributed none.
Why the bottleneck moved in the first place
AI coding assistants are no longer experimental. Most engineering teams use them weekly. AI generates a large and growing share of production code across the entire lifecycle. The problem is that AI raised the volume of code without raising anyone's confidence that the code is correct or aligned with what was actually intended. Studies report real productivity gains but also quality problems under production conditions, along with a steady stream of AI-generated code reaching production with security weaknesses, familiar bug patterns, and quiet behavioral drift.
This creates a governance problem, not just a capability problem. Who is accountable for AI-generated behavior? How do you detect when it diverges from intent? How do humans and models split the labor of oversight? These questions matter now because regulatory obligations are landing. The EU AI Act's high-risk provisions demand risk management, record-keeping, and meaningful human oversight. ISO/IEC 42001 requires a documented AI management system with controls and audit trails. The NIST AI Risk Management Framework organizes the same expectations under Govern, Map, Measure, and Manage.
If a growing share of production code is AI-generated, saying you review the output carefully provides little evidence of how risk management, record-keeping, and human-oversight controls are actually implemented. The specification-as-governance approach tries to close that gap by making the contract explicit and auditable.
What the study actually tested
The study used a multi-account banking service as the system under review. This was a deliberate choice. Banking concentrates the properties that make AI-generated code risky: money must be conspired, transfers must be atomic and idempotent, overdrafts and daily limits must be enforced, and every balance change must be auditable. The system exposed an API that a real core-banking system would recognize, with operations for opening accounts, depositing, withdrawing, transferring, accruing interest, generating statements, and closing accounts.
Five reviewers, each with three to ten years of experience, performed two independent reviews in a counterbalanced design. In one condition, reviewers received the approved specification, high-level design, and low-level design, and reviewed the code against it. In the other, they received only the public API and had to judge correctness without any approved contract. This second condition is exactly how most teams review AI-generated code today.
Ground truth was established by adjudicating each service against a 20-invariant baseline through source inspection, not just running a test suite. The test suites missed real defects that reviewers correctly found. Eleven adjudicated drifts existed in one service, ten in the other. Generation used a mix of frontier models including Claude Opus 4.8, GPT-5.2, DeepSeek V4, and Gemini 3.1.
The numbers that matter
Recall was essentially identical. Baseline reviewers found an average of 5.6 out of 11 drifts. Code-only reviewers found 5.4. The difference of 0.2 is not statistically significant (p=0.69). The intuitive selling point of spec-driven governance is that it makes reviewers better bug-finders. On this task, it did not.
Attribution is where the effect lives. Baseline reviewers tied 81% of their findings to a named invariant or specific requirement. Code-only reviewers, with no contract to point at, attributed none. This matters because governance frameworks require traceability. Saying "this looks wrong" is not the same as saying "this violates the transfer_atomic_on_fail invariant defined in section 3.2 of the approved design." The former is an opinion. The latter is an auditable finding.
The cost of that attribution is time. Baseline reviews took an average of 48.4 minutes. Code-only reviews took 26.7 minutes. That is an 81% increase, statistically significant at p=0.043. Reviewers also reported higher confidence in their findings when working with the baseline (4.2 vs 3.4 on a five-point scale, trending toward significance at p=0.068). They spent more time and felt more certain about what they found, even though they found the same number of bugs.
The reasoning effect nobody talks about
The study's generation-side experiments revealed something important about easier tasks. When models are given a specification and asked to implement from it in a single prompt, the quality improvement people attribute to "specifying first" is largely a reasoning effect in disguise. The model reasons through the requirements as it generates code, and that reasoning improves output quality. If you strip out the reasoning and just compare direct generation to spec-then-code on simple tasks, the difference shrinks dramatically.
This means teams claiming that specification prompting improves quality should control for reasoning first. On easy tasks, you may be getting the benefit from the model thinking through the problem, not from the specification itself. The specification matters most on hard, multi-constraint work where the model's reasoning alone is insufficient to navigate all the requirements correctly.
What this means for teams building with AI
The governance model under test produces five lifecycle control points: specification authoring, review gate, guided generation, drift detection, and reconciliation. Each one emits an artifact the next consumes. The approved baseline captures what humans agreed the system should do. The generation record ties the code to that specific baseline. The drift log records where the implementation diverged. The reconciliation record captures how a human resolved each divergence.
The audit trail every governance regime asks for falls out of this loop as a byproduct. Each AI-generated behavior traces to an approved requirement and an accountable human decision. That is the operational meaning of meaningful oversight, the part that conceptual governance frameworks usually leave undefined.
For teams shipping AI-generated code into production, the takeaway is practical. Specification-driven governance does not help you catch more bugs. It makes the bugs you catch accountable and auditable. That distinction determines when the added time and cost are worth paying. On simple tasks with low stakes, the overhead is probably not justified. On complex, multi-constraint systems where correctness matters and regulatory compliance is required, the attribution and traceability alone justify the investment, even if recall does not improve.