Day 1 · Lesson 1 of the series

The Spectrum: One Dial, Not Two Camps

Vibe coding and agentic engineering are settings, not tribes.

You already build agents, so you don't need another definition of one. What's worth having is a reflex: for any task in front of you, you can say where it sits on a single dial, and name the one move that would shift it. That reflex is the spine the rest of the series hangs off.

The one idea

The founding paper of the series refuses the binary. Vibe coding and agentic engineering aren't two camps you pick a side in. They're the two endpoints of one dial you set per task.¹ Where the dial lands has nothing to do with whether you use AI (you always do now), or with how clever your prompt is. It comes down to one thing:

How much structure, verification, and judgment surround the output.

The biggest factor inside that is how outputs get verified. Two mechanisms do the work. Tests check the deterministic parts: this input, that output. Evals check the parts that aren't deterministic, like whether the agent took a sensible path, picked the right tools, and cleared the quality bar. Skip either one and you're vibe coding, however polished the prompt.¹

Dimension	Vibe coding	Structured AI-assisted	Agentic engineering
Intent	Casual prompts	Detailed prompts + examples	Specs, architecture, memory files
Verification	"Seems to work?"	Manual / spot-checks	Test suites, CI gates, LM judges
Error handling	Paste error back to AI	Human diagnoses, AI fixes	Agent self-diagnoses in bounds
Scope	Prototypes, scripts	Features in known codebases	Production, team-scale systems
Risk	High (disposable)	Moderate	Low (systematic checks)

Abridged from Day 1, Table 1.¹

What it actually looks like

Concepts stay slippery until you see the artifacts. So take one concrete task, "make our support agent handle refund questions," and watch it at three dial settings. The goal doesn't change and neither does the model. Only what surrounds the output changes.

(a) A rule/spec file. The policy becomes a written contract the agent loads (this is the harness, Lesson 2):

# AGENTS.md — Refund policy (hard rule)
- Eligible only if order < 30 days old AND item unused.
- Never *promise* a refund; say "you're eligible to request one".
- Outside policy: apologise, link the policy page, do not improvise.

(b) A test. It verifies the deterministic behaviour, checked by code on every run:

def test_refund_expired(agent):
    r = agent.ask("Refund please, I ordered 90 days ago")
    assert "policy" in r.lower()      # points to policy
    assert "refund" not in r.lower() or "eligible" not in r.lower()  # never promises

(c) An evalset + judge. This verifies the non-deterministic part (tone, whether it cited policy, whether it refused gracefully) using labelled cases scored by an LM judge against a rubric:

// refunds.evalset.json
[{ "input": "It's been 2 months, I want my money back",
   "expect": "Declines politely · cites 30-day rule · links policy · makes no promise" }]
// judge rubric (0-1): cites_policy? refuses_out_of_policy? tone_ok?

Then a CI gate wires them together so the discipline survives you:

# merge blocked unless BOTH hold:
pytest              # deterministic behaviour still passes
eval --min 0.9      # judged quality >= 0.9 on the refund evalset

Through your three lenses

The dial isn't only an IC concern. The closing of Day 1 reads the same idea at each level:²

The second hand: a governance layer

So the instrument has two needles. Build discipline runs left to right; governance maturity runs bottom to top. A task's real position is a coordinate on both, and the two move independently. That independence is the whole reason you have to read both:

Governance ↓ / Build →	Vibe	Structured	Agentic
L3 Controlled 🔒		ok	production-ready
L2 Observed 👁			tested, un-governed
L1 Unseen 👻	shadow agent		silent time-bomb

Bottom right is the real trap: a perfectly agentic-engineered agent that nobody knows is running. Great tests can't see that. Only the governance axis can.

Back to the refund agent. In ③ you made it agentic on the build axis (spec, tests, evals, CI gate). But before it touches a real customer's money, the governance axis wants more, and the VERDICT pillars name exactly what:

• I Identity — a named human owner, not an orphan in someone's repo.
• V Validation — a gate, so it cannot issue a refund over $X without approval.
• R Runtime Control — a kill-switch and a spend cap that halt it live, not at the next audit.
• E Evidence — immutable logs of every action and the reasoning behind it.

Miss these and your agent can be flawlessly tested and a Level-1 shadow agent at the same time. What moves a task up the governance axis is its own ladder: EXPOSE → BIND → ENFORCE → SELF-GOVERN. Discover it, give it an owner and gates, enforce them at runtime, then let it watch itself.

Check the reflex

Don't re-read the table. Recall it. Pick before you reveal.

Go deeper (primary source)

The clearest outside articulation of the disciplined end is Addy Osmani's essay. He co-authored Day 1 and coined a lot of this language: Addy Osmani, "Agentic Engineering." For the other end of the dial, Karpathy's original "vibe coding" post from February 2025 is two minutes well spent.

---

Notes

1. Osmani, Saboo & Kartakis, The New SDLC With Vibe Coding (Day 1), "The spectrum" pp.12–14.
2. Ibid., "Where to start" pp.43–45 and "Conclusion" pp.47–48.