Google's Vibe Coding Whitepaper, Explained in Plain English

Google put out a 51 page whitepaper in June about how AI is changing the way software gets built. It is free, it is better than most things with the word "whitepaper" on the cover, and almost everyone I know saved the link and never opened it. So this is the plain English version: what it says, what the jargon means, and which parts I think are actually worth changing your week over.

The short version is that the paper draws a line between two things people currently call by the same name. Vibe coding is when you let an AI write code and you do not read it. Agentic engineering is when an AI writes the code inside a structure you built, with tests and checks that catch it when it is wrong. Same tools, same models, completely different activity. The paper's argument is that the line between them is not which assistant you bought. It is whether anything verifies the output.

What the paper actually is

It is called The New SDLC With Vibe Coding, written by Addy Osmani, Shubham Saboo and Sokratis Kartakis. It went out as Day 1 reading for the 5 Day AI Agents Intensive Vibe Coding Course that Google ran on Kaggle from June 15 to 19, 2026. The course has finished but the material is still up and still free, and you do not need to have taken it.

Worth setting expectations: this is a course handout, not research. There is no methodology section and nothing was peer reviewed. It is a well organised argument by people who have thought about this a lot, and reading it that way rather than as a Google study will save you some disappointment later.

Where "vibe coding" came from, and what it actually means

Andrej Karpathy posted the phrase in February 2025. His description was that you give in to the vibes, embrace exponentials, and forget the code even exists. He described accepting every suggestion, not reading the diffs, and pasting error messages back at the model until things worked.

The part everyone drops is that he scoped it. He was talking about throwaway weekend projects. Within a few months the phrase had stretched to cover anything involving an AI, which is how you end up with a senior engineer carefully specifying a feature and a teenager building a to do app both describing their work with the same two words.

So the paper narrows it back down, and the definition it lands on is the useful one: vibe coding means you are not reading the code. That is the whole test. Not how casual your prompt was, not whether you used an agent. If you shipped something you did not read, you vibe coded it.

The other end of the spectrum took longer to name. Simon Willison proposed "vibe engineering" in October 2025, describing the gap he was trying to fill: what do you call it when experienced people use these tools hard and stay accountable for what they ship? The community argued about it for a few months, and in February 2026 Karpathy said agentic engineering was his favourite of the options going around. That is the name that stuck.

The spectrum, and the one thing that moves you along it

The paper's central picture is a line with three positions on it.

On the left, verification is "it ran and nothing exploded." In the middle, a human looks at the parts that matter. On the right, there are automated tests, evaluations and gates that have to pass before anything moves.

The distinction the paper makes here is small and genuinely useful. Tests check the parts of your system that are deterministic: give this function that input, get this output. Evaluations, or evals, check the parts that are not: did the agent take a sensible route, pick the right tools, produce an answer that clears the bar. You need both, because an agent can produce a perfect looking result having skipped every step that would have made it correct.

The practical takeaway is that your position on this line should change depending on what you are building. A weekend prototype can sit hard on the left and that is fine. Anything touching money or customer data belongs on the right. Most work is in the middle, and the skill is knowing where to draw the line for each task rather than picking one mode and applying it to everything.

The idea worth stealing: your agent is mostly not the model

This is the section I would read first if you only have ten minutes.

When an agent does something stupid, the instinct is to blame the model. New model, agent gets smarter. Old model, agent gets worse. The paper argues that this intuition is wrong and that it leads people to spend money in the wrong place.

A raw model is not an agent. It becomes one when you wrap it in what the paper calls a harness: the rule files that tell it who it is, the tool definitions, the sandbox its code runs in, the logic that decides which sub agent handles what, the hooks that run automatically at fixed points, and the logging that tells you whether any of it is working.

The line the paper uses is Agent = Model + Harness, and the point it drives at is ownership. The model is the provider's problem. The harness is yours. When people say Claude Code and Cursor and Codex "feel different" while running similar models underneath, what they are noticing is mostly harness.

There is a nice piece of evidence for this. LangChain took its own coding agent, left the model completely alone, and only changed the scaffolding around it: the system prompt, the tools, the middleware. Its score on Terminal Bench 2.0 went from 52.8% to 66.5%, which was enough to put it fifth on the leaderboard in February 2026. Same model, 13.7 points. You can read the full writeup, and it is worth it because the details are more instructive than the headline.

Two honest footnotes on that number. It has aged, as benchmark results do: that entry now sits at 27th out of 142 because the whole field moved up around it. And the single biggest jump in their experiment came from tuning how hard the model thinks rather than from a prompt or tool change, which sits a little awkwardly inside "we only changed the scaffolding."

Neither of those undermines the actual lesson, which is the sentence I keep coming back to: most agent failures are configuration failures. That matches my experience almost exactly. When one of my agents goes wrong, it is nearly always a tool description that was vague, a rule that never got loaded, or a context window so full of noise that the one important line got buried. Swapping the model rarely fixes any of those.

Context engineering, or why your agent keeps forgetting things

The paper says the quality of AI generated code depends less on clever prompting than on the quality of the context you provide. I would go further. Nothing else on this list pays back as fast, and the paper moves past it quicker than it deserves.

The framing that helps most is splitting context into two piles by when it gets loaded.

Static context is the stuff that loads every time: your rule file, the persona, anything in global memory. It defines who the agent is. It is also expensive, because you pay for every token of it on every single interaction, including the ones where none of it matters.

Dynamic context loads on demand: a skill that fires when a task matches it, results that come back from a tool, documents pulled out of a search. You only pay when you actually need it.

Deciding what goes in which pile is a real design decision, not a config detail. Too much static and you are burning money while drowning the signal you care about. Too little and the agent forgets rules you thought you had set. The pattern the paper points at for the dynamic side is Agent Skills, where the agent sees a one line description of each capability up front and only loads the full instructions when something matches. That way it can carry thirty specialities and pay for one.

In practice, the thing that keeps my own rule files useful is deleting from them. Mine started at ten lines and grew every time an agent did something I did not want repeated. The discipline is pulling anything task specific back out of the always loaded pile, which is the same instinct as designing retrieval for a RAG system: the question is never how much you can fit, it is what earns its seat.

Two ways to work with agents

The paper describes two modes, and naming them properly is more useful than it sounds because most people slide between them without noticing.

Conductor is hands on. You are watching the code appear, correcting as you go, keeping tight control. This is the right mode for tricky logic, real debugging, and any codebase you do not know yet. It preserves your understanding, which is worth a lot. The catch is that your own attention becomes the ceiling on throughput.

Orchestrator is hands off. You define the work, hand it out, go do something else, and review what comes back. Agents may be running in parallel on different parts of the codebase. This fits well specified tasks: a known bug, a migration, generating a test suite, a feature that follows an established pattern.

Orchestrator mode asks for different skills than most of us built our careers on. Less syntax fluency, more of four things: writing a specification precise enough that nobody has to guess, breaking work into pieces the right size to hand off, judging output quickly, and designing the constraints and feedback loops that keep agents from wandering. That last one is really systems design wearing a new hat.

The 80% problem

This is the part I expect most readers will recognise immediately.

An agent will get you about 80% of a feature very fast. The remaining 20% is the edge cases, the error handling, the integration points and the subtle correctness requirements, and that part needs context the model does not have. So the time you saved on the first 80% goes into the last 20%, and sometimes more than you saved.

What makes this harder than it used to be is that the errors changed shape. Older tools produced syntax mistakes, which are loud and instant. Current models produce conceptual mistakes: a wrong assumption about your business logic, a missing edge case, a decision that quietly makes the next six months harder. These are worse precisely because the code looks right and often passes the obvious tests.

The posture the paper recommends is to point AI at what it is good at, which is implementing well specified things quickly, and to spend your own attention on what it is bad at: ambiguous requirements, architectural tradeoffs, and deciding whether the thing is actually correct. You do not get faster by accepting more. You get faster by putting your judgment where it counts.

What it costs, and where the cost hides

The economics section is short but it is the one I would put in front of a manager.

Vibe coding looks free. A subscription and some prompts, no setup. The cost shows up later in three places. You burn tokens prompting a model over and over to fix work it did not get right the first time. You pay a maintenance tax when someone has to reverse engineer unstructured code six months later. And you pay for security problems that a check would have caught before they shipped.

Agentic engineering inverts it. You spend real engineering time up front on schemas, test suites and context design, and then the cost of shipping each additional feature drops, because the agent is working inside something that catches its mistakes.

Two levers make the ongoing cost smaller. The first is context engineering, which is a financial decision as much as a technical one: a dense, well aimed payload gets the answer right the first time, and first pass success rate is what actually controls your bill. The second is model routing. Most teams pay frontier prices for everything, including asking a model to fix a typo. Send hard reasoning to the expensive model and mechanical work to a cheap one.

One caution on this section. The paper puts a specific multiple on the crossover, and Osmani has since said on his own site that the figure is illustrative rather than a measured constant. It is circulating on LinkedIn as though it were data. Trust the shape, not the number.

How each phase of the work changes

The paper walks the whole software lifecycle. Compressed:

• Requirements stop being a document that gets handed over. You can go from a description to something running in minutes, so the specification and a first implementation now happen in the same conversation.
• Architecture barely moves, and the paper is refreshingly blunt about why. Architectural calls are tradeoffs that depend on business context and constraints the model cannot see. AI is very good at implementing an architecture once you have decided it.
• Implementation shifts from writing to reviewing and directing. This is the phase that compressed hardest, and it is why the other phases now feel like the bottleneck.
• Testing gains a second dimension. You check the output, and you check the trajectory: the sequence of steps the agent actually took. A clean result that skipped its own verification is more dangerous than a visible failure.
• Review gets an AI first pass for the mechanical things, so humans arrive at the parts that need judgment with more attention left.
• Maintenance is the one the paper thinks is most underrated, and I agree. Code that was too risky to touch because only its author understood it can now be read, explained and modernised. Migrations that were never worth the risk become weekend work.

The mental model tying it together is what the paper calls the factory. Your output is no longer the code. It is the system that produces the code: the specs, the agents, the gates, the feedback loops. A factory manager does not assemble each unit by hand. They design the line and own the quality of what comes off it.

Where I would push back

I liked the paper. Three things I would not take at face value.

Treat the statistics as soft. The opening page says 85% of professional developers regularly use AI coding agents, 51% daily, and 41% of all new code is AI generated. I went looking for the sources. The 41% does not have one that survives contact; the best real measurement I could find is DX telemetry across 135,000 developers putting AI authored code at around 22 to 27% of merged code. The 85% is real but comes from JetBrains measuring AI tools generally; their number for coding assistants and agents specifically is 62%. The 51% daily figure checks out, from the Stack Overflow 2025 survey, and it also refers to AI tools rather than agents. None of this changes the argument. It does mean you should not quote those three numbers in a board deck.

The productivity picture is genuinely unsettled. The paper cites a METR study that found experienced developers took 19% longer with AI. That result was real, but METR has since marked it as no longer reflecting current models, and its 2026 follow up points toward a speedup while cautioning that its own new data is unreliable because developers now refuse to work without these tools. What did survive is the finding I think about most: those developers predicted AI would make them 24% faster, and afterwards still believed it had made them about 20% faster, while the measurement said they were slower. Nobody can feel their own throughput. Measure it.

"Review every line that ships" is not a real policy. The paper says it, and working engineers keep saying it does not survive contact with volume. Nikhil Verma put it well: nobody honestly reads every line they review, and pretending otherwise turns review into rubber stamping, which is worse than an honest sampling policy because it produces a false record of care. Sample by risk instead, and turn every defect you catch into an automated check so that class of bug cannot come back.

Worth knowing that the wider evidence is mixed in ways the paper does not dwell on. Google's own DORA research still finds AI adoption correlating with less stable delivery even as throughput improved. GitClear measured code duplication climbing 81% since 2023 while refactoring collapsed. And Veracode found 45% of AI generated samples introduced a known vulnerability class, with no improvement as models got better at writing working code. Fast is solved. Sound is not.

Also, fair warning: the last few chapters turn into a walkthrough of Google's own agent tooling. Useful if you are on Google Cloud, skippable otherwise.

If you only do five things

Stripping it to what I would actually act on:

Write the rule file before your next agent run. Ten lines. Stack, conventions, hard rules, workflow. Add one line every time you correct the same mistake twice. It is the cheapest thing on this list and the one most people skip.

Put your non negotiables in hooks, not in prose. Anything the agent must never do belongs in code that runs before a commit. A rule written in a prompt is a suggestion the model may or may not attend to. A hook is a constraint.

Write the tests before you generate the code. This is the paper's best single piece of advice. A test suite communicates what correct means far more precisely than any paragraph of instructions, and it keeps working while you are asleep.

Pick your mode deliberately. Conductor for unfamiliar or subtle work, orchestrator for well specified work against known patterns. Deciding on purpose beats drifting.

Watch your pull request size. If adopting agents doubled the size of your changes, you moved the bottleneck into review rather than removing it. Batch size is the number I would put on a dashboard before any productivity metric.

The paper closes on a line that I think is right: generation is solved, and verification, judgment and direction are the new craft. The tools got good enough that plausible output is basically free. Deciding whether it is correct is now most of the job. That is a better job than the one it replaced, but it is a different one, and the teams treating it as the same job with faster typing are the ones that will spend next year cleaning up. If you are working out where agents belong in your own stack, that is the question I would start from, and it is the one I spend most of my time on when I build these systems.

Frequently asked questions