Vibe Coding vs Agentic Engineering: What Google's New SDLC Paper Argues

From a catchphrase to a whitepaper

Early in 2025, Andrej Karpathy sketched a style of programming where you give in completely to the vibes, ride the exponential curve and stop caring that code exists. The cycle was to prompt, accept, run, and on failure feed the error message back in. The label spread at once, although people already worked that way. It just lacked a name.

Roughly sixteen months on, Google released a 50-page whitepaper titled The New SDLC With Vibe Coding, written by Addy Osmani, Shubham Saboo and Sokratis Kartakis. It's dense and neatly structured, and its message stings: vibe coding was fine for prototypes, yet it's slowly wearing down production systems, and many teams miss this because the harm accumulates gradually. The sections below cover the paper's argument, its firm dividing line and what it implies for people building with AI agents in 2026.

Why vibe coding worked, and where it stops

Vibe coding caught on because it lowered the floor. Prototypes took minutes, non-engineers could assemble working tools, and the gap between an idea and running code shrank from days to hours. That's valuable, and waving it away is engineering snobbery. The floor was never the issue, though. The ceiling is.

Once agents got better, teams started pushing the same casual prompt-and-accept habit into production work, including payment APIs, authentication logic, data pipelines and healthcare tools. The output looks neat and usually clears basic tests, so it goes live. Some weeks or months later, something fails in a way that's expensive and awkward to trace.

The cause is structural. Vibe coding was built to get something running quickly, not to meet production-grade correctness requirements, and those are different goals. Mixing them up is where today's problems come from. The whitepaper tries to hand teams the vocabulary and framework to stop mixing them.

A spectrum with one dividing factor

The paper lays out a spectrum, with vibe coding at one end and agentic engineering at the other. Most practitioners sit somewhere between and can't say exactly where, which is itself part of the trouble.

The spectrum runs across three dimensions: how intent is specified, how rigorous verification is, and the risk profile. One factor separates the ends, and it isn't which model you use, how clever your prompts are or what tool you pick. It's how outputs get verified.

Two kinds of checking are needed. Deterministic tests ask whether a function returns the right output for a given input. Trajectory evaluations ask whether the agent followed the right sequence of reasoning steps to get there. Without both, you're vibe coding however elaborate the setup looks. A polished, fluent result that skipped verification isn't a success. It's a more dangerous failure than one that shows an error, since it stays hidden until production. That's the hard line, and it explains why many teams with sophisticated agentic workflows are still technically vibe coding.

The model isn't the main variable

This is probably the most important technical reframe in the paper, and plenty of developers get it wrong. When an agent misbehaves, the usual reaction is to blame the model as too weak, too slow or too prone to hallucination, and to assume a better one is the fix. That reasoning is almost always mistaken.

The model is only one part. The rest, namely prompts, tools, context policies, execution sandboxes, sub-agents and observability, forms the harness, and an agent's behavior owes much more to the harness than to the model. Two data points in the paper make the case. On Terminal Bench 2.0, one team lifted a coding agent from below the top 30 into the top 5 by altering the harness alone. In a separate LangChain study, edits to the system prompt, tools and middleware around an unchanged model added 13.7 points to a coding agent's benchmark result.

Rule files, tools, sandboxes, orchestration logic, guardrails and observability all belong to the harness, and building it falls entirely to the team. The provider ships the engine and the team constructs the factory floor around it. Looked at honestly, most agent failures are configuration problems: a tool that's missing, a rule that's vague, a guardrail that's absent, or a context window swamped with noise. Blame lands on the model since it's the visible layer, while the actual defect lives in the harness. Chasing model upgrades and neglecting the harness resembles fitting a quicker engine to a car with no brakes.

Context engineering replaces prompt engineering

Prompt engineering as its own discipline has mostly faded, and context engineering has taken its place. That means supplying agents with rich, organized information about the codebase, architecture, conventions and intent they're working in. The paper lists six context types every agent needs: instructions, knowledge, memory, examples, tools and guardrails. Each may be static, present in every interaction, or dynamic, brought in on demand.

Static context costs a lot, since each token travels with every model call whether it matters or not. Excess wastes tokens, weakens the signal and can hurt performance by hiding key rules in noise. Dynamic context is cheaper, coming from RAG pipelines, task-matching triggers or tool results at the moment of need. Choosing what goes where is a core engineering trade-off and not a configuration footnote, so it deserves versioning, review and the same care as other design decisions.

The best pattern here is Agent Skills: structured, portable bundles of procedural knowledge that load only when a task needs them. Instead of cramming specialist knowledge into the system prompt, skills let the agent remain a light generalist that becomes a specialist when called on. An AGENTS.md that deals with this boundary well could read like this:

# Project: PaymentService API

## Architecture
- REST API, Node.js, PostgreSQL
- Never modify /src/core/billing without explicit approval

## Agent Skills (load on demand)
- skill:stripe-integration → load when task involves payments
- skill:database-migrations → load when task involves schema changes

## Hard Constraints
- No hardcoded credentials
- All new endpoints require integration tests before merge

The exact syntax matters less than the idea of intent encoded as constraint. The agent learns what it is, what it may touch, what triggers specialist behavior and what's forbidden without approval, and none of that has to sit in every context window. That's the difference between an agent that stays dependable across hundreds of tasks and one that drifts after the first dozen.

The 80% trap

Agents can write about 80% of a feature's code fast. That share tends to look clean, survive a surface review and ship without drama, which is how the trap closes. The last 20% is where systems break: edge cases, business rules held in people's heads and not in documents, integration points between services built years apart by separate teams, and fine correctness requirements that appear only under real load or real user behavior.

The nature of AI mistakes has also changed. Early coding tools made obvious syntax errors that review caught easily. Current agents make conceptual ones: wrong assumptions about business rules, plausible but missing edge cases, and architectural choices that bring hidden long-term maintenance debt. The code looks right and may pass the test suite, yet the failure is structural, delayed and usually far costlier to repair than to prevent.

This is why trajectory evaluation, meaning inspection of the agent's reasoning path along with its output, can't be skipped in production agentic systems. Output evaluation asks if the function returned the right result. Trajectory evaluation asks if the agent grasped the problem before writing anything. Each question counts, and looking only at output lets the final 20% through. The developers who cope best aren't speeding up by accepting everything. They gain speed by putting their own judgment where AI judgment is structurally weakest: unclear requirements, architectural trade-offs and correctness at system boundaries.

Conductor and orchestrator modes

The paper describes two operating modes, and moving between them may be the most practically significant career shift in software engineering today. In conductor mode the developer works live in the IDE, watching code appear, steering with corrections and holding fine-grained control of each change. It preserves the intuition and sense of understanding engineers are trained for. The cost is throughput, because directing every interaction personally caps the gains from AI.

Orchestrator mode sits a level higher. Developers set goals, hand them to agents and review what comes back, without watching code appear line by line. Agents work in parallel inside background sandboxes, at times for hours, and return pull requests. The developer looks in periodically, assesses results and redirects as needed.

Conductor mode is real-time, hands-on and single-agent. Orchestrator mode is asynchronous, with parallel agents and a pull request as output. Most developers are trained conductors, and the move to orchestrator is a large change of role.

The required skills differ too. Conductors lean on deep language and syntax knowledge, quick debugging, a feel for the codebase and live error interpretation. Orchestrators need exact specification, task decomposition, fast evaluation of results and system design, which means shaping the constraints, tests and feedback loops that keep agents dependable without close supervision. Many senior developers are practiced conductors, and orchestrating feels uncomfortable because it feels like giving up control. At times it is, so harness infrastructure, eval coverage and context engineering should be in place before orchestration expands. Delegating with no verification setup isn't engineering. It's vibe coding at scale.

An economics question

The paper treats the vibe-coding-versus-agentic-engineering debate as a question of cost, not method. Vibe coding costs almost nothing upfront: no specification discipline, no eval infrastructure, no harness design, no AGENTS.md upkeep. Yet it piles up hidden operating debt quickly through token waste from unstructured context, a growing bug surface from unchecked output, and developer time lost to failures that automated evals ought to catch.

Agentic engineering takes real, front-loaded investment in specification rigor, evaluation infrastructure, harness design and context architecture. After that, the marginal cost per feature drops sharply, because each new agent capability reuses the same harness, eval suite and context architecture.

For one developer, a prototype or a side project, vibe coding clearly wins on cost. No production system needs protecting, and the debt never reaches a dangerous size. Teams hit the crossover sooner than expected. Five engineers vibe coding for three months can easily end up with a third of their capacity swallowed by debugging and rework that systematic verification would have avoided. Agentic infrastructure repays its cost, provided it goes in before the debt passes its tipping point.

What the paper settles and what it doesn't

The paper isn't a product pitch. It's a framework document, and a handier one than most because its main claims can be checked. The harness effect is real and measurable, as the cited benchmarks show. The 80% problem is real and grows sharper as agents take on harder work. And the shift from conductor to orchestrator is already happening in every serious engineering organization at scale.

Left open, apparently on purpose, is where a given team should sit on the spectrum. That turns on stakes, team size, deadline pressure and technical maturity, in ways no framework can dictate. The paper provides vocabulary and a mental model, and the judgment call stays with people, which is probably the most candid position available.

Structure scales, and vibes don't. Developers who absorb that now are building on very different ground from those who'll learn it the costly way in production.