Upstream

8.1 million pull requests. 4,800 organizations. LinearB's 2025 benchmarks contain a contradiction that nobody pauses on long enough.

AI-generated pull requests wait 4.6 times longer for their first human review than human-written code. Agentic PRs wait 5.3 times longer. They're 154% larger, contain 75% more logic errors, and get accepted only 32.7% of the time versus 84.4% for manual code.

But once review actually begins, AI PRs are processed twice as fast.

The code isn't harder to read. It's harder to trust.

The Trust Problem

Without a specification to verify against, every code review is a trust decision. The reviewer must reconstruct the developer's intent from the implementation, assess whether that intent is correct, and evaluate whether the implementation satisfies it. Three layers of inference, simultaneously, under time pressure.

When a human writes the code, the reviewer can shortcut: they know the developer, trust their judgment, understand the context. When an AI writes the code, those shortcuts vanish. The reviewer faces the same implementation but with no human intent behind it — just output. The 4.6x wait isn't laziness. It's a rational response to an epistemically different artifact.

And AI reviewing AI doesn't fix it. Zietsman's research identifies why: when generating and reviewing agents share a training distribution, their failures correlate. Echo rather than cancel. The review becomes circular — one model's blind spots are the other's. Without an external reference, the loop is closed.

Five Groups, One Conclusion

The external reference is a specification. Not a design document gathering dust in a wiki. A structured, executable spec that defines what the system should do before any code is written.

Five independent research groups arrived at this conclusion within a twelve-month window:

Different teams. Different countries. Different methodologies. Same conclusion: when code generation becomes cheap, specification becomes the binding constraint.

Trust to Conformance

The mechanism is specific. Specification converts trust decisions into conformance decisions.

That's why LinearB's AI PRs move twice as fast once review begins — when the reviewer knows what to check against, the code itself isn't the obstacle. And it's why SGCR's dual pathway works: the spec handles the conformance layer deterministically, freeing human judgment for the residual — the things beyond the spec's reach. Specification doesn't eliminate judgment. It reduces the domain over which judgment is required.

Fifty Years

Zietsman's third paper contains the sharpest finding in the entire convergence. Aviation software certification — DO-178C — has enforced specification completeness for safety-critical avionics since 1992. Three structural requirements: every requirement traces to a spec, every spec traces to a verification artifact, and verification produces auditable evidence rather than subjective assessment.

None of these exist in AI-assisted software development governance.

The AI coding industry in 2026 is learning what aviation learned in the 1970s and 1980s. That's not an insult. It's a structural observation about how domains independently discover the same constraints when the consequences of specification failure become visible enough. Faros reports incidents per PR up 242.7%, code churn up 861%, review time up 441.5%. GitClear's 623 million code changes show refactoring down 70%, duplication up 81%, defect costs at four times 2023 levels. The consequences are becoming visible.

The Recursion

Twenty-six articles on the generation/verification asymmetry invite the obvious question: if specification is the binding constraint, who verifies the specification? Doesn't pushing verification upstream just push the recursion upstream?

Yes. But upstream, the recursion attenuates instead of compounding.

Code-level verification recursion compounds downward. Automated generation → automated testing → automated test validation → automated validation of the validator. Each layer is more abstract, further from ground truth, harder to check. This is what "The Verifier" described: the verification stack grows faster than the confidence stack.

Specification-level recursion works differently. The spec is shorter than the code it describes. It's closer to natural language. It's closer to the domain expert's understanding. And it's closer to where formal methods — Lean, Coq, Verus — actually work. The gap between spec and intent is smaller than the gap between code and intent, and more amenable to both human review and formal verification.

This is what "Trust Is Free" looked like from the constructive side. Formal verification works when the spec-intent gap approaches zero. Specification-first doesn't achieve zero — humans write imperfect specs — but it operates in the zone where the gap is smallest and most tractable to close. The recursion doesn't disappear. It gets easier at each level up. That's enough.

The Honest Limits

The positive case is early. These need stating:

The strongest deployment evidence — Itaú — is N=1. The authors call it a "boundary test," not a universal model. The selection bias question is unresolved: organizations capable of writing good specs may simply be organizations that succeed regardless.

Claimed first-pass improvements of 3-10x come from vendor reports. Not independently confirmed. Thoughtworks placed SDD in "Assess," not "Adopt." The less-disputable finding is that developer time shifts from coding to specifying — not that total effort shrinks.

Most critically: specification-first addresses generation — roughly 30% of software lifecycle cost. The remaining 70% is maintenance. O'Reilly's analysis draws the distinction between spec-first (specs govern generation) and spec-anchored (specs live alongside code through its entire life). The industry has the first. It does not yet have the second. The gap between spec and code reopens over time unless the spec is maintained — and nobody has shown that it will be.

And DORA's 2026 findings remain the necessary counterweight: AI amplifies whatever engineering culture it lands in. Organizations with good processes benefit. Organizations without suffer. Specification-first may be the mechanism by which good organizations get better — not the mechanism by which struggling ones improve.

In July, Addy Osmani wrote the sentence that five research groups had already proved: "Generation is mostly solved. The work that remains is specification and verification, and the systems that hold them together."

For 26 articles, this blog has tracked why verification doesn't scale with generation. The answer was always the same: there was no external reference. The review was subjective. The intent was implicit. The judgment was unstructured.

Specification provides the external reference. It doesn't solve the problem. It makes the problem tractable. In a space that has spent two years generating faster than it can verify, tractable is the positive case.