Stop Blaming the Model

Google published "The New SDLC with Vibe Coding" this month. 51 pages. Three authors. Lots of diagrams. It is the most thorough description of where AI-assisted development is in mid-2026 that I have read.

Most of it I already believed. Some of it I already wrote about. A few things made me re-evaluate my own setup.

This is what I took from it and what I am changing.

The idea that matters most

Here is the paragraph I keep coming back to:

When an agent does something wrong, the first instinct is to blame the model. More often, the failure traces back to a missing tool, a vague rule, an absent guardrail, or a context window stuffed with noise. Most agent failures, examined honestly, are configuration failures.

The paper calls this the harness model. Agent = Model + Harness. The harness is everything around the model: the system prompts, the tools, the sandboxes, the hooks, the observability, the sub-agent routing, the guardrails. The model is one input. The harness is the system.

The numbers back this up. On Terminal Bench 2.0, one team moved their agent from outside the Top 30 to the Top 5 by changing only the harness. Same model. LangChain raised their score by 13.7 points tweaking only the system prompt, tools, and middleware around a fixed model.

When my agent does something stupid, I used to curse the model. Now I look at the harness first. Did I give it the right tools? Is the AGENTS.md file precise enough? Are there guardrails catching the failure mode before it compounds? Nine times out of ten, the answer is no, and the fix is a configuration change, not a model swap.

I wrote about this pattern before in Software Factory: Build Factories, Not Features when I said the developer's primary output is not code but the system that produces code. The paper gives this idea a name and a framework. The harness is the factory. The model is the machine on the factory floor. A machine without belts, sensors, and quality control is just a very expensive paperweight.

Context engineering is the real job

The paper traces the shift from prompt engineering to context engineering. I have felt this shift in my own workflow over the last year. Early 2025 I was obsessing over prompt phrasing. How do I word this instruction to make the model behave? By early 2026 I was obsessing over context structure. What does the agent need to know before it starts? What should be in static context (always loaded) and what should be dynamic (loaded on demand)?

The paper defines six types of context every agent needs: instructions, knowledge, memory, examples, tools, and guardrails. The design decision of what goes where is a genuine engineering trade-off.

Too much static context wastes tokens and dilutes signal. Too little means the agent forgets critical rules. The paper calls this boundary a first-class architectural decision, reviewed and versioned like any other configuration. That is the right framing.

I have been using Agent Skills on this site to manage this trade-off. Skills are structured, portable packages of procedural knowledge that load only when the task calls for them. The agent stays a lightweight generalist that flexes into specialist roles on demand. The paper validates this pattern and gives it a vocabulary. That is useful when I am explaining it to other people.

The spectrum is real, the terms are not

The paper spends a lot of time defining the spectrum from vibe coding to agentic engineering. I agree with the spectrum. I think the labels are already stale.

Karpathy coined "vibe coding" in February 2025. By early 2026 he was already using "agentic engineering" for the disciplined end. The paper treats "vibe coding" as a serious category but the term has become a strawman. Nobody who ships production code describes their workflow as vibe coding. The people who do pure vibe coding are building prototypes and scripts. They are not reading 51-page whitepapers.

What matters is not the label. It is the dimension the spectrum measures: how much structure, verification, and human judgment surrounds the AI output. The paper's spectrum table is the most useful part of this section. It compares intent specification, verification, codebase understanding, error handling, appropriate scope, and risk profile across the range. That is a diagnostic tool, not a label. I will use it that way.

The 80% problem needs more attention

The paper mentions the 80% problem: AI gets about 80% of a feature right quickly, but the remaining 20% requires deep contextual knowledge the model does not have. The errors shift from syntax mistakes to conceptual failures. Wrong assumptions about business logic. Missing edge cases. Architectural decisions that look right but create long-term maintenance burdens.

This maps to my experience exactly. The fastest way to produce bad code with an AI agent is to accept the first output. The most productive pattern is to treat the agent output as a first draft and apply your own expertise to the parts that matter.

The paper says the developers who navigate this best "use AI for what it is good at while reserving their own attention for what it struggles with." That is the right posture. But the paper does not spend enough time on what that looks like in practice. How do you develop the taste to know which 20% needs your attention? What does a good review of AI-generated code look like? When do you trust the agent and when do you override it?

I covered some of this in my breakdown of Simon Willison's agentic engineering guide. The anti-pattern that matters most is the same in both documents: inflicting unreviewed code on collaborators. If you open a PR with hundreds of lines you have not read, you are delegating the review to someone else. You are providing negative value.

Conductor and orchestrator

The paper distinguishes two modes of working with AI: conductor and orchestrator.

In conductor mode, you work in real-time with the agent, watching code appear, guiding it with prompts and corrections. This is what most people do with Cursor, Copilot, or Claude Code in interactive mode.

In orchestrator mode, you define goals, assign them to agents, and review results asynchronously. Agents work in the background, in parallel, on different parts of the codebase. You check in periodically.

I use both modes every day, and the paper helped me see something I was doing wrong. I was trying to orchestrate tasks that needed conduction. When a task involves complex logic, unfamiliar code, or ambiguous requirements, conductor mode is faster because you can course-correct in real time. When a task is well-specified with clear acceptance criteria, orchestrator mode is better because you parallelise the work and stay out of the agent's way.

I was treating all tasks as orchestration problems because orchestrator mode feels more advanced. That was a mistake. The skill is not picking one mode. It is knowing which mode fits the task and switching fluidly.

What I am changing

The paper confirmed some things I was already doing and exposed one gap I am closing.

Keep doing: treating the harness as the product. My AGENTS.md file, my skill files, my quality gates, my review checklists. These are the assets that compound across projects. Every hour spent improving the harness pays back faster than every hour spent hand-holding an agent through a task it should be able to do itself.

Keep doing: static versus dynamic context separation. Skills on disk, loaded on demand. This pattern works.

New: I am adding an explicit harness review to my workflow. Before I start a new project or feature, I will audit the harness the agent will operate inside. What tools are available? What guardrails exist? What happens when the first attempt fails? If the harness is not ready, the agent should not start.

New: I am writing a context debugging guide for myself. When the agent fails, I want a checklist to trace the failure to its source. Model limitation or harness gap? The paper's framing gives me the categories for that checklist. Instructions, tools, memory, examples, guardrails. Which one was missing or wrong?

New: I am being more explicit about conductor versus orchestrator mode in my task planning. If a task needs conductor mode, I schedule it for focused time. If it can be orchestrated, I write the spec and delegate. No more defaulting to one mode for everything.

The bottom line

The paper is worth reading. It is too long, too Google-centric, and too invested in the vibe coding label. But the core ideas are solid.

The model is not the agent. The harness is the agent. When something breaks, look at the harness first. Most agent failures are configuration failures. The teams that compound the most value from AI are the ones that build their harness once and refine it many times.

The paper's closing line is the best one: "Generation is solved. Verification, judgment, and direction are the new craft." I will be thinking about that for a while.