Generation is Not Solved: What Google's New SDLC Paper Gets Wrong About AI-Assisted Development

✓ Human-authored analysis; AI used for formatting and proofreading.

Google published The New SDLC With Vibe Coding in May 2026, a 51-page paper positioning agentic engineering as the mature successor to ad-hoc AI-assisted development.

It is full of errors. Claims that sound reasonable until you hold them against the formal traditions that govern whether software works.

This article examines twelve specific misconceptions in the paper and offers the grounded alternative for each. The places where it's wrong are the places where teams will make expensive decisions.

The paper's closing line: "Generation is solved. Verification, judgment, and direction are the new craft."

Generating code that compiles is solved. Generating code that passes a test suite is mostly solved. Generating code that is correct meaning it satisfies a complete specification of all required behaviors, including behaviors the test suite doesn't cover is not solved. Conflating these three things is a category error.

Dijkstra spent a career distinguishing between "testing shows the presence of bugs, never the absence of bugs." That distinction is the central problem of software verification. It applies with greater force to AI-generated code because AI models produce plausible-looking output that passes shallow checks while harboring semantic errors that only manifest at system boundaries.

The correction: Generation is automated. It is not solved. Production outages, security vulnerabilities, and data corruption live in the gap between "compiles and passes tests" and "correct under all specified conditions". Any engineering process that treats generation as solved will systematically undercount that gap.

The paper presents context engineering as deciding what information an AI agent needs to do its job as an emergent practice driven by AI tooling. It identifies six types of context: instructions, knowledge, memory, examples, tools, and guardrails.

Parnas's "On the Criteria To Be Used in Decomposing Systems into Modules" is about one thing: what information does a module need, and what information should be hidden from it? His information hiding principle is the design decision is choosing what each module doesn't know. It maps directly onto the paper's static/dynamic context split. The six context types the paper lists are preconditions, postconditions, invariants, and interface contracts, reorganized into a taxonomy that obscures their origin.

The paper even rediscovers the core trade-off Parnas identified: "Too much static context wastes tokens and dilutes signals. Too little means the agent forgets critical rules." Substitute "too much coupling increases complexity" and "too little information causes incorrect behavior" and you have the original formulation.

The correction: Context engineering is specification engineering applied to AI agents. The medium changed (natural language prompts instead of formal interface definitions), but the principles are identical. Teams that treat context engineering as a novel skill without studying its theoretical foundations will rediscover every mistake the specification community already catalogued.

The paper's verification rests on two mechanisms: tests verify deterministic properties, evals (scored by datasets, rubrics, and LM judges) verify non-deterministic properties.

The paper claims the difference between vibe coding and agentic engineering is "how outputs get verified." But its own verification toolkit can only sample behaviors. It cannot prove properties. A system verified only by tests and evals has no guarantees about behaviors outside the test distribution. This is where the catastrophic failures live.

The correction: A production verification framework needs at least three layers: deterministic tests for known behaviors, property-based tests for algebraic invariants, and static analysis for structural properties. For security-critical paths, formal verification of specific properties (e.g., "this function never reads outside the bounds of its input") is not optional. Evals scored by LM judges add a fourth layer for subjective quality, but they are the weakest layer, not a replacement for the first three.

The paper proposes the "factory model" as its central organizing metaphor: the developer's primary output is not code but "the system that produces code" such as specifications, agents, tests, feedback loops, and guardrails.

This metaphor has been critiqued and rejected for 40 years.

Brooks's No Silver Bullet (1986) argues that software development is different from manufacturing because each unit of software is unique. Manufacturing produces identical copies of a designed artifact. Software development is the design process. There is no separate production step. The factory metaphor misleads because it implies that once the assembly line is configured correctly, output is reliable and repeatable. Software does not work this way. Each prompt produces different output. Each context window yields different behavior. The factory has no quality floor.

What the paper describes, specifying properties, constraining agent behavior, verifying outputs against specifications is closer to Lamport's framework for specifying concurrent systems. In Lamport's model, you specify what the system should do (the safety and liveness properties), not how to build it. The specification is the primary artifact. Implementation is a refinement of the specification. Verification proves the refinement preserves the properties.

The correction: Replace the factory metaphor with the specification-refinement model. The developer's primary output is the specification. The precise description of what the system must do and must not do. AI agents perform refinement (translating specification into implementation). Verification proves the refinement is correct. This model is rigorous, has formal foundations, and doesn't mislead teams into thinking they're running a production line.

The paper's equation is "Agent = Model + Harness." The harness is "the car, the road, and the traffic laws." The model is "the engine." Figure 7 labels the model at ~10% and the harness at ~90%.

The metaphor is wrong, and it leads to the wrong investments.

An engine has a defining property: it converts energy into reliable, predictable work. A combustion engine produces torque proportional to fuel input. You can characterize its output curve, its failure modes, its efficiency envelope. It degrades gracefully under load. It does the same thing every time you turn the key.

An LLM does none of this. Given identical inputs, it produces different outputs (temperature > 0). Its failure modes are not characterizable in advance. You cannot predict which prompts will produce hallucinations. It does not degrade gracefully; it fails silently by producing plausible-looking but incorrect output. Calling it an engine smuggles in connotations of reliability and predictability that the component does not possess.

In TRIZ's Law of System Completeness, a framework for analyzing whether a technical system has all necessary components. A complete system requires an Engine, Transmission, Tool, Control Unit, and Energy Source. Applied to an AI agent system, the components map differently than the paper assumes. The Tool is the model. It's the thing that acts on the workpiece (the codebase). The Engine is the element that drives the system forward is the specification-verification-learning loop. The Transmission is the harness, which translates the engine's output into the tool's motion. The Control Unit is the human exercising judgment over whether the system's output satisfies the specification.

This distinction matters. If the model is the engine, you improve the system by upgrading the model. If the model is the tool, you improve the system by improving the loop with tighter specifications, faster verification, better learning from failures. The paper's own Terminal Bench data (harness-only changes moved an agent from outside Top 30 to Top 5) proves the tool framing. They cited the evidence for the right conclusion and drew the wrong one.

The correction: The model is a stochastic tool. The engine of an AI-assisted development system is the specification-verification-learning loop: specify what correct means, generate a candidate, verify it against the specification, learn from the failures, revise the specification. Every investment decision should optimize the loop, not the tool. A better model inside a broken loop produces faster garbage. A weaker model inside a tight loop converges on correct output.

The paper's AI-driven SDLC (Figure 5) prescribes: Requirements → Design → Implementation (agents) → Testing/Eval → Review & Deploy → Maintenance. The recommendations reinforce the sequence: write specs and architecture docs upfront, configure the harness, define eval criteria, then let agents run.

This is waterfall with a faster implementation phase.

The point of the Agile movement, whatever you think of its current institutional form was one empirical insight: you cannot fully specify a system before building it. Requirements emerge from building. The user doesn't know what they want until they see what they don't want. The developer doesn't understand the problem until they've tried to solve it and failed.

The paper eliminates the primary mechanism by which this learning happens.

In traditional development, the developer writes code and learns from the act of writing. The resistance of the material teaches them about the problem's structure. They discover edge cases by hitting them. They revise their mental model of the requirements in real time. The feedback loop between "what I think the system should do" and "what the system does" is tight and continuous.

In the paper's orchestrator model explicitly positioned as the more advanced mode, the developer writes a specification, hands it to agents, and reviews output asynchronously. The human is removed from the implementation loop. But most learning about requirements happens during implementation. When the agent runs autonomously in the background and produces a pull request, the human reviews the output but never observes the intermediate states that would have taught them about the problem.

The paper even identifies "specification quality is the new bottleneck" without recognizing the contradiction: if writing good specs requires understanding the problem deeply, and understanding the problem deeply requires building and failing and learning, then removing humans from the building phase degrades the specs that the paper positions as the foundation of everything.

First, spec drift without revision. The paper recommends writing architecture docs and AGENTS.md files upfront, then running agents against them. But specifications written before implementation reflect pre-implementation understanding. If the human never touches the implementation, they never learn what's wrong with their specification. The spec becomes a stale document that agents faithfully implement, correctly satisfying the wrong requirements.

Second, the METR tax compounds. The paper's own data shows experienced developers take 19% longer with AI assistance. Part of that tax is the cost of understanding code you didn't write. But part of it is also the cost of discovering, at review time, requirements you didn't know you had. Things you would have discovered earlier if you'd been in the implementation loop. Deferring that discovery to review time is more expensive than discovering it during implementation, for the same reason that bugs found in production cost more to fix than bugs found during development.

The correction: The SDLC needs a learning loop, not just a feedback loop. The paper's feedback loop routes test failures back to agents for correction. The agent learns and retries. But the human doesn't learn. A learning loop routes surprises such as unexpected behaviors, discovered requirements, spec violations back to the human to revise the specification. This means: build small, verify early, revise the spec based on what you learned, then build more. It means the specification is a living document that co-evolves with the implementation, not an upfront artifact that agents execute against. It means the human must remain in the loop during implementation, not just before and after.

The conductor mode (real-time, in the IDE) preserves this learning loop. The orchestrator mode (async, background agents) breaks it. The paper positions orchestrator mode as the more advanced practice. It's the more dangerous one. It's only safe for tasks where the specification is already known to be complete which is a small subset of real work.

The paper observes that AI agents can generate approximately 80% of a feature's code, but the remaining 20% such as edge cases, error handling, integration points requires deep contextual knowledge. The paper treats this as an empirical observation about current model limitations and prescribes focusing human attention on "what AI struggles with."

The diagnosis is wrong. This is not a workflow problem. It's a specification completeness problem.

The gap between the 80% and the 100% is not between "easy code" and "hard code." It is between what is specified and what is assumed. Parnas called these the "unstated requirements" — the behaviors the system must exhibit that nobody wrote down because they seemed obvious to the humans who understood the domain.

AI models cannot infer unstated requirements. They generate code that satisfies the stated specification (the prompt) and fills in the rest with statistical patterns from training data. The 20% gap is the set of requirements that exist in the developer's head but not in the prompt.

The correction: The 80% problem is a specification problem. The fix is not "focus human attention on the hard parts." The fix is: make the specification complete enough that correctness is mechanically verifiable. This means writing preconditions, postconditions, and invariants for every interface — not as documentation, but as executable checks. Property-based testing (e.g., with Hypothesis, Rapid, or gopter) is the practical tool for discovering unstated requirements before they become production bugs.

The paper's thesis — developers now express what they want rather than how to build it is presented as an unambiguous advance. The conclusion is titled "Intent as the new Interface."

This framing ignores a critical regression: natural language is a lossy and ambiguous specification medium.

TLA+, Alloy, Z, VDM, and even CEL predicates have been "intent as interface" for decades. They let you say what the system should do without saying how. The difference is that these languages are formal — they have precise semantics, they're mechanically checkable, and they eliminate ambiguity by construction.

Natural language does none of this. "Build a secure API" is ambiguous in ways that a TLA+ specification of the API's safety properties is not. The move from formal specifications to natural language prompts trades precision for accessibility. That trade-off may be worth making for some use cases, but presenting it as pure progress without acknowledging the precision cost is misleading.

The correction: Natural language intent is a useful starting point, not a finished specification. A disciplined workflow starts with natural language intent, refines it into testable properties (property-based test generators, CEL predicates, formal invariants), and uses the testable properties as the contract with the AI agent. The natural language prompt is the sketch. The executable specification is the blueprint.

The paper mentions in one paragraph that a METR study found experienced developers took 19% longer when using AI assistants on certain tasks, primarily because of time spent verifying, debugging, and correcting AI output. The paper then moves on.

This is the most important data point in the entire paper, and it's treated as a caveat.

For experienced practitioners working on complex, unfamiliar, or correctness-critical tasks, current AI tooling may impose a net tax rather than providing a net benefit. The verification burden — reading AI-generated code you didn't write, understanding its assumptions, checking its correctness can exceed the time saved by not writing the code yourself.

This finding is consistent with what the theoretical literature predicts: the cost of understanding a system scales with the system's complexity, not with who wrote it. AI doesn't reduce the complexity of the software; it shifts the work from writing to reading. For systems where understanding is the bottleneck (legacy codebases, security-critical paths, concurrent systems), this shift may not be favorable.

The correction: Teams should measure total task completion time including verification, not just code generation time. For correctness-critical work, the right metric is "time to verified-correct implementation," not "time to first output." The 25-39% productivity gains cited in the paper likely measure the wrong thing — they measure generation speed, not delivery speed. Until the industry converges on measuring delivery of verified-correct code, productivity claims from AI tooling are suspect.

The paper defines "Agent = Model + Harness" and describes harness components: instructions, tools, sandboxes, orchestration, guardrails, observability. It claims that ~90% of agent behavior is determined by the harness, not the model.

The claim may be directionally correct, but the model is missing a critical component: who owns correctness?

The conductor/orchestrator framework defines developer roles around workflow mode — real-time direction versus async delegation. Neither role, as defined, owns the system's properties. In Lamport's framework, someone must own:

Neither conductor (focused on keystroke-level direction) nor orchestrator (focused on task delegation) is responsible for specifying, verifying, and maintaining these properties. The result is that system invariants become emergent properties of the agent's behavior rather than designed properties that the harness enforces.

The correction: Add a third role: the specifier. The specifier owns the system's safety and liveness properties. They write the invariants that the harness must enforce and the properties that verification must prove. The specifier reviews not individual code changes but the system's property set: "After this change, do all invariants still hold?" This role maps to what Stave calls the Judge. The component that evaluates whether the system's output satisfies the specification, independent of how the output was produced.

The paper discusses each SDLC phase independently and evaluates AI output per-task. Its verification framework (test individual outputs, eval individual trajectories) operates at the single-agent, single-task level.

Production systems fail at boundaries. The most dangerous bugs are in the interactions between components where individually-correct pieces compose into incorrect systems.

This is the graph problem. A function that correctly validates input and a function that correctly processes validated input can still compose into a system that processes unvalidated input, if the edge between them (the call site, the data flow, the trust boundary) is missing or incorrect. AI agents generating code module-by-module have no mechanism to verify that the edges compose correctly.

The paper never addresses compositional correctness. There is no discussion of interface contracts between AI-generated modules, no discussion of how to verify that independently-generated components compose into a system that satisfies global properties, and no discussion of the well-known theoretical results (Hoare logic, rely-guarantee reasoning, separation logic) that govern compositional verification.

The correction: Verification must operate at three levels: unit (does this function satisfy its contract?), compositional (do these modules compose correctly across their interfaces?), and system (does the assembled system satisfy its global properties?). AI-generated code requires more attention to compositional verification, because the agent generating module A has no awareness of the assumptions module B makes about A's behavior. Architectural enforcement tools (dependency guards, interface lint, contract-based design) are not optional when AI is generating the components.

The paper's CapEx/OpEx analysis compares vibe coding (low CapEx, high OpEx from token burn and maintenance) with agentic engineering (high CapEx from upfront specification, low OpEx from structured output). The crossover point where agentic engineering becomes cheaper is presented as the key decision point.

The model is incomplete because it doesn't account for escape cost. The cost of bugs that pass both tests and evals and reach production.

For security-critical systems (cloud infrastructure, financial services, healthcare, compliance), a single undetected vulnerability in AI-generated code can exceed the entire cost savings from AI-assisted development. The TCO model needs a third term: risk-adjusted cost of escapes, weighted by the probability that AI-generated code contains defects that evade the verification framework, multiplied by the cost of those defects in production.

The paper's verification framework (tests + evals) has a known escape rate. No test suite has 100% fault detection. AI-generated code may have a higher escape rate than human-written code because AI errors are more likely to be semantically plausible (they look right) and less likely to trigger the pattern-matching heuristics that experienced reviewers use to catch bugs.

The correction: Add escape cost to the TCO model: TCO = CapEx + OpEx + (P(escape) × Cost(escape)). For systems where Cost(escape) is high (security, compliance, financial), the investment required to drive P(escape) acceptably low may dominate both CapEx and OpEx. This is where formal verification, static analysis, and defense-in-depth verification strategies pay for themselves by reducing the expected cost of undetected defects.

These twelve issues share a root cause: the paper treats workflow advice as engineering principles without grounding either in the formal traditions that govern whether software works.

The paper never cites Dijkstra, Parnas, Lamport, Hoare, Liskov, or Brooks. It never references TLA+, Alloy, separation logic, or rely-guarantee reasoning. It never distinguishes between testing (sampling behaviors) and verification (proving properties). It never acknowledges that natural language specifications are lossy.

This matters because the paper will be read by engineering leaders making investment decisions. Those decisions such as how much to invest in verification infrastructure, whether to adopt formal specification practices, how to measure AI-assisted development productivity will be worse if the conceptual foundations are wrong.

The tools are changing. The principles are not. AI agents are a new implementation medium, not a new theory of correctness. The teams that build reliable systems with AI assistance will be the ones that apply the existing theory such as specification, verification, compositional reasoning to the new medium.

Generation is automated. Correctness is still the hard problem.