Day 1 · Lesson 5 of the series

Conductor & Orchestrator: Two Modes, and the 80% That Decides

When to hold the baton, when to walk away, and the 20% that bites.

The last four lessons were about the system. This one is about you: how your role splits as agents take the implementation, and the single problem (the last 20%) that tells you, task by task, which hat to wear.

Recall first (spacing — answer before reading on)

From Lesson 1: what catches a non-deterministic, "looks-right" failure?

A quick manual glance
A bigger frontier model
Evals with a rubric

Evals, tests only catch deterministic breaks. Hold that: the 80% problem below is exactly a swarm of "looks-right" failures, and evals are what see them.

Two modes you move between

As AI takes more of the implementation, the developer works in two modes, fluidly, switching many times a day.¹ They are not personality types; they are settings you choose per task (like the dial in Lesson 1).

—	Conductor	Orchestrator
Posture	Hands-on, real-time	Async, higher abstraction
You are	In the IDE, watching code appear	Setting goals, reviewing results
Agents	One pair-programmer, live	Several, in the background, parallel
Fits	Complex logic, debugging, unfamiliar code	Well-specified tasks: fixes, migrations, tests
Tools	Copilot, Cursor, Gemini Code Assist	Jules, Claude Code, background agents

Conductor mode preserves the sense of understanding and control engineers value, but if you personally direct every keystroke, you become the bottleneck and the throughput gain evaporates. Orchestrator mode lifts that ceiling, but demands a different skill set:¹

SPECIFICATION   define a task precisely enough to run without you
DECOMPOSITION   break large work into agent-sized units
EVALUATION      judge output quality fast (← Lesson 1's evals)
SYSTEM DESIGN   build the constraints + feedback loops (← Lessons 2-3)

Notice those last two are the harness and the factory. Orchestration is what becomes possible once you've built the system the earlier lessons describe, not a personality trait.

The 80% problem — the thing that decides

Here is the crux that tells you which mode a task needs. Agents rapidly generate ~80% of a feature; the remaining 20% (edge cases, error handling, integration points, subtle correctness) needs deep contextual knowledge current models often lack.²

Why the 20% is the dangerous part

The nature of AI errors has evolved from syntax mistakes to insidious conceptual failures: wrong assumptions about business logic, not seeking clarification on ambiguous requirements, missing edge cases, architecture that creates slow long-term maintenance debt. These are hard to catch precisely because the code "looks right" and may even pass basic tests.² That's the same "looks-right" failure class from the recall above, which is why evals, not a glance, are what guard the 20%.

So the posture that works: use AI for what it's good at (rapid implementation of well-specified tasks) and reserve your attention for what it struggles with (ambiguous requirements, architectural trade-offs, correctness verification). You don't get faster by accepting everything the agent produces doesn't make you faster. Aiming your expertise where it matters does.² Put simply:

ORCHESTRATE the 80%   — well-specified, gated, safe to walk away from
CONDUCT     the 20%   — ambiguous, architectural, needs your judgment live

Linkage: this is where Lessons 1–4 pay off

You can only safely orchestrate, hand a task to a background agent and leave, if the factory catches the 20%'s failures without you watching. Orchestration is not a braver attitude; it is what the harness (gates, hooks) and the factory (eval gates, feedback loops) earn you. No gates → every task needs conducting, because you are the only thing catching the 20%.

The governance layer, on the two modes

Governance overlay · Lesson 5

When you walk away, governance has to replace you

In conductor mode you are the live control: your eyes are the observability, your hand is the kill-switch. The moment you shift to orchestrator mode, async, parallel, in the background, you've removed the human from the loop, so VERDICT's runtime pillars must take your place: R Runtime Control (a real kill-switch), E Evidence (traces of what ran while you weren't looking), I Identity (who owns each background agent).

Ladder read: orchestrating a fleet of background agents with no observability or kill-switch is the fastest route to L1 Unseen — the exact "12 unregistered agents nobody knew about" story. The more you orchestrate, the higher up the governance ladder you must climb just to stay safe. Autonomy and governance rise together, or you are breeding shadow agents.

Through your three lenses

Individual (IC)

Sort each task before you start: is this the 80% (well-specified, orchestrate it) or the 20% (ambiguous or architectural, conduct it live)? Sharpen the orchestrator skills: specification, decomposition, evaluation.

Team

Agree what is orchestratable: which task types are well-specified and gated enough to hand to background agents, and what the handoff + review protocol is for that output, so "walked away" never means "unreviewed."

Organisation

Plan for hybrid teams: humans set direction, agents implement, clear handoffs govern the boundary. Hire and develop for judgment — specification, evaluation, architecture, not raw implementation speed.

Check the reflex

Recall, don't re-read.

You're debugging tricky logic in an unfamiliar codebase. Which mode fits?

Conductor: hands-on and live
Orchestrator: async and delegated
Neither: pure autocomplete only

Conductor, complex logic and unfamiliar code are where you want to understand each change as it lands. Orchestrate the well-specified work, not the exploratory 20%.

The last 20% AI leaves is dangerous mainly because —

It crashes on every run
It never compiles, ever
It looks correct, passing basics

Conceptual failures (wrong business logic, missed edge cases) look right and can pass basic tests, which is why they slip through, and why evals with rubrics, not a glance, guard that 20%.

The more you orchestrate (walk away), the more you depend on —

A much larger context window
Runtime governance replacing you
Faster in-editor autocomplete

You were the kill-switch and the observer. Remove yourself and VERDICT's Runtime Control, Evidence, and Identity pillars have to fill the gap, or you're running blind.

Carry this into the week

Before you hand a task to a background agent, ask one question: "if this lands in the dangerous 20%, what catches it while I'm not watching?" If the honest answer is "nothing," conduct it instead, or build the gate first.

Go deeper (primary source)

Addy Osmani's "From Conductors to Orchestrators" is the origin of this framing, and his "The 80% Problem in Agentic Coding" is the sharpest treatment of the 20% that bites.

Notes

Osmani, Saboo & Kartakis, The New SDLC With Vibe Coding (Day 1), "The developer's evolving role: conductors and orchestrators" pp.31–33.
Ibid., "The 80% problem" p.34.

Up next → Lesson 6: The Economics of AI Development — CapEx vs OpEx, the token economy, and intelligent model routing. The last Day-1 lesson, and squarely the team + org lens.