Quick Answer
In May 2026, Google published a 51-page whitepaper called The New SDLC With Vibe Coding, authored by Addy Osmani (a Director at Google Cloud AI), Shubham Saboo, and Sokratis Kartakis. It argues that AI hasn't shortened the software development lifecycle, it has moved the bottleneck. Writing code is no longer the expensive part; specifying what "correct" means and verifying that the AI actually delivered it now is. The paper draws a spectrum from vibe coding (casual prompts, "does it seem to work?", fine for disposable prototypes) to agentic engineering (formal specs, automated evals, CI/CD gates, built for production systems), and the only thing that separates the two ends is how rigorously the output gets verified.
The Core Idea: It's a Spectrum, Not a Binary
The paper refuses to treat vibe coding and agentic engineering as two different tools or two different skill levels. They're endpoints of one practice, and your position on that line is set entirely by how much verification surrounds the AI's output. A developer can vibe code a throwaway script and practice disciplined agentic engineering on a production feature in the same afternoon, with the same underlying AI agent.
Three points on the spectrum, as the paper frames them:
- Vibe Coding: Casual, natural-language prompts. Verification is "does it seem to work?" High risk. Best for disposable scripts, prototypes, and proofs of concept.
- Structured AI-Assisted: Detailed prompts and structural outlines. Verification is manual spot-checking. Medium risk. Fits internal tooling and contained feature work.
- Agentic Engineering: Engineered, often machine-readable specifications. Verification runs through automated evals, CI/CD gates, and LLM judges. Low risk. Built for production-grade and enterprise systems.
The practical test the paper offers for figuring out where you actually sit: when the agent produces something wrong, what catches it? If the answer is "me, when I happen to notice," that's vibe coding regardless of how sophisticated your prompts sound.
Agent = Model + Harness
The paper's second major idea is an equation: an agent is a model plus a harness, and it puts the split at roughly 10% model, 90% harness. The harness is everything wrapped around the reasoning engine, instruction files, tool and MCP integrations, sandboxes, orchestration logic, guardrails, and observability.
The sharp conclusion that follows: most agent failures, examined honestly, are harness failures, not model failures. When an agent does something wrong, the instinct is to blame the underlying model. Usually the actual problem is a missing tool definition, a vague instruction file, or a context window cluttered with irrelevant noise.
There's a real benchmark result behind this claim. In February 2026, LangChain rebuilt the harness around a coding agent while holding the model completely fixed, and lifted its score on Terminal-Bench 2.0 from 52.8% to 66.5%, moving the agent from outside the top 30 to the top 5 on a public leaderboard, without touching the model at all. That's a genuine, single, well-documented experiment; independent reviewers have noted the whitepaper presents it in a way that could be misread as two separate results, when it's one team's one benchmark run.
How the Software Development Lifecycle Actually Changes
The paper keeps the traditional SDLC phases (requirements, architecture, implementation, testing, review, maintenance) but argues the time spent in each shifts unevenly:
| Phase | Before | With Agentic Engineering |
|---|---|---|
| Requirements | Handoff document | A conversation that produces a spec and a working prototype together |
| Architecture | Human-driven | Stays human-driven; trade-offs depend on business context the model doesn't hold |
| Implementation | Days to weeks | Minutes to hours |
| Testing | Manual review at the end | Automated evals and CI/CD gates running continuously; the test suite becomes how you communicate intent to the agent |
| Review | Human only | AI does a first pass; humans keep judgment on design and maintainability |
| Maintenance | Often avoided on risky legacy code | An agent that respects existing architecture can safely navigate and refactor code that was previously too risky to touch |
The mental model the paper uses: the developer's primary output stops being code and becomes the system that produces code, the specs, the agents, the quality gates, and the guardrails. You're designing the assembly line and auditing what comes off it, rather than assembling every piece by hand.
Reading the Paper's Numbers With Some Caution
The framework itself holds up well, but some of the whitepaper's supporting statistics are worth a second look before repeating them as fact. Its headline adoption figures trace back to marketing-statistics aggregators rather than primary research, even though stronger primary sources exist and say something similar: Stack Overflow's 2025 Developer Survey found just over half of professional developers use AI tools daily, and Google's own DORA 2025 report puts workplace AI adoption at roughly 90% of nearly 5,000 respondents. The paper's often-cited productivity range of 25-39% draws on vendor blog posts rather than controlled studies, and its claim that vibe coding costs three to ten times more per feature past a "crossover point" appears to illustrate a conceptual curve rather than measure an actual study. None of this undermines the core framework, but it's worth treating the specific percentages as directional rather than precise.
Why This Matters for Custom ERP and Manufacturing Software Work
This isn't just an abstract framework for app startups. It applies directly to the kind of work RAWN Technologies does: customizing Odoo and Openbravo modules, building the data pipelines and predictive models covered in our Data Engineer and AI/ML Engineer service lines, and delivering software a manufacturing client will run in production for years.
The paper's line about a CTO's reaction is worth sitting with: telling a client "we vibe coded your payment module" should raise alarms, while describing the same AI-assisted speed under test coverage, specs, and CI gates is a completely different, and much more defensible, conversation. For an ERP customization, a jewelry manufacturing cost engine, or an AI-deployed predictive maintenance system, that difference isn't academic, it's the difference between a system a client can trust in production and one that happens to have worked in a demo.
Frequently Asked Questions
Who wrote Google's "The New SDLC With Vibe Coding" whitepaper?
Addy Osmani, a Director at Google Cloud AI, together with Shubham Saboo and Sokratis Kartakis. It was published on Kaggle in May 2026 and taught as part of a free five-day Google AI Agents course.
What's the actual difference between vibe coding and agentic engineering?
Not the tools, the AI models and even the prompts can be identical. The difference is verification: vibe coding checks only whether the output "seems to work," while agentic engineering runs the output through formal specs, automated evals, and CI/CD gates before it ships.
What does "Agent = Model + Harness" mean in practice?
It means most of an AI agent's real-world performance comes from the surrounding system, instructions, tools, guardrails, and context, rather than from the underlying model itself. The paper estimates this split at roughly 90% harness, 10% model.
Is vibe coding always a bad practice?
No. The paper is explicit that vibe coding is the right speed for prototypes, throwaway scripts, and early exploration. The risk is letting vibe-coded work drift into production without ever moving to the verification rigor agentic engineering requires.
Building custom software on top of Odoo or Openbravo, or deploying AI/ML systems that need to run reliably in production? Contact RAWN Technologies to talk through your project.