The industry has moved past the question that dominated the last two years. “Can an AI write this code?” is answered. It can, and it does — a large and growing share of new code is now machine-generated. The open question is different and harder: how do you trust output arriving faster than any team can read it? Generation stopped being the scarce resource. Validating that what was generated fits the architecture is now the scarce resource.
Google’s spec-driven development paper is one of the clearest statements of this shift to date. It is worth engaging seriously, because it is mostly right. Where it stops short is instructive, and it points directly at the layer that has to come next.
What Google’s Spec-Driven Development Paper Shows
The paper, part of Google’s 2026 AI Agents intensive, sets out to bridge the gap between fragile, “vibe-coded” prototypes and production-grade software. Its central moves are these:
- Code is disposable; the specification is the durable asset. When a model can regenerate an implementation in seconds, the implementation stops being precious. The blueprint that describes intended behavior is what carries value across regenerations.
- The spec lives in the repo as the source of truth for humans and machines alike. The paper leans on behavior-driven, Gherkin-style specifications so that intended behavior is written down in a form both people and agents can work against.
- Implementation is no longer the limiting factor. The paper is direct that AI writes code — and potential mistakes — at a rate humans cannot match. The hard part shifts to review, integration, and trusting output at scale.
- Trust is engineered through a zero-trust pipeline. The paper recommends policy servers, deterministic structural gating, sandboxing, human-in-the-loop checkpoints, and automated AI code-review agents, organized into tiers a team can adopt incrementally.
This is a strong, practitioner-grade framing. It names the real problem and refuses the fantasy that faster generation is a free lunch. Google’s own tooling — Antigravity, the Gemini CLI, and MCP-based context wiring — sits underneath as the delivery vehicle. If you take one thing from the paper, take the reframing: the durable engineering artifact is intent, not code.
The New Limiting Factor Is Validating Architectural Consistency
Once implementation is cheap, the constraint moves downstream. Every generated change is plausible. Most of them work. The expensive question is whether each one is consistent with the system it just joined — whether it respected the service boundaries, used the approved libraries, followed the conventions, and honored the architectural decisions the team already made.
That is not a code-quality question. A change can be clean, tested, and locally correct and still quietly violate an architectural decision recorded eighteen months ago. When one feature fans out across several agents, each optimizing its own slice, the odds of a system-wide decision surviving untouched drop with every additional generation. This is the scarce resource now: not producing code, but verifying that a flood of produced code stays inside the architecture.
Where the Paper Is Strongest
Most of the paper’s prescriptions are correct and Mneme agrees with them without reservation. It is worth being specific about what genuinely holds up:
- Spec-driven development itself. Writing intended behavior down before generation, in the repo, is the right foundation. It is the same premise behind treating architectural intent as something explicit rather than tribal knowledge.
- Repo-local specs as source of truth. Keeping the spec next to the code, versioned with it, beats a stale wiki every time. Intent that drifts from the codebase is intent debt waiting to be discovered in an outage.
- Policy servers and structural gating. Centralizing rules so they are applied uniformly, rather than re-litigated per pull request, is exactly the right instinct.
- Sandboxing and zero-trust posture. Treating agent output as untrusted until proven otherwise is sound security engineering. The default should be denial, not permission.
None of this is in dispute. The disagreement is narrow, and it lives in one specific link of the chain: how the pipeline decides that a change is architecturally acceptable.
Where Deterministic Governance Differs From AI Reviewing AI
The paper’s trust mechanism leans on automated review agents — models that inspect the output of other models and flag problems. This is useful for catching classes of defects. It is the wrong tool for establishing architectural authority, and the reason is structural.
Generation is probabilistic. A model produces a plausible answer, not a guaranteed one. Run the same prompt twice and you may get two different verdicts. That is acceptable for drafting code. It is not acceptable for the final decision about whether code is allowed to land. If the reviewer is also probabilistic, you have not established authority — you have added a second opinion that is confident, fast, and occasionally wrong in ways you cannot predict or reproduce.
Architecture is not a matter of opinion. “This service may not read another service’s database directly” is a decision that was made once, for stated reasons, and recorded. Checking a change against that decision should return the same verdict every time, for the same change, forever. That is what deterministic enforcement means, and it is precisely what a model-reviewing-a-model cannot promise.
A probabilistic reviewer can tell you a change looks fine. It cannot tell you the change obeys a specific recorded decision, the same way, every time. Authority over architecture has to be deterministic, or it is not authority — it is a well-informed guess.
The contrast is sharp enough to lay out directly:
| AI reviewing AI | Deterministic engineering governance |
|---|---|
| Probabilistic verdict, may vary run to run | Same change, same verdict, every time |
| Judges against a model’s learned priors | Judges against recorded decisions (ADRs, standards) |
| Explains a rejection with generated prose | Names the exact decision that was violated |
| Confidence without provenance | Enforcement with a checkable contract |
| A second opinion | An authority |
This is not a claim that AI review is worthless. It is a claim about where it belongs. AI review is excellent for the fuzzy, judgment-heavy layer — readability, likely bugs, missing edge cases. It is the wrong instrument for the yes/no question of whether a change is inside the architecture. That question deserves a check that does not change its mind. We have made this argument at length elsewhere: review, human or machine, is not the same thing as governance.
Engineering Governance Is a Distinct Layer
It helps to be precise about what this layer does and does not do, because “governance” is an overloaded word. Engineering governance in this sense is not model-risk management, not regulatory compliance, not content safety. It is the layer that verifies generated code against the engineering organization’s own recorded decisions:
- Architectural decisions (ADRs). The boundaries, the layering, the “we chose X over Y and here is why” record.
- Service and module boundaries. What may call what, what owns which data, where the seams are.
- Approved technologies. The sanctioned libraries, frameworks, and patterns — and the ones deliberately ruled out.
- Conventions and standards. Naming, error handling, structure — the consistency that makes a codebase legible.
These are all things a team already decided. Governance does not invent them. It makes them enforceable, so that a decision recorded once is honored by every agent, on every change, without a human re-explaining it each time. That is the difference between a specification, which tells an agent what to build, and governance, which verifies whether it was built within the architecture.
Spec-Driven Development Plus Engineering Governance
The right conclusion is not to reject spec-driven development. It is to finish it. Google’s pipeline is close; it needs one more stage with different properties than the rest. The full shape looks like this:
- Requirements. What the change should accomplish.
- Specification. The behavior, written down in the repo as the source of truth — the paper’s core contribution.
- Generation. The agent produces an implementation against the spec.
- Deterministic governance. The change is checked against the recorded architectural decisions before it can land. Same change, same verdict. Violations are rejected with the specific decision named, so the agent can retry compliantly.
- Risk-based review. What survives deterministic gating goes to review sized to its risk — AI review for the routine, human review for the consequential.
- Production. Only changes that passed both a deterministic architectural check and a risk-appropriate review.
The critical insight is that steps 4 and 5 are different kinds of check and must not be collapsed into one. Step 5 is judgment, and probabilistic tools are fine there. Step 4 is authority, and it has to be deterministic. Google’s paper effectively merges them into “AI review with a policy server in front.” Pulling architectural verification out into its own deterministic stage is the missing piece. This is the same conclusion our evergreen argument reaches: spec-driven development still needs governance — a spec defines intent, but something deterministic has to enforce it.
The Next Step After Spec-Driven Development
Google is right that code is disposable and the spec is the durable asset. Google is right that trusting AI output is the real problem, and right to reach for zero-trust pipelines, policy servers, and sandboxing to solve it. The one place the paper stops short is treating architectural compliance as something another model can adjudicate. It cannot — not with authority, not reproducibly.
Specifications tell AI what to build. Engineering governance verifies whether it was built within the architecture. The next step after spec-driven development is not another reviewer with better prompts. It is a deterministic layer that checks every change against the decisions the team already made and recorded — and returns the same answer every time. That is the difference between hoping the architecture held and knowing it did.