What Google's New SDLC Paper Leaves to the Buyer
Google says the harness is yours. It does not say who builds it.
In its May 2026 whitepaper, The New SDLC With Vibe Coding, Addy Osmani, Shubham Saboo and Sokratis Kartakis define an agent as a model plus its harness. The harness includes instructions, tools, context policies, sandboxes, orchestration, hooks and observability.
Then comes the paper’s strongest line: “If that sounds like a lot of surface area, it is. And it is the team’s surface area, not the model provider’s.”
An AI model vendor is saying this about its own product. It is correct. It is also handing the buyer an invoice that the paper never itemizes.
The model is no longer the system
The paper separates AI-assisted development into three bands: Vibe Coding, Structured AI-Assisted Coding and Agentic Engineering. What separates them is how much structure, verification and human judgment surrounds the output.
That distinction matters because most production decisions sit in the middle. Detailed prompts, constraints, manual testing and selective review can support moderate risk. They do not constitute an agentic SDLC.
The paper then replaces the image of a developer writing code with a factory. The developer defines specifications, designs guardrails, and reviews results. Agents plan and code. Tests and verification return failures to the planning agent.
This is the right system boundary. Generated code is an intermediate product. The engineering asset is the system that produces and checks it.
The paper frames the model as roughly ten percent of the agent and the harness as roughly ninety percent. That split is a framing, not a measurement. The measured results underneath it carry more weight.
On Terminal Bench 2.0, a team moved a coding agent from outside the top 30 into the top five without changing the model. They changed only the harness. A separate LangChain study raised the same agent’s score by 13.7 points through changes to the system prompt, tools and middleware around a fixed model.
The paper also distinguishes the Conductor from the Orchestrator. The Conductor works with an agent inside the IDE and controls the steps. The Orchestrator delegates a goal and evaluates the result.
Orchestration requires specification, decomposition, evaluation and system design. Those are operating responsibilities, not features inside a model subscription.
The paper stops before the operating model
The whitepaper tells engineering leaders to treat harness components as a shared team asset. Reusable prompts, skill libraries, MCP connections and evaluation harnesses should be built once and refined many times.
A buyer will read that as “build it in-house.” That reading is faithful to the paper. The question is what the instruction commits the organization to.
A shared asset needs funding before it compounds. The first pass must be designed against a codebase, domain and team. The paper does not say who funds that pass or the dead ends that precede a useful system.
The factory also needs staffing. Someone must write the specification. Someone must own the tests and evaluations. Someone must define agent boundaries, approve tools, maintain guardrails and decide when a guardrail has become obsolete.
The person approving scope changes too. When execution accelerates, approval sets the pace. A factory that waits for product decisions is not autonomous in any useful delivery sense.
Cadence remains unspecified. A system can generate and verify work without defining when it reaches production. Release frequency must match the client’s ability to review, accept and absorb change.
These omissions do not undermine the paper’s model. They define the work left to the buyer.
Do not build a harness
“Build a harness” is the wrong unit of work. A harness is a category for everything around a model. It cannot be assigned, finished or inspected at the end of a week.
The first useful unit is a role-based teammate. Each teammate has one job, an ownership boundary, prohibited actions, measures and a named reviewer. A teammate that converts acceptance criteria into executable tests is distinct from one that checks a diff for architectural drift.
The second unit is a slice of workflow automated from start to finish. Partial automation preserves the labor and adds supervision. The organization pays for both.
The owner of these units is the RACE Engineer. DevOps automated the path from commit to production. The RACE Engineer automates the path from intent to commit, installs that machinery in the project environment, and qualifies the people working beside it.
This role owns an asset with a horizon measured in years. The asset changes as models, harnesses and team capability change. Yesterday’s necessary guardrail can become tomorrow’s waste.
RACE Programming answers the operating questions the paper leaves open. It assigns product intent, backlog preparation and workflow automation to named roles, encodes specifications and guardrails as versioned assets, and ties the work to a release cadence that ends in production.
This is convergence, not endorsement. Google does not know RACE Programming exists. Its whitepaper identifies the same boundary: the model is one input, while the team owns the production system around it.
Fund the harness as an engineering asset. Define its work as role-based teammates and end-to-end workflow slices. Arguments against that, or questions about who carries your first pass, go to hello@raceprogramming.com.
Written by Pavel Khodalev, author of RACE Programming and CTO of First Line Software. Follow new essays via RSS.