Google's Vibe Coding Whitepaper, Explained in Plain English

Google published a 51 page whitepaper about how AI is changing the way software gets built in the week of June 15, 2026. It is called The New SDLC With Vibe Coding, it is free on Kaggle, and Google released it as Day 1 reading for a five day course. The page footers inside the PDF say May 2026, but one of its three authors, Addy Osmani, wrote on his own site on June 16, 2026 that Google had published it that week. 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. I rechecked what I say about the paper against the PDF itself in October 2026.

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, live from June 15 to 19, 2026. The PDF runs 51 pages, and the PDF file behind the Kaggle page was generated on June 18, 2026, so I cannot give you an exact first upload day. The course has finished but the material is still up and still free as a self paced guide, 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 on February 2, 2025 (see my glossary entry on vibe coding for the short definition). 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 what it lands on is the useful part. Its comparison table lists a developer who "may not read the generated code" as the vibe coding row, and its test is verification: without both tests and evals, it says, the practice is always vibe coding, however sophisticated the prompts are. My shorthand for that is vibe coding means you are not reading the code. Not how casual your prompt was, not whether you used an agent. If you shipped something you did not read or check, 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 on February 4, 2026 Karpathy said agentic engineering was his current favourite of the options going around. Willison added an update to his own post on February 23, 2026 saying that agentic engineering was coming out on top. That is the name that stuck, and the paper itself uses it as the other end of its spectrum. I keep a short entry on it in my glossary: agentic engineering.

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, the paper's table puts verification at "does it seem to work?" In the middle, a human does manual testing and selective review of the critical paths. On the right, there are automated test suites, CI and CD gates and LM judges 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. The paper's own example for the right is a production API handling financial transactions, and I would put anything touching customer data there too. 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. The paper's Figure 7 even puts a rough split on it, about 10% model and 90% harness, though that is a diagram legend rather than a measurement. When people say Claude Code and Cursor and Codex "feel different", the paper's claim is that the behaviour you experience is dominated by what the harness does, not just by which model sits underneath.

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 LangChain says moved it from outside the top 30 into the top 5 in February 2026. Same model (GPT-5.2-Codex), 13.7 points. The paper lists "one team" moving into the top 5 and a "separate study at LangChain" adding 13.7 points as two examples, but LangChain's own post describes one experiment that produced both numbers. You can read the full writeup from February 17, 2026, and it is worth it because the details are more instructive than the headline.

Two honest footnotes on that number. It is a snapshot: as of October 2026 tbench.ai leads with Terminal Bench 4.0, so I would not quote that February ranking as current. And not everything LangChain changed was a prompt or a tool. It also tuned how much reasoning compute the model spends: running the highest setting everywhere scored 53.9% because of timeouts against 63.6% at the high setting, and its final setup, which spends the most reasoning on planning and verification, reached the 66.5%. That sits a little awkwardly next to the claim that only the scaffolding changed.

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 dozens of 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. If you want the memory side of that split in more depth, I wrote up how agent memory works in production.

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 engineers built their 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. A vibe coding workflow tends to run one frontier model for everything, including asking it to fix a typo. The paper's answer is to send requirements, architecture and the first implementation to the big model and test generation, code review and CI monitoring to a smaller, cheaper one. I wrote about the routing options in my post on LLM routers for AI agents.

One caution on this section. The paper's Figure 9 puts a specific multiple on the crossover: past that point, vibe coding costs 3 to 10 times more per feature. Osmani wrote on his own site on June 16, 2026 that this figure is illustrative, not a measured constant. 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. The paper says migrations and API updates that were so tedious and risky they never happened can now be done.

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.

What has changed since the paper came out

Everything below is as of October 2026, from the sources named. The paper itself says its phase by phase picture reflects mid 2026 and "may look different in 12 months," so it is worth checking where the numbers have moved.

Agent usage went up quickly. A Stack Overflow pulse survey fielded in late April 2026 with about 1,100 respondents found that 59% use AI agents at work, against 31% in its 2025 survey. It also found that 68% prefer single agent setups over multi agent ones and that 60% block agents from making unapproved system changes. The full 2026 Developer Survey, published on October 6, 2026 with more than 30,000 respondents, says 73% of those who use AI coding assistants or agents use them daily, that Claude Code (66%) and GitHub Copilot (59%) are the agents of choice, and that the main uses are generating code in familiar areas (67%) and debugging (61%), against only 20% for deploying, operating or troubleshooting production systems.

AI written code passed half of merged code, and pull requests grew by about two thirds. DX's self reported figure, from developers at roughly 400 to 500 organisations, was 22% of merged code in Q4 2025. Its final Q2 2026 report puts it at 52%, up from 34% in Q1 (an earlier Q1 preview said 27.4% on a different cohort). Over the same cohort, DX's telemetry shows median pull request size going from 44 to 72 lines between July 2025 and June 2026, a rise of about 64%. DX calls that "nearly doubled"; by my arithmetic it is closer to two thirds. Either way, that is the review problem the paper hands off to its Day 5 companion paper.

Generated code is no safer. Veracode's 2026 GenAI Code Security Report, published July 28, 2026, puts the average security pass rate at 56%, virtually unchanged from last year, with models failing about 44% of tasks while compiling at close to 100%. Its models ran without security specific prompting and without the agent harness the paper describes, so read it as the floor a harness has to lift, not as a score for agentic engineering.

The tooling the paper leans on is moving. The paper's Agents CLI is a real package: PyPI lists google-agents-cli at version 1.10.0, uploaded October 12, 2026, with a first release on April 21, 2026. The other four course papers cover agent tools and interoperability, agent skills, security and evaluation, and spec driven production development, and Osmani has kept writing about the same ideas on his blog, including a September 14, 2026 post on brownfield agentic engineering.

Where I would push back

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

Treat the statistics as soft. The introduction 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 paper's endnote for all three numbers points to two blog roundups, GetPanto and Index.dev, rather than to a survey. The 41% has no measurement behind it that I could find. The best real measurement I found was DX's Q4 2025 report across 135,000 developers, which put AI authored code at 22% of merged code. DX's later self reported readings, in the section above, were 34% in Q1 2026 and 52% in Q2, so 41% does not match any single DX reading. The 85% is real but comes from JetBrains measuring AI tools generally; their number for relying on at least one AI coding assistant, agent or code editor 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 on certain tasks with AI. That result was real, but it used data from February to June 2025. METR's February 24, 2026 follow up says it believes developers are likely more sped up now, shows raw results with some evidence for a speedup, and also says its new data is only very weak evidence because more developers refuse to work without AI tools. The paper's endnotes list that follow up, but its text only gives the 19%. What did survive is the finding I think about most: in the original study, developers expected AI to make them 24% faster, and afterwards still believed it had made them 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 in its advice for individual developers: review every line the agent produces that is going to ship. Working engineers keep saying it does not survive contact with volume. Nikhil Verma, in a July 14, 2026 essay that agrees with most of the paper, argues that no human honestly reads every line they review, that engineers have always sampled, and that guardrails such as static analysis, linters, type checkers and tests shrink the tier of code where you read everything. 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 2025 DORA research finds AI adoption correlating with better delivery throughput but still with worse delivery stability. GitClear's 2025 analysis of 2024 code changes, as reported by DevClass, found a 39.9% drop in moved lines, the signature of refactoring, and 2024 was the first year copied lines outnumbered moved ones. And Veracode's 2025 report found 45% of AI generated code samples failed security tests, with no improvement as models got better at writing working code; its 2026 report, covered above, still shows about 44%. Fast is solved. Sound is not.

Also, fair warning: pages 36 to 39, the section on vibe coding production ready agents, turn into a walkthrough of Google's own Agents CLI and Agent Development Kit. 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. The paper says to start with ten lines: stack, conventions, hard rules, workflow. Add a rule every time the agent does something it should not do again. 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. DX's telemetry found median pull request size rising from 44 to 72 lines between July 2025 and June 2026, so this is already happening at scale.

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

What is vibe coding?

Letting an AI write code that you do not read. Andrej Karpathy coined the phrase in February 2025, describing accepting every suggestion, never looking at the diffs, and pasting errors back at the model until it worked. He was talking about throwaway weekend projects. The defining characteristic is the absence of review, not how casual your prompt was or whether you used an agent.

What is agentic engineering?

The disciplined end of the same spectrum. AI still does the implementation, but inside a structure a human designed: specifications, tests, evaluations, guardrails and review of the parts that matter. The name came out of a long community argument. Simon Willison proposed "vibe engineering" for it in October 2025, and Karpathy said on February 4, 2026 that agentic engineering was his current favourite option, and Willison later noted it was coming out on top.

What is the actual difference between them?

Verification. The paper is explicit that it is not about which tool you use, because the same agent supports both. Two developers running identical software can sit at opposite ends of the spectrum. What separates them is whether anything checks the output before it ships, and what that checking consists of.

What is a harness in AI coding?

Everything wrapped around the model that turns it into a working agent: rule files, tool definitions, the sandbox code runs in, orchestration between sub agents, hooks that fire automatically at fixed points, and logging. The paper's formula is Agent equals Model plus Harness, and its practical claim is that most agent failures trace back to a missing tool, a vague rule or a noisy context window rather than to the model itself.

What is context engineering?

Deciding what information your agent has and when it gets it. The useful split is static context, which loads on every single turn and therefore costs you on every interaction, against dynamic context, which is fetched only when a task needs it. Rule files and persona are static. Skills, tool results and retrieved documents are dynamic. Getting the boundary wrong either burns money and buries your signal, or leaves the agent forgetting rules you thought you had set.

What is the 80% problem?

An agent gets you roughly 80% of a feature quickly, and the last 20% takes disproportionately long because edge cases, error handling and integration points need context the model does not have. It is harder than it used to be because AI errors have shifted from syntax mistakes, which are obvious, to conceptual ones like a wrong assumption about your business logic, which look correct and often pass basic tests.

Where can I read the whitepaper, and is it free?

Yes, free and no signup needed. It is on Kaggle as The New SDLC With Vibe Coding, 51 pages, by Addy Osmani, Shubham Saboo and Sokratis Kartakis. Google released it in the week of June 15, 2026, although the page footers say May 2026. It was Day 1 of a five day course that ran live from June 15 to 19, 2026, and the other four papers, the podcasts and the codelabs are still available through the course guide. The course itself has ended but everything is self paced now.

Is it worth reading, and who is it for?

Worth reading if you are an engineer, lead or founder deciding how agents fit into how your team works. Read the harness and context engineering sections first, since those are the most immediately useful. Treat the statistics as approximate, and feel free to skip pages 36 to 39 unless you are on Google Cloud, because they turn into a product walkthrough. If you want the same ideas argued more sharply, Addy Osmani's own site is where much of this material started, including his June 16, 2026 post The New Software Lifecycle.