"Vibe coding" became an insult faster than it became a word. Say it out loud in a serious engineering meeting and you're admitting you shipped something you don't fully understand. But that framing hides a more useful question: not whether you used AI to write the code, but how much structure surrounds what it produced.
Google published a whitepaper in May 2026 — "The New SDLC With Vibe Coding" (Osmani, Saboo, Kartakis) — that gives this question real vocabulary. I spent a session running it against my own setup. Some of it confirmed what I already believed. Some of it pointed straight at a gap I'd been ignoring.
The Spectrum, Not a Binary
The whitepaper's core move is refusing the binary. Vibe coding and agentic engineering aren't two different activities — they're two ends of one spectrum, and the variable isn't whether AI wrote the code. It's how much structure, verification, and human judgment surrounds the output.
That reframes the question you should actually be asking. Not "did I vibe code this?" but "does my position on the spectrum match what's actually at stake here?" A weekend prototype and a payments migration have wildly different correct answers, and neither one is shameful at its own end of the spectrum.
The One Differentiator: Verification
Strip away the vocabulary and one thing actually separates the two ends: verification. Not prompt sophistication, not how impressive the output looks — whether there are tests (deterministic, mechanical checks) and evals (trajectory and quality checks, often judged by another model). Without both, it's vibe coding, no matter how elaborate the prompt was.
Harness = Model + Harness
The line I keep coming back to: the model is the engine, but the harness — the prompts, rule files, tools, sandboxes, orchestration logic, hooks, guardrails, and observability wrapped around it — is what determines whether the engine goes anywhere useful.
One request, through the harness
The model is one box in that chain. Every failure the whitepaper calls a "configuration failure" happens in one of the other five.
The whitepaper puts it bluntly: most agent failures are configuration failures. Not a weaker model. A missing tool, a vague rule, an absent guardrail, a context window drowning in noise. When an agent does something dumb, the first question shouldn't be "is this model good enough" — it should be "what did I fail to give it."
Conductor vs. Orchestrator
Two modes of directing agent work, and they're not a maturity ladder — the same person moves between both, often in the same afternoon.
| Conductor | Orchestrator |
|---|---|
| Real-time, in-IDE, fine-grained direction | Async, define-goal / assign / review |
| Complex logic, unfamiliar code, live debugging | Well-defined bugs, migrations, test generation |
| One agent, tight feedback loop | Multi-agent delegation, reviewed on return |
The 80% Problem
Agents nail roughly 80% of a feature fast — often deceptively fast. The remaining 20% is edge cases, integration seams, and the kind of subtle correctness that needs contextual judgment models don't have. The trap isn't that this 20% is hard. It's that failures in it look right, pass the basic tests, and hide anyway — until they don't.
The Economics
Vibe coding is low CapEx, high OpEx: little upfront investment, but the bill arrives later as token burn from retry loops, a maintenance tax on unstructured output, and security remediation. Agentic engineering inverts it — you pay upfront in specs, test suites, and context structure, and the operating cost drops.
Context engineering is the financial lever on that second side of the trade — and it splits into six types worth naming individually: instructions, guardrails, knowledge, examples, tools, and memory. The static ones (instructions, guardrails) load every time; the dynamic ones (tools, memory) load on demand. Agent Skills are the mechanism for that progressive disclosure — load only what the current task needs, not the entire library up front.
Running It Against My Own Harness
Frameworks are only useful if they survive contact with your actual setup. So I built the table on myself:
| Harness Layer | Status |
|---|---|
| Instructions / rule files | In place |
| Tools | In place |
| Sandboxes | In place |
| Orchestration logic | In place |
| Guardrails / hooks | In place |
| Observability | Gap — no formal cost, latency, or drift tracing |
Five out of six layers were genuinely there. The sixth — observability — was the one I'd been quietly skipping, doing ad hoc review instead of building a real trace. It didn't show up until I forced myself to fill in every row instead of the rows I was already confident about.
The Actual Exercise
The value of this framework isn't the vocabulary itself — it's that it gives you a checklist specific enough to fail on. Try the same table on your own setup. Not "do I use AI to code" — every row: instructions, tools, sandboxes, orchestration, guardrails, observability. The gap you find is usually the same one you've been quietly working around for months.