In this video, Cole Medin breaks down a newly released 51-page Google masterclass on AI coding, which he calls "the cleanest packaging I've seen for everything that the industry is converging on" in terms of best practices and terminology. Rather than have viewers read the whole article, Cole reorders and condenses its core ideas into a single diagram, explaining the AI-driven software development lifecycle (SDLC), the spectrum from vibe coding to agentic engineering, the central role of the harness, context management, and token economics.
The SDLC (software development lifecycle) is the full process of going from idea to production: requirement gathering, design, implementation, testing, review, deployment, and maintenance. It is far more than just writing the code in the middle.
This is why you hear that AI coding assistants 10x an engineer's output but not the output of the business: software engineering is bottlenecked by the parts that haven't been automated. Cole predicts many of the next billion-dollar companies will be platforms that speed up requirements gathering and validation, since the middle is largely solved.
Google frames AI coding as a spectrum, not a switch. Most people treat it as binary, but it is a continuum based on how evolved your system is:
Important nuance: the spectrum is not about how much you write by hand versus trust the agent. Even in agentic engineering you delegate all of the coding to the agent. The spectrum measures how evolved your system is, not how much you type yourself. Vibe coding still has a legitimate place; agentic engineering is simply where you want to be most of the time because it produces reliable code.
The harness is the set of context, rules, and workflows you bring into the AI coding assistant. It is the layer you control. Google's central claim: the large language model is only about 10% of the system. The other roughly 90% is everything you engineer around it:
Cole notes this aligns exactly with Anthropic's Claude Code best-practices article, whose headline is "the harness matters as much as the model." Google (and Cole) push it further: the harness matters more than the model. The model is the brain and reasoning, but it is the one thing you do not control. The harness is what you build for your specific codebases, architectures, and tech stacks.
The Claude Code primitives that make up the harness for any AI coding assistant: global rules, hooks, skills, code-search methods, MCP servers, and subagents. As Google puts it, "the agent is the model plus the harness."
With harness engineering, Google introduces the idea of the factory. Instead of an engineer writing code or a PM writing the PRD by hand, you are responsible for designing the system (the harness), and the agent produces the code and documentation. This is a bigger upfront investment than vibe coding, but it yields a repeatable loop:
Split planning and coding into two separate sessions. The planning agent builds up a lot of context and bias; you avoid context rot by taking only the plan artifact forward into a fresh coding session.
Keep a human in the loop. If you never review the output yourself, you fall back toward vibe coding. For agentic engineering, generally a human should review the final pull request before it is marked as passing.
Just as you evolve your codebase, you evolve your system. Cole calls this the system evolution mindset: whenever the agent has to iterate more than you would want, or you have to step in before shipping, don't just fix the bug and move on. Have the agent do a retrospection and ask where the workflows, rules, or any part of the AI layer could be improved so the issue is less likely to recur. Each pass makes the system more reliable.
The harness is worth the investment because it really is the 90%. Cole cites benchmark studies (e.g., Terminal Bench 2.0) where a model outside the top 30 was lifted into the top 5 purely by adding an AI layer of rules and workflows. LangChain reportedly raised a score by 13.7 points, roughly the gap between Sonnet and Opus, meaning a good harness can make Sonnet perform like Opus.
Context is your most precious resource, both for cost and for avoiding context rot (LLMs get overwhelmed by too much information, just like people). Google distinguishes:
Skills let the agent "remain a lightweight generalist that flexes into specialist roles on demand through progressive disclosure." The underlying lesson: you really only need one agent, made specialized through skills (workflows). The industry is moving away from complicated multi-agent systems and large piles of specialized subagents. A single generalist session can become a code reviewer or a planner thanks to dynamic context. Keep it simple.
Google describes two modes the engineer moves between:
Google argues you should move between both modes. Cole partly disagrees: he believes that once your harness is reliable and you trust your rules and workflows, you can largely live in orchestrator mode and "graduate" from being the conductor. He concedes there's a time and place for granular conductor work (deep debugging, initial exploration) and that the conductor/orchestrator model is a useful mental model for traditional engineering organizations just adopting agentic engineering, until their system matures.
Cole praises Google's CapEx vs. OpEx framing:
The crossover point is reached very quickly. Agentic engineering can become roughly three to ten times more reliable and cheaper than vibe coding because you stop burning tokens on rework.