70 Minutes, 10 Pull Requests: Anatomy of a Symphony Run
I run multi-agent coding sessions I call Symphony runs. One orchestrator, a locked plan, and a small fleet of coding agents building in parallel. One run shipped 10 pull requests, about 6,800 lines of TypeScript, and 34 passing tests in 70 minutes.
One run, April 2026: three build waves, short integration steps, one closing smoke test.
The Shape of the Run
The plan comes first, and it is locked before any agent starts. This one went through four review turns the evening before. During the run there is no design debate. Every implementation prompt points at its section of the plan and nothing else.
The plan is decomposed into file-disjoint slices. Each slice owns its own subdirectory, so parallel agents cannot write over each other. Each slice gets its own git worktree on its own branch, cut from a single integration branch.
Then the fan-out. Two to four coding agents build slices at the same time, and reviewer agents fire on every commit instead of waiting for the end. An integrator cherry-picks finished slices into the integration branch and keeps one consolidated pull request as the only thing I ever review.
File-disjoint slices fan out to parallel agents and fan back in to one reviewed PR.
The merge is gated. Adversarial review rounds run against the consolidated diff, and a smoke test runs against the assembled whole. In the 70-minute run that smoke test caught a real race condition in parallel test execution, a bug no single slice could have shown.
The numbers hold across sizes. With a locked plan, a small-to-medium PR lands about every 7 minutes. The same pattern carried a 29-PR run across five waves, and a 6 hour 41 minute overnight run that produced 52 commits and 13,900 lines added, with parallelism capped at four agents the whole time.
The lesson that keeps repeating: the agents are not the bottleneck, the plan is. Locked plan, disjoint slices, one review surface, gated merge. Everything fast about these runs was decided before they started.