Running A Fleet Of Coding Agents

The transaction cost collapse argument says that one term in the cost of a change fell sharply while the rest did not, and that the constraint moved downstream as a result. Running several coding agents in parallel is that argument taken to its conclusion and then run at speed. If producing a candidate change is nearly free, why produce one at a time?

It is a fair question and the answer is not "no". It is that parallel generation multiplies the arrival rate at a stage whose service rate did not change, and queueing systems respond to that in one way only. Everything that makes a fleet work is about the downstream half: how the work is carved so the outputs do not collide, how each change is kept small enough that a human can form a judgement about it, and whether your test suite is trusted enough that part of the judgement can be delegated to it.

There is a version of this that works well, and a version that produces forty open pull requests, two exhausted reviewers, a merge conflict graph nobody can hold in their head, and a codebase that has quietly acquired three ways of doing the same thing. The distance between them is delivery discipline rather than tooling, which is the least fashionable and most reliable finding in this area.

Decomposition is the whole game

Agents collide when their changes touch the same code, and far more readily than people do. Two engineers in adjacent areas talk, notice, adjust. Two agents do not. Each completes a locally coherent change against the state it started from, and you find the incompatibility at merge — or worse, after both merged cleanly and the combination is wrong.

So decomposition happens before dispatch, by a human, against the actual shape of the code rather than the shape of the backlog. Tickets are not units of parallelism. Modules with clear boundaries are.

Carve along seams that already exist. Well-bounded modules, separate services, independent packages. If two pieces of work sit behind one interface, they are one piece of work until that interface is stable.

Push interface changes to the front, alone. If several tasks depend on a new signature, schema or shared abstraction, land that first, on its own, reviewed properly. Then fan out. Agents that each invent their own version of a shared abstraction produce three incompatible designs and a week of reconciliation.

Parallelise the additive, sequence the subtractive. New endpoints, tests, adapters and mechanical migrations parallelise well. Refactors that move responsibility between modules do not, because they rewrite the seams everything else works against.

Refuse to dispatch across a dependency. If task B needs task A's result, B waits. Dispatching both and hoping produces two changes built on incompatible assumptions, and untangling that costs more than waiting would have.

The uncomfortable part is that this decomposition is senior work, it is not much faster with assistance, and it is now the rate limiter on how much parallelism you can usefully run. You have not removed the architectural thinking; you have moved it to the front and made it load-bearing.

Isolation is cheap, so use it properly

Every agent gets its own working tree, branch, build directory and test run. Git worktrees make this near-free: multiple checkouts of one repository sharing history, each on its own branch, no stashing and no interference. Where the build allows it, use separate containers per agent so a dependency change in one does not alter another's environment.

Branch from a recent main and keep it short-lived. A day is comfortable; three days is a merge problem you chose to have. Everything trunk-based development says about long-lived branches applies with more force here, because the divergence rate is higher and nobody involved knows what else is in flight.

Anything shared breaks the isolation: a shared test database, a hard-coded port, a fixture file written during a run, a cache directory keyed by project name rather than worktree. Agents run tests constantly, so these collide immediately and produce failures that look like code defects and are not. Fix test isolation before you scale, and give each agent a fast way to run the relevant suite in its own tree — an agent that cannot verify its own work just adds candidates to the review queue.

Review capacity is the ceiling, and it arrives immediately

This surprises teams, and it should not. It is Little's Law, which does not care how the work was created: average cycle time equals work in progress divided by throughput. If throughput is capped by review and you raise work in progress by generating in parallel, cycle time rises proportionally and nothing arrives sooner. The queueing behaviour is the one described in why busy teams are slow teams, and it goes non-linear earlier than anybody expects.

Do the arithmetic before you scale. Two reviewers absorbing four substantial changes a day each give you eight a day of real capacity. Six agents producing three a day give eighteen. That is a queue growing by ten items daily, and within a fortnight the backlog is the dominant cost in your system and its oldest items conflict with everything merged since. The interventions are the ordinary ones and they work.

Limit work in progress explicitly. Cap open agent-authored changes. When the cap is hit, nobody dispatches; somebody reviews. This is WIP limiting applied to a new kind of producer, and it feels as wrong and works as well as it always does.

Match fleet size to review capacity, not licence count. More agents than your humans can absorb is manufacturing inventory.

Make review cheaper rather than faster. Smaller changes, better descriptions, automated checks that remove the mechanical part of the job. The practice this volume requires is a different one, and it is the subject of code review when code is cheap.

Attack the whole downstream path. A slow pipeline and a fortnightly approval board are queues too.

Keep change sets small enough to be reviewable

Small changes were always better. They are now necessary, because review is the constraint and review cost scales badly with size — a reviewer's ability to hold a change in their head does not degrade linearly, it falls off a cliff in the low hundreds of lines.

The temptation runs precisely the wrong way. A large change costs an agent almost nothing to produce, and one asked to do a broad task will cheerfully return a sweeping one. Agent-authored changes trend larger than human ones, because none of the friction that kept them small — typing effort, fatigue, the author's sense that a change has got out of hand — is present any more.

So impose the constraint in the task definition rather than afterwards. Scope each dispatched task to one reviewable change, split a broad intent into narrow tasks before dispatch rather than after seeing the result, and treat a much larger result than expected as evidence the task was under-specified, which it usually was.

Separate mechanical changes from semantic ones absolutely. A rename across two hundred files is reviewable in minutes if it contains nothing else, and unreviewable if a behavioural change hides in it. Agents violate this constantly unless told not to. Insist too on a description stating intent, approach and what was verified; one that merely restates the diff has passed the work back to the reviewer.

The test suite is what makes any of this safe

Everything above is bookkeeping. This is the load-bearing part. Parallel generation is only tolerable if a cheap, trustworthy, automatic check catches most defects before a human looks. Without it, every change needs full human verification, review capacity collapses to a handful a day, and the fleet produces work nobody can accept. With it, review becomes a judgement about design and intent rather than a hunt for bugs.

The requirement is trust rather than coverage. A suite with flaky tests is worse than a smaller reliable one, because an agent seeing an intermittent failure will either work around it or retry until green, and both destroy the signal. Fix or delete flaky tests before scaling. Speed matters as much, because agents run tests constantly and suite duration multiplies across the fleet. The test strategy argument needed no revision; it simply became more valuable.

Add checks that catch what agents specifically get wrong. Contract or schema tests at module boundaries, because cross-module assumptions are where parallel work collides. Architectural fitness checks on dependency direction and layering, because conceptual drift is otherwise invisible until entrenched. Mutation testing on critical paths, because agents write tests that pass rather than tests that discriminate, and assertions that cannot fail are the most convincing false comfort available. Enforce all of it automatically in the pipeline, which is the argument in putting AI in the delivery pipeline and verification is the new bottleneck.

What stays human

Some things do not delegate, and being explicit about them keeps a fleet from becoming a drift machine.

Architecture and the seams. How the system is divided, where the boundaries are, which dependencies are allowed. Agents work within a structure competently and do not maintain one. Left alone, parallel work erodes boundaries, because each change takes the locally easiest path and nothing looks at the whole.

Invariants. Security properties, data integrity rules, regulatory constraints, the behaviours the business actually depends on. Write them down, encode them as tests where possible, review every change against them personally.

Accountability for the merge. Somebody approved it, somebody owns it, somebody is on call for it. "The agent wrote it" is not a position anyone can hold in an incident review, and an organisation that lets it become one has lost something it will not easily recover. This is the part of what AI does not change that matters most here.

Deciding what should be built. Cheaper implementation makes this more important, because the cost of building the wrong thing well has fallen relative to choosing wrongly.

The failure modes worth naming

Three, and they are the ones that actually get teams.

Plausible wrong code. Agent-authored changes are clean, idiomatic, well-commented and confident. Human mistakes usually look like mistakes — awkward, inconsistent, obviously rushed — and reviewers have spent careers calibrating on that signal. The calibration does not transfer. Surviving defects hide in code that reads beautifully: an edge case unhandled, an error swallowed, an assumption that holds today. Review for what is absent and what happens at the boundaries.

Review fatigue. Reviewing many similar, competent, mostly-fine changes differs qualitatively from reviewing a few by colleagues whose habits you know. Attention degrades, approval becomes the default, and the escape rate climbs with the approval rate. Cap reviews per person per day, and treat a rising approval rate as a warning rather than efficiency.

Conceptual drift. The slowest and most expensive. No single change is wrong; the codebase accumulates three patterns for the same problem, boundaries blur, and the system gets harder to reason about faster than anyone notices. Human teams resist this through shared context nobody writes down, and agents have none beyond the repository — so write the conventions down and do the whole-module read above. This is technical debt as an economic decision accruing faster and less visibly than usual.

What to do on Monday

Count your actual review capacity before adding a single agent: changes per reviewer per day that genuinely receive attention, times available reviewers. That is your ceiling. Size the fleet below it and treat anything above as inventory.

Then check isolation and the suite. Can two agents run the full tests simultaneously in separate worktrees without interfering? Is the suite fast enough to run constantly and trusted enough that green means something? If either answer is no, fix it before scaling.

Cap open agent-authored changes explicitly, at a number you choose rather than one that emerges. When the cap is reached, somebody reviews rather than dispatches. Hold it for a month and compare lead time to production, not pull requests raised.

Finally, put the whole-module read in the calendar monthly, with a named owner, for the areas under the most parallel change. Diff review will not catch conceptual drift and no metric you collect will either. An hour of someone senior reading a module whole is the cheapest insurance against a failure that takes a year to surface and two to repair.