Spec-Driven Production Grade Development In The Age Of Vibe Coding

Lee Boonstra · pdf · 2026-06-18 Reader 🖥️

Agent Blame Attribution & Accountability Burnout & Recovery Guardrails Policy-as-Code Pull Requests & Async Code Review Sandboxing Spec-Driven Development

Because agentic coding has eliminated the implementation bottleneck and shifted it downstream to the humans who must review, integrate, and govern AI-generated output, production-grade development requires treating specifications as a disposable-code-enabling source of truth, redesigning team review culture (risk-bundled PRs, conditional approval, no-blame norms, tiered continuous reviewers) around that volume, and backing both with defense-in-depth technical guardrails (sandboxing, policy servers, context hygiene) rather than relying on speed of writing or any single control.

practical · mixed — A Google whitepaper (part of a multi-day series) mixing expository framing, prescriptive technique ('plays' on spec formats, review tiers, policy servers), worked code snippets, and anecdote (the hallucinated-email incident, the fintech review-tier case). Written entirely from the vantage point of Google's own agentic tooling (Antigravity, Gemini CLI, ADK).

Structure

Part	Role
Introduction: the Illusion of Speed and 'vibe coding' vs. 'vibe-in-production'	problem statement
Spec-Driven Development: a good specification, formats, where instructions live, execution modes	core technique
MCP as integration layer	infrastructure context
Team Culture & Process Evolution: PR volume problems, code review practices, continuous review tiers, sustainability/burnout	organizational redesign
Zero-Trust Development: the hallucinated-email incident, sandboxing, human-in-the-loop, guardrails, policy server, context hygiene	technical safety net
AI-generated test coverage and evaluation	verification technique
Summary and 'Where to start'	conclusion / call to action

Key terms

Vibe coding vs. vibe-in-production
Vibe coding is using AI to generate code rapidly from high-level intent rather than rigid manual coding; 'vibe-in-production' is the author's named anti-pattern — relying on that unvalidated output directly in production without full intention and control.
Code is disposable
Once a rock-solid specification exists, the entire codebase implementing it can be regenerated repeatedly (even in a different language) without loss, because the spec — not the code — carries the design intent; this removes the emotional/sunk-cost attachment developers have to any particular implementation.
Context fragmentation
The digital equivalent of the game 'telephone': an agent loses the plot because it is working from an outdated snapshot of files or specs that have since changed, producing code based on stale assumptions.
Conditional LGTM
A reviewer approves a PR contingent on it passing all automated tests; if tests turn green, the code merges automatically — proposed specifically to eliminate multi-hour cross-timezone approval delays.
Policy Server (structural + semantic gating)
A two-layer governance component intercepting every agent tool call: structural gating is fast, deterministic, role/environment-based allow-listing (e.g., a viewer role cannot call send_email); semantic gating uses a second LLM to judge whether an allowed action's content violates a natural-language policy (e.g., unmasked PII in an otherwise-permitted email).
Context hallucination (risk)
When an agent lacks specific data needed to complete an action, it fills the gap using whatever strings happen to be present in its current context — including sensitive values like hardcoded email addresses or URLs — rather than refusing or asking.

Propositions

explicit"Vibe coding" (generating code from high-level intent) is explicitly not the same as "vibe-in-production": production-grade reliability requires that AI agent use remain fully intended and controlled, rather than relying on unvalidated AI output reaching production.conf: high
explicitBecause implementation is no longer the primary bottleneck, the freed-up capacity should be redirected toward AI-generated test coverage more comprehensive than any human could write in the same timeframe, as a programmatic way to raise confidence in the resulting code.conf: high
explicitIn agentic development the developer's role shifts from "code-first" implementer to technical architect, because once a sufficiently rock-solid specification exists, the implementing codebase is disposable and can be regenerated repeatedly (even in a different language) without loss of intent.conf: high
extendsSam Hatoum's Post · p5 — Boonstra's 'code is disposable once the spec is rock-solid' is the present-tense, practice-level version of Hatoum's limiting-case thought experiment that if implementation became truly instant, all human effort would go to specification.
explicitcontestedA good specification acts as an 'Architectural North Star,' stored as a version-controlled artifact (e.g. a specs/ folder) that prevents 'context fragmentation' (the agent working from outdated file snapshots) and serves as the shared source of truth for both humans and AI.conf: high
supportsSam Hatoum's Post · p9 — Boonstra's 'spec as Architectural North Star preventing context fragmentation' is the practical restatement of Hatoum's claim that specs function as durable external memory for design intent precisely because the implementer (the agent) has no persistent memory of its own.
contradicts ←Just Talk To It - the no-bs Way of Agentic Engineering · p5 — Boonstra treats a version-controlled, upfront specification as the stable 'Architectural North Star' that production-grade agentic development should anchor on; Steinberger treats heavy upfront spec-writing as 'the old way of thinking,' reserving a written spec only for tricky features.
explicitInstruction format and placement materially affect agent performance: citing a 2026 benchmark, deeply nested configuration parses far more accurately in YAML than in Markdown, JSON, or XML, so specs should mix narrative Markdown with targeted YAML rather than use one format throughout, and instructions should be distributed across the chat interface, a version-controlled specs/ folder, reusable skills, and layered system-prompt files rather than dumped into a single channel.conf: high
explicitTokenization is a hard physical constraint on specification writing: every character, newline, and indentation space in a spec consumes an agent's processing budget and latency, so a specs folder should be treated as a lean, compiled instruction set rather than verbose documentation.conf: high
explicitDifferent execution modes (project generation, feature generation, bug fixing, documentation writing, data engineering) require structurally different prompting strategies — notably, bug fixing should shift from 'symptom prompting' to 'evidence prompting,' require a failing reproduction test before any fix is attempted, and must not let the agent 'clean up' unrelated code alongside the fix.conf: high
explicitAs AI-generated commit volume grows, code review should shift from line-by-line style nitpicking toward verifying architectural integrity, supported by bundled AI-generated risk-assessment summaries attached to each PR, automated style enforcement, and a 'Conditional LGTM' (approval contingent on automated tests passing) to remove cross-timezone review delays.conf: high
supportsArticle: When Spec-Driven Development Pays Off · p3 — Both push review attention toward a structured, named artifact (a bundled AI-generated risk assessment / an approved spec baseline) that lets reviewers tie findings to something specific, rather than relying on free-floating line-by-line critique.
explicitHigh-velocity AI-assisted teams need a deliberate no-blame culture, because the person who produced the most code via an agent becomes an easy scapegoat for bugs or merge conflicts that actually stem from broken integration processes, not individual fault.conf: high
supportsYour AI agent just blamed the network team. Now what? · p14 — Both locate the real problem in organizational/political dynamics (who absorbs blame for an AI-touched outcome) rather than in technical capability — Boonstra's no-blame-culture proposal is the team-culture-side answer to the same diagnosis.
explicitcorroboratedContinuous automated PR review must be deployed as a standing service that watches every PR and runs nightly sweeps, rather than an on-demand skill a developer remembers to invoke, because once a team ships AI-generated PRs at volume, a continuous reviewer is the only mechanism that scales with the output.conf: high
supports ←AI Development Patterns · p9 — Both independently arrive at the same requirement — a standing, automated reviewer watching every agent-produced change rather than an on-demand human-only process — with Duvall supplying a concrete worked pipeline (conflict detection, quality gates, auto-merge, human-review fallback) for the specific case of parallel-agent output.
explicitContinuous code-review infrastructure splits into three tiers trading control for simplicity — managed/vendor (generic criteria, no setup), hybrid/self-written skill triggered from CI (team-specific criteria, a day's work, the recommended default starting point), and fully custom agent runtime (needed only when the reviewer must hold memory across a multi-PR refactor or decompose large-scale compliance/impact analysis) — and most teams should adopt the lowest tier that actually catches what matters to them.conf: high
explicitAt the largest scale (hundred-million-line legacy codebases), effective automated code review requires a knowledge graph combining structural (graph traversal), semantic (vector), and exact (full-text) retrieval, because flattening code into a vector store destroys the structural relationships — class-to-file, function-call-to-requirement — that answer 'what breaks if I change this?'conf: high
explicitFrequent AI tool use is empirically associated with higher burnout (cited: 45% more likely, per a reported industry survey), driven by 'approval fatigue' — reflexive, attention-less approving of a constant stream of micro-decisions — which is a structural problem requiring imposed boundaries (e.g. 'Digital Quiet Hours,' shared 'Agent Insight Sessions') rather than individual self-discipline.conf: high
supportsAI productivity is burning out your best engineers · p6 — Both insist the fix for AI-driven review/approval burnout is structural and leadership-owned (named boundaries, named roles) rather than individual resilience or self-discipline.
explicitA single under-specified autonomous action (a browser agent clicking a newly created button with no target URL) escalated into sending fifty colleagues hallucinated emails, illustrating that an agent facing a context gap fills it with whatever data is already present in its context rather than refusing — making guardrails, not just correctness checking, the binding constraint on autonomy.conf: high
explicitProduction-grade agent governance requires two distinct layers working together: a deterministic 'structural gating' layer (fast, role/environment allow-lists, no LLM call needed) and a probabilistic 'semantic gating' layer (a second LLM judging whether an allowed action's content violates a natural-language policy, e.g. unmasked PII in an otherwise-permitted email) — because static rules alone cannot regex-detect every possible semantic policy violation.conf: high
explicitSeparating execution logic (what an agent can technically do) from governance logic (what it is allowed to do, enforced by a policy server intercepting every tool call) is a necessary architectural pattern for enterprise-grade autonomous agents, not an optional add-on layered on afterward.conf: high
implicitThe paper treats rising code-generation velocity (a thousand well-documented lines by lunchtime) as an unquestioned benefit to be safely absorbed through better review and governance, never asking whether producing that volume that fast is itself a defensible target rather than a given to be managed.conf: medium

Arguments

As AI eliminates the code-production bottleneck, an organization's safety net must shift from catching mistakes in the code itself to governing the behavior of the agents producing it, because review volume alone cannot catch every failure mode. strength: high

Explicit premises:

Implementation speed is no longer the constraint, so review volume increases sharply.
A single under-specified agent action can cascade into a serious incident before any reviewer sees a diff (the hallucinated-email case).
Static, deterministic permission rules cannot detect every semantic policy violation (e.g. unmasked PII inside an otherwise-permitted action).

Implicit premises:

Governance infrastructure (policy servers, sandboxes, context hygiene middleware) is a tractable engineering investment organizations can build and maintain in-house.
No single control (sandboxing alone, or human review alone, or structural rules alone) is sufficient on its own.

Inferences:

Production-grade reliability for agentic systems requires defense-in-depth — structural gating, semantic gating, sandboxing, context hygiene, and human-in-the-loop checkpoints together — rather than any single control.

Teams should adopt the lowest-tier continuous code-review runtime that catches what actually matters to them, rather than defaulting to the most sophisticated (Tier 3, knowledge-graph-backed) architecture. strength: medium