←
How to talk to coding agentsCH. 06 / 07

Orchestration

Watch yourself for a few minutes. Short prompt, response. Short prompt, response. It feels like flow, but the agent finishes in seconds and you spend the next ninety seconds thinking, scanning, retyping. You are the bottleneck.

Ping-pongYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do next~14 minBrief & shipYou — writing a prompt or briefAgent — running~5 mintime →
FIG. 6.1Same work, very different wall-clock cost. The dashed blocks in the top row are you, deciding what to type next.

Orchestration is the move from typist to conductor — from messaging the agent to briefing it, from one thread to several. Stop tuning the next prompt and start tuning the next hour.

Chain, don't ping

If you already know steps two through five before you send step one, write them all into the brief and let the agent walk the chain on its own. The agent loses nothing by knowing the destination; you lose four context switches.

Pinging
> Read the auth module.

(reads, waits)

> Now find the session bug.

(finds, waits)

> Now write a test for it.

(writes, waits)

> Now open a PR.
Briefing
> Read the auth module, find the
  session bug we keep seeing on
  refresh, write a regression test,
  and open a PR. If you hit a fork,
  pick the smaller change and note
  the alternative in the PR body.

Rule of thumb: if you already know the next prompt, write it into the brief instead.

Stagger and overlap

You can only write one brief at a time. The agents don't all start in parallel — you start them in a cascade. Brief thread one, kick it off. While it runs, brief thread two. Then three. By the time you've sent the third, the first is delivering. You step in, glance, send a follow-up, and the cycle continues.

Thread 1You — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningThread 2You — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningThread 3You — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningtime →
FIG. 6.2Briefs (red) cascade — you can only write one at a time. Agent work (ink) overlaps freely. Dashed gaps are the cost of switching attention.

Three things to notice. The red bars never overlap — that's your hands, and there's only one of you. The ink bars do, freely; the agents don't wait for each other. And after every agent finishes, there's a small dashed gap before you come back: attention is a real cost, and you can only spend it on one thread at a time.

Fan out

One agent works on one thing at a time. You don't. The moment two tasks are independent of each other, run them side by side — separate tabs, separate worktrees, separate windows.

You — writing a prompt or briefYou · briefAgent — runningAgent · testsAgent — runningAgent · docsAgent — runningAgent · refactormergetime →
FIG. 6.3One brief fans out; three streams run in parallel; one merge to review. Use this shape only when the tracks don't depend on each other.

Good candidates: tests in parallel with the implementation, five unrelated bugs at once, three library spikes side by side. Bad candidates: anything where agent B reads what agent A produced — don't parallelize a chain. Budget for the merge too; three branches become one review queue.

Specialize the roles

Give different agents different jobs and let them hand work to each other. A researcher reads and plans. An implementer takes the plan and writes. A reviewer comes in cold and critiques. Each role wants a different mindset and a different context window — splitting them enforces a discipline you'd struggle to keep alone.

Researcherreads & plans
Implementerwrites the diff
Reviewercritiques cold
FIG. 6.4Each handoff is a concrete artifact — a plan, a diff. Name them and the seams between roles stop being fuzzy.

Most modern tools support this directly — sub-agents, background tasks, parallel runs. The spin-up cost is now smaller than the cost of switching contexts in your own head.

Run long, check less

The biggest leaps of the last year have been long-horizon tasks — jobs that run for thirty, sixty, ninety minutes while you do something else. Whole-repo refactors. Migrations. Test backfills. The instinct is to babysit. Resist it; babysitting collapses long jobs back into ping-pong.

Write a brief that can survive without you: a clear goal, an explicit success criterion (“all tests pass, build is green”), permission to make small judgment calls, and a fallback for when stuck (“leave a TODO and continue”). Come back to a finished branch, not a half-finished conversation.