Imagine you can run hundreds or thousands of coding agents in parallel. How would you use them? The interesting answer is not “do everything faster”, but rather what fundamentally changes when parallelism is cheap.
From Sequential Exploration to Parallel Search #
When you have one agent, you think carefully before acting, because going down dead ends is expensive. With thousands of agents, the calculus flips. Exploration becomes cheap, and convergence becomes the hard problem. Your job shifts from “what should I try?” to “how do I synthesize thousands of results?”
High-Leverage Use Patterns #
Speculative execution on decisions.
At every architectural fork, such as “should this be a queue-based system or polling?”, you do not decide, you branch.
Two fleets of agents build both options, and you evaluate the results, borrowing the processor idea of speculative execution.
This pattern is huge for situations where you genuinely do not know which approach is better until you have tried it.
Mutation testing at scale.
Spin up hundreds of agents making targeted changes to a codebase, each trying a different hypothesis about why a bug exists or how to optimize something.
It is like fuzzing, but semantically directed: instead of random inputs, each change probes a specific theory.
Full-stack consistency checking. Have agents simultaneously hold the contract between every pair of services in your system, constantly verifying that implementations match specs, that error handling is symmetric, and that naming is consistent. These are the things that fall through the cracks in sequential review.
Competitive benchmarking of approaches. For a problem like network latency or caching strategy, you could have 50 agents implement 50 different approaches against the same test harness, and just pick the winner. No reading papers and reasoning about tradeoffs, you settle the question empirically.
Living documentation. Agents continuously reconcile docs, comments, and code. Every pull request triggers agents that check for documentation drift, update runbooks, and surface inconsistencies.
The Harder Problems Cheap Parallelism Creates #
Synthesis is the bottleneck. If 1,000 agents each produce a pull request, you are back to being the serial bottleneck reviewing them. You need meta-agents whose job is to evaluate and rank the output of other agents, with clear scoring functions.
State and conflict. Agents working in parallel on the same codebase will conflict. You probably want agents working in isolated sandboxes (branches, ephemeral clusters, test environments) with a merge or tournament layer on top.
Task decomposition quality matters more, not less. Bad task specs mean 1,000 agents going confidently in the wrong direction simultaneously. The skill of writing tight, evaluable task specs becomes enormously valuable.
Evaluation functions become critical.
“Did the agent succeed?” needs a concrete, automated answer.
You cannot eyeball 1,000 outputs.
That constraint pushes you toward test-driven development in a serious way.
What This Implies For Infrastructure Work #
The most compelling application is parallel experimentation on real infrastructure parameters. Spin up ephemeral environments, have agents try different configurations or scheduling strategies, measure actual performance, then tear the environments down. What makes infrastructure hard is that you normally cannot afford to run 50 experiments simultaneously. With cheap parallel agents managing the scaffolding, that constraint disappears.
The practical limit ends up being compute and money, not ideas, which is a fundamentally different world than the one most engineering workflows were designed for.