Execution: running a multi-agent build

Planning is done. You have a spec broken into slices, and the grilling has already happened. That's why the plan doc exists. This chapter turns that doc into merged, tested code without losing the thread across five agents working at once. Jargon arrives fast here, so dotted terms like subagent explain themselves on hover, or on tap on a phone.

The claim underneath everything here is measurable. Across 29 days I logged 241 sessions and roughly 1,470 hours of agent runtime, shipping +109k / −9.5k lines with 88% of classified tasks mostly or fully achieved. About 24% of messages were across parallel Claude sessions. None of that works without the discipline below. Volume without gates is just a faster way to make a mess.

Why break work down at all#

Everything in this chapter is downstream of one fact: an agent gets less capable as its context window fills, long before the window is actually full. Matt Pocock, whose workflow this track borrows heavily, calls the early stretch the smart zone and everything after it the dumb zone, a framing he credits to Dex Horthy of HumanLayer. Roughly the first 40% of the window is sharp; after that, confusion and mistakes creep in.¹ In his AI coding workshop he puts the practical marker around 100k tokens no matter how big the advertised window is: "It starts to just get dumber."² His written definition hedges the number, not the effect: the dumb zone "commonly begins around 125K-150K tokens — though this is debated."³

The boundary is debated; the cliff is corroborated. Chroma's Context Rot study measured 18 frontier models and found accuracy degrades, unevenly, as input grows even on tasks the same models ace with short input.⁴ Anthropic's own engineering guidance describes an "attention budget" that every token in the window draws against.⁵ And Pocock's recovery rule is the line worth memorizing: "You recover by removing context, not adding more."³

That is the entire logic of breaking work down. Slices are small so one agent can plan, build, and test a slice while staying deep in its smart zone. Subagents exist so heavy reading happens in someone else's window and comes back as a summary. Docs carry memory between sessions, which is chapter 3's whole subject. And gates exist so you can stop, merge, and restart fresh instead of nursing one long, degrading conversation.

The toolkit: skills you call, not skills that fire#

The workflow runs on skills. Mine come from mattpocock/skills, the same library behind the grilling in the previous chapter: /grill-me and /grill-with-docs to reach shared understanding, /to-spec to lock it into a spec, /to-tickets to cut the spec into tracer-bullet tickets, /tdd and /code-review during the build. One install and they show up as slash commands.

What makes this set distinctive isn't any individual skill. It's that every one is user-invoked: nothing happens until you type the slash command. The best-known alternative, Jesse Vincent's superpowers, takes the opposite bet.⁷ A session-start hook teaches Claude to search the skill library itself and to use any skill it judges relevant, so the brainstorm-plan-implement process engages on its own the moment you describe a task.

Auto-firing has real advantages. The process runs even when you forget to ask for it, it's uniform across a team, and superpowers is impressively built: the bootstrap costs under 2k tokens and the skills are adversarially pressure-tested. The costs are the mirror image. Ceremony fires whether or not the task deserves it, so a two-line fix can summon a planning interview. And when a session goes sideways, it's hard to tell which auto-loaded skill steered it there. Pocock's version of that critique is aimed at process-owning frameworks like GSD, BMAD, and Spec-Kit rather than at superpowers, but it's the same trade: they "take away your control and make bugs in the process hard to resolve."⁸

I stay on the user-invoked side because it keeps the process legible. I decide when a task deserves the full grill → spec → tickets treatment and when it's a two-minute edit. When output goes strange, I know exactly which skill was in play. And because I reach for each skill deliberately, the method sticks: I'm learning a workflow, not riding one. The rest of this chapter is that workflow's execution half.

Slice, don't layer#

The unit of execution is a vertical tracer-bullet slice: one thin path through the whole stack that actually runs, not a horizontal layer you finish before starting the next. A slice is sized for one agent, small enough to finish well inside the smart zone. Write one test, make it pass, repeat, and let each test respond to what the last one taught you.

The anti-pattern is writing every test first and then all the implementation. Tests written in bulk verify imagined behavior. They test the shape of your data structures instead of what a user can do, and they pass while real behavior breaks.

WRONG (horizontal):
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

RIGHT (vertical):
  RED → GREEN: test1 → impl1
  RED → GREEN: test2 → impl2
  RED → GREEN: test3 → impl3

Red, green, refactor#

Good tests exercise real code paths through public interfaces. A test named user can checkout with valid cart tells you what capability exists, and it survives a refactor because it doesn't care how the code is structured internally. If renaming a private function breaks a test, that test was coupled to implementation. Treat it as a warning sign, not a passing grade.

The TDD loop each slice runs:

# 1. RED: write the test, run it, watch it fail for the right reason
npm test -- cart.checkout.test.ts

# 2. GREEN: write the minimum code to pass
npm test -- cart.checkout.test.ts

# 3. REFACTOR: clean up with the test as a safety net
npm test

# 4. Confirm the whole suite is still green before declaring the slice done
npm test

A subagent executing a slice gets told, verbatim: write the slice's tests, run them to confirm they fail correctly, implement, get them green, refactor, and run the tests one more time before reporting back.

When it breaks, build the loop first#

The hard part of debugging isn't the fix. It's having a fast, deterministic, agent-runnable pass/fail signal for the bug. With one, bisection and hypothesis-testing are mechanical. Without one, no amount of staring at code will save you.

So before touching the suspected code, build a loop: a failing test at whatever seam reaches the bug, a curl script against the dev server, a headless Playwright script that drives the UI and asserts on the DOM, or a replay of a captured payload through the code path in isolation. Then make it faster, sharper, and more deterministic. A 2-second deterministic loop is a debugging superpower. A 30-second flaky one is barely better than nothing. For a UI regression, Playwright-MCP lets the agent drive the real browser and verify the fix in-band rather than claiming success from a diff.

Only after the loop reliably reproduces the failure the user described do you hypothesise and fix. A nearby failure is the wrong bug, and the wrong bug gets the wrong fix.

Dispatch waves of parallel agents#

Once slices are independent, they run in parallel. The coordination lives in an orchestrator doc, a markdown file holding the cross-slice dispatch graph, the rules every subagent follows, and a live status table. The orchestrator doesn't write feature code. It writes the dispatch plan, watches tasks complete, resolves conflicts, and integrates.

Independent slices are spawned as a wave: several subagents in one message so they run concurrently, each in its own git worktree so their checkouts never collide.

# Each slice gets an isolated checkout. This is what makes a wave safe.
git worktree add ../wt-A1 -b slice/A1-worker-scaffold
git worktree add ../wt-A4 -b slice/A4-ask-ui
git worktree add ../wt-B1 -b slice/B1-push-contract

Every subagent's prompt carries the same rules block:

You are executing one slice of a larger plan.

- Read your slice's section in the plan doc end-to-end before doing anything.
- Apply TDD: write the failing tests, implement, get them green, refactor.
- Stay strictly within your slice's file list. If you need to touch a file
  outside it, STOP and report — do not expand scope.
- Leave a one-paragraph status note (commit SHA, tests added, surprises).
- Do not merge. Do not delete worktrees. Do not push to main.

Gates between waves#

You don't promote from one wave to the next on vibes. Every wave ends at an acceptance gate: before Wave N+1 starts, every Wave N branch is merged, npm test is green on main, the deploy dry-run passes, and each slice has left its status note. If a gate fails, you fix forward by spawning a follow-up slice before dispatching more work.

Merge order matters: integrate lowest-conflict-first. Shared infrastructure and frozen contracts land before the slices that consume them, and the second slice to touch a known hotspot rebases rather than fighting a conflict. Conflict-prone files (a config envelope, the home page, a shared nav) get flagged in the orchestrator doc up front, with the first slice laying down the full structure, commented placeholders included, so later slices only fill it in.

Here's what a wave handoff actually sounds like:

Every one of those green checks is a claim you verify at the diff, not a claim you trust. My reads run roughly 1:1 with edits for a reason. Move fast because the gates, not your optimism, are what say a slice is done.