The premise was straightforward: if one agent can fix a bug, sixty-four should be able to fix sixty-four bugs. The reality was more interesting, and most of the lessons had nothing to do with the agents.
Parallelism is easy, merging is not
Running 64 agents concurrently is a scheduling problem, and scheduling is solved. Each agent gets its own worktree, its own branch, its own budget. That part worked on the first afternoon.
What did not work was everything downstream. Sixty-four independently correct changes to one codebase produce a merge situation nobody would design on purpose. Two agents fix the same bug differently. Three refactor the same helper in incompatible directions. One renames a function that eleven others are calling.
Sixty-four agents produced far more merge conflict than useful diff. The bottleneck was never generation. It was reconciliation.
Partitioning beat coordination
Our first instinct was to have agents coordinate — announce intent, claim files, negotiate. This performed badly. The coordination traffic grew faster than the useful work, and agents spent budget reasoning about each other instead of the task.
What worked was doing the partitioning up front, outside the agents entirely. Compute a dependency graph, cut it into weakly connected components, assign one component per agent. Agents never negotiate because their work cannot overlap by construction.
This caps useful parallelism at the number of independent components in the codebase, which for most repositories is a lot less than 64. That is a real limit and we would rather know it than paper over it.
Verification does not parallelize the same way
Generation scales linearly with agent count. Verification does not, because verifying a change means running tests, and tests contend for the same resources.
At 64 agents we were saturating the test runner long before we saturated anything else. The fleet spent most of its wall clock waiting. Effective throughput peaked around twelve concurrent agents on our hardware and got worse after that.
Adversarial review earned its cost
The one place extra agents paid for themselves cleanly was verification by disagreement. For each proposed fix, spawn three reviewers whose instruction is to refute it, each given a different lens — does it break under concurrency, does it change behaviour at a boundary, does the described bug even reproduce.
Majority refutation kills the change. This caught a category of bug that single-reviewer setups consistently missed: fixes that are locally correct and wrong in context. Three skeptics with different mandates disagree in useful ways.
Where we landed
Around a dozen agents on partitioned work, each change verified by three adversarial reviewers, and a hard budget ceiling that stops the whole fleet rather than any individual. The number 64 makes a better headline than an architecture.