Working paper · AI engineering

The Heat Death of the Codebase?

On Paying Maxwell’s Demon a Day Rate

How many AI coding agents to run, and why review sets the limit.
Tom Baldwin · First published 29 September 2026 · revised 1 October 2026

The hard part of software engineering was never coding: it’s deciding what to build, and knowing what was built is right. Coding agents now make changes cheaply, and you can add as many agents as you like for the cost of the tokens. So how many agents should you run? Not as many as you can afford: every change still needs an engineer’s judgement, and every change creates some waste: conflicts, regressions, fixes that need fixing. More agents make more changes at once, and the waste grows faster than the output.

Engineers have a name for the energy an engine takes in but cannot turn into useful work: waste heat. This paper puts numbers on an agent fleet’s waste heat: one model of three well-studied effects, with defaults from published measurements going back to 1975, reduced to a sizing formula and a rule of thumb for when you have no numbers yet.

1 The formula

The three equations below are shortcuts to the model in section 6. It starts from the three forces of section 3. Contention and coherence enter as the coordination drag of Neil Gunther’s Universal Scalability Law, and rework rises with the number of changes in flight. Finished work is then capped at what reviewers can check. Equation 1 is where the agents’ output, after drag but before rework, first fills that ceiling. Equations 1 and 2 are approximations, chosen by testing them against the full model (section 2); the third follows directly from it.

The sizing formula

Fleet size where review is the limit

Agents ≈ q/(1 − αq − βq²)(1)

Most agents worth running

Agents ≤ (1 − α)/(p + √β)(2)

Finished work when review is the limit

Finished work ≈ (1 − r) · review capacity(3)

where:

q

agents your reviewers can keep up with (review capacity ÷ one agent’s output)

α

share of work that waits its turn

β

coordination cost per pair of agents

p

chance two concurrent changes force a redo

r

share of changes that come back

In words Run enough agents to keep your reviewers busy, a few more to cover the drag, and stop there.

1.1 Equation 1 is usually the answer

A careful human reviewer checks about 200 lines an hour, and a single agent can produce more than one reviewer can properly read. So for teams with one or two reviewers and modest automation, the fleet is limited by review: the right number of agents is the number that keeps your reviewers fully used. q is that number before drag. The rest of the line adds the agents you need to make up for the output lost to coordination. If αq + βq² reaches 1, drag stops the fleet ever filling your reviewers, and equation 2 decides instead.

1.2 Equation 2 is the ceiling

Past the ceiling, each extra agent causes more coordination and collisions than it adds in output, whatever your review capacity. With typical values it is about 8 agents.

1.3 Equation 3 is what you get

When review is the limit, finished work is what your reviewers can check, less the share of changes that come back, r. Re-reviews of returned changes use the same capacity, which is why rework costs twice. Adding agents does not raise it; better verification, such as tests, types and automated checks, does. When the ceiling binds instead, finished work before rework is X(N) from equation 4: with typical values, about 3.5 agents’ worth from a fleet of eight.

1.4 A worked example

Take the typical fleet. Two reviewers read about 1,200 lines a day between them, and with tools doing half the checking that covers about 2,400 lines of agent output. An agent produces about 900 lines a day, so q ≈ 2.7. Equation 1 then says 4 agents, and equation 3 says they finish about 9.3 changes a day, which is what the full model gives. The rule of thumb agrees: at that level of automation it allows two agents per reviewer, which is also 4.

1.5 Why not run more?

Equation 1 is the theory of constraints applied to a fleet: size everything to the step that limits it. The calculator plans for reviewers to be busy 75% of the time, for the usual queueing reason: the time work waits for a server rises steeply as it approaches full use, and once work arrives faster than it can be served the queue simply grows (Kingman; Reinertsen; Tan plans to 80%). The trial below ran past that point.

Past this size finished output barely changes, but cost does: every extra agent burns tokens, and every change it makes joins the queue of work waiting to be checked. The calculator’s estimate below shows what a backlog costs in agent-days at the size you choose.

2 How well it holds up

We tested the formula against the full model over 1,050 combinations of settings: α from 0.02 to 0.4, β from 0.001 to 0.035, p from 0 to 0.05, and review capacity from half an agent’s output to none at all. It picks a fleet within one agent of the best in 91% of cases. Running at its size delivers at least 91% of the best achievable output in every case, and 98% or more in nine cases out of ten.

2.1 Where the rule of thumb comes from

The rule of thumb is the formula with the details dropped. A careful person, with no help from tools, checks roughly what one agent produces, and every share of checking that tools take over multiplies what that person can keep up with: that is q again. Equation 2 gives about eight for typical values, but that is the peak. The rule aims at the smallest fleet that gets close to it, which across the teams we simulated is usually five or fewer; a cap of four did as well. The cap is per codebase, because collisions and coordination only happen between agents working on the same code. Twelve agents spread across three projects are four per codebase and get in each other’s way far less, though they still share the people checking them.

2.2 Testing the rule

We tested the rule against the full model, and against simpler rules such as “always run four”, on randomly drawn teams: one to six reviewers, 0–80% of checking automated, and the ranges of α, β and p above. Output is nearly flat past the best size, so being close to the best output is easy; the test also asks whether a rule avoids paying for agents that add nothing, meaning no more than one agent per codebase beyond the smallest fleet that gets within 5% of the best.

On 20,000 simulated single-codebase teams the rule gets within 10% of the best output for 84% and does both for 67%, against 47–54% for “always four” or “always five” and 47% for “two per reviewer”. The sizing formula gets within 10% of the best output for 99% of these teams, but it aims at the peak, so it usually runs one agent more than it needs.

On 8,000 simulated teams running two or three codebases that share their reviewers, searched over every way of splitting the agents, the rule does both for 54–57%, and no fixed number does better than 28%. The test script and its results are public. The rule assumes human reviewers; for agents as reviewers, see below.

3 Where the waste heat comes from

Three forces pull a fleet’s output below the sum of its agents. Each has decades of evidence behind it in human teams, and early measurements suggest each shows up in agent fleets.

• ContentionSome steps happen one at a time: the merge queue, CI, a lock on a shared file, a human approving the change. This is Amdahl’s law. Cursor reported that twenty agents coordinating through locks “would slow down to the effective throughput of two or three”. After replacing the locks with a hierarchy of planners and workers, the same team ran hundreds of agents at once. How much contention a fleet has depends on how it is organised.
• CoherenceEvery pair of agents can step on each other, and the number of pairs, n(n−1)/2 as Brooks counted them for people, grows with the square of the fleet. Agents must also catch up on what the others changed. A 2026 study built on 33,596 agent pull requests replayed pairs that were open at the same time: 41.7% of sampled pairs from different agents (48 of 115) had textual conflicts, and 19.8% of pairs from the same agent. Our own test below found that few of those conflicts turn into rejected work.
• ReworkSome changes need fixing, and some fixes need fixing too. That is a geometric series: total effort is the planned work divided by (1 − r). At r = 0.5 you do twice the work. When r reaches 1 the series never ends, and each fix breaks at least one more thing.

Brooks described the last one in 1975: repairs tend to destroy a system’s structure and increase its disorder, until fixing stops making progress. He put the chance that a fix introduces a new defect at 20–50%. Lehman wrote that his law of increasing complexity may be an analogue of the second law of thermodynamics. Agents raise all three at once.

3.1 Returns cluster

The rework term treats every change alike: each has the same chance r of coming back, and so does each fix. Reviews of agent pull requests say otherwise. In AIDev, the public dataset of agent pull requests tested in section 8, 11% of reviewed changes in repositories where changes wait for review were sent back in review at least once. Of those sent back once, a quarter to over a third came back again, and the chance kept rising with each round. A few bad changes keep bouncing, and the total comes to between a fifth and a half more rework than a constant rate predicts; the range is there because the data cannot always tell one round of review from two. Fixes to human-written code also come back more often than first changes: about 10% of changes need a follow-up fix (table 1), while 22–33% of resolved bugs needed more than one fix (Park et al.), and at least 15–24% of fixes to shipped bugs in four large operating systems were themselves wrong (Yin et al.).

Counted as the share of changes sent back at least once, r is a floor, and the rework it implies should be scaled up. As the share of reviews that send a change back, the way the trial in section 9 counted it, it already includes the repeats. There the reviewer, a model, sent rework back at the same rate as first attempts, so on that small sample its returns did not cluster. Either way the repeats are re-reviews. If q counts only first submissions, review binds at fewer agents than equation 1 says; counted with resubmissions, as in section 9, it already allows for them.

A returned change might also spread its trouble, its fix breaking other agents’ work in turn. We looked for that in the same data, in review outcomes, and did not find it. A pull request whose files received a merged change that had needed rework was no more likely to be sent back afterwards than one whose files received a clean change, once the strictness of its reviewers was allowed for, though the data cannot rule one out. Such pull requests tended to be abandoned more often, but the data has no control to separate that from strictness. The exploratory analysis has the details. It cannot say how large each return was, because the dataset has no line counts.

4 Unverified change is entropy

We use the word in the spirit of Shannon: entropy as missing information. For a codebase, the useful version is the gap between what the code does and what you believe it does. Every unverified change widens that gap. Verification (tests, types, review, proofs) is the work that closes it again.

We are not claiming a physical energy cost. The Landauer bound on erasing a bit, about 2.9 × 10⁻²¹ joules at room temperature, is irrelevant to an engineering budget. The analogy is structural. Only observing code removes uncertainty about what it does, and observing is work someone or something has to do.

Maxwell imagined a demon that could sort fast molecules from slow ones, and so make heat flow the wrong way, by checking each molecule and letting only the right ones through. Szilard, Landauer and Bennett worked out what the demon costs. Looking can in principle be almost free, but the demon has to remember what it saw, and clearing that memory for the next molecule has an unavoidable cost. Your reviewers are that demon. They can hold back the disorder, but only if someone pays them to look, to keep track of what they have checked, and to clear their desk for the next change. Economists would recognise a cousin of Baumol’s cost disease: as generation gets cheaper and checking does not, checking takes a growing share of the cost.

5 The same limit, one level down

A language model is an engine of the same kind. It samples a plausible change, so every output carries some leftover uncertainty about whether it is right. Long tasks compound this: each step has some chance of going wrong, so the chance of finishing falls away with length, consistent with METR’s measurements of how long a task agents can complete.

Having another model check helps only so far: Stroebl, Kapoor and Narayanan showed that when a verifier sometimes passes wrong answers, generating more candidates and checking them cannot push accuracy past a ceiling set by how often the verifier waves a wrong answer through, however much compute you spend. A model reviewing a model’s work also tends to share its blind spots: different models agree on the same wrong answer far more often than chance would predict, so their errors only partly cancel. The reviewer in our controlled experiment is itself a model, so its escaped defects measure this.

The way out is to move checking onto machines that do not guess: types, tests, proofs and effect analysis. Inside what they cover they are cheap and almost never wave a wrong change through. But they only check what has been specified. The gap between the specification and what someone meant still needs a person.

5.1 Life’s checkers

Living cells have faced this problem for about four billion years, and several of their solutions carry over to code.

• Checking costs energyThe enzymes that copy DNA and build proteins tell right building blocks from wrong ones far better than the binding-energy difference between them should allow. Hopfield and Ninio proposed how in 1974 and 1975, and experiments supported it (Hopfield et al.; Thompson and Stone): the enzymes spend energy on extra checking steps, called kinetic proofreading. Bennett showed that the lowest error rate a proofreading scheme can reach is approached only as the energy it burns goes to infinity.
• Independent layers multiplyCopying DNA makes roughly one error in 10⁴ to 10⁶ bases from base selection alone. Proofreading removes 90 to 99.9 per cent of those, and mismatch repair a further 99 per cent or more, for roughly one in 10⁹ to 10¹⁰ per base per replication in bacteria and eukaryotes. That works because the layers catch errors largely by different mechanisms, so what one misses the next mostly does not. Two models reviewing the same way do not have that property.
• Care where errors lastErrors in DNA persist and are inherited, so selection has driven its copying to enormous accuracy. Most proteins are replaced within hours to days, and are built with errors around a million times more often (Drummond and Wilke). Code on the main branch deserves the heavy checking; a throwaway branch does not.
• Structure narrows the searchA template or a crystal lattice constrains what can be built, so there is less to check. Types, schemas and specifications do the same for code.
• Slow down when checking falls behindWhen misfolded proteins pile up in the endoplasmic reticulum, where the cell folds its secreted and membrane proteins, faster than its quality control can deal with them, the unfolded protein response throttles new protein synthesis and expands folding capacity until it catches up. The cell holds its output to what its checking can handle, as equation 1 does, and if it still cannot catch up, it kills itself.

6 The model

Coordination drag follows Neil Gunther’s Universal Scalability Law, which has been fitted to systems from databases to human teams. With N agents, raw throughput in single-agent units is

where α is the share of work that must happen one at a time and β is the cost of each pair staying in sync. On its own, this peaks at N* = √(1−α)/β. Rework rises with the fleet, because each change can collide with any of the N−1 others in flight:

Useful output is raw throughput that does not come back, capped by what reviewers can verify:

Here r₀ is the share of changes that come back when one agent works alone, and r(N), written r in equations 3 and 7, is that share with N agents. λ is the number of changes one agent submits per day, V is verification capacity in reviewed lines per day and h is lines per change. Rework hits whichever limit binds. Reviewers spend time on changes that come back, and agents spend time redoing them, so the factor (1 − r) multiplies both the raw output and the review ceiling.

The sizing formula is an approximation to where U peaks, chosen by testing against the full model. Equation 1 is the fleet size at which raw output reaches the review ceiling: solving λX(N) = V/h exactly when β = 0 gives (q(1 − α))/(1 − αq), and equation 1 is a simpler form that also allows for β. Equation 2 approximates the peak without a review limit: with no collisions it gives (1 − α)/√β, a little below Gunther’s √(1 − α)/√β.

A collision here means a conflict that forces a change to be redone. A textual conflict is often a quick rebase, so if most of yours are cheap, use the share that are not. And β should be measured separately from p, or fitted jointly: a β fitted to raw throughput already contains the rework that collisions caused, so pairing it with a non-zero p counts conflicts twice.

No heat engine can beat the Carnot limit, the ceiling on efficiency set by the conditions it runs in. The best finished output this model allows is the equivalent for an agent fleet, set by your collision rate, coordination costs and review capacity. The analogy is loose: Carnot’s limit depends only on the temperatures an engine works between, while this one depends on how the fleet is organised. The calculator below finds it.

Carnot

Find your fleet’s Carnot limit

The typical fleet, with two reviewers: best at 4 agents. With JavaScript on, every input here can be changed.

Agents	Finished changes/day	Rework	Limit
1	3.6	40%	coordination
2	6.4	41%	coordination
3	8.4	41%	coordination
4	9.3	42%	review
5	9.2	42%	review
6	9.1	43%	review
7	9.0	44%	review
8	8.9	44%	review
9	8.9	45%	review
10	8.8	45%	review

7 What the data says

Default values in the estimator come from published measurements. Most are thin, so treat them as starting points and replace them with your own.

Telemetry from AI-heavy teams is consistent with the model. Faros AI reported 98% more pull requests merged, but review time up 91% and no gain in company-level throughput. DORA’s 2024 survey associated every 25% rise in AI adoption with a 7.2% fall in delivery stability. Both are what you would expect if output is capped by verification and the surplus turns into rework.

8 Tested against 48,000 agent pull requests

We tested the model’s collision term on AIDev (Li, Zhang and Hassan, 2025), a public dataset of pull requests written by coding agents. Two of the studies cited above, Xu et al. and Ehsani et al., use a subset of the same data. We wrote down the hypotheses, the analysis and what would count against the model before looking at any outcome, and published the results whichever way they came out.

They came out mostly against. Across 48,128 closed agent PRs in 455 repositories, a PR opened while many others were open was not rejected more often. Three of the four pre-registered predictions failed. The one that held was the mechanism: concurrent PRs touching the same files raised rejection slightly, by about 0.2% each, while those touching other files did not. The sample is dominated by agents merging their own PRs within seconds, with no review at all. In the 298 repositories that look review-gated, rejection did rise with concurrency, by about 0.2% per concurrent PR, but that analysis was done after seeing the data and the rise came from PRs touching different files. It points at load on reviewers, not collisions between changes, which fits Nachuma and Zibran’s finding on the same data that reviewer engagement is the strongest predictor of an agent’s PR being merged.

We changed the paper as a result. The default collision chance went from 5% to 1%, and the sizing formula now leads with review capacity.

9 A first controlled trial

We built a sandbox codebase with 220 small, tested feature requests and a harness that runs a fleet against it. Each task goes to its own cloud session running Claude Haiku 4.5. Every finished change is reviewed by a single automated reviewer, Claude Opus 5.5, which sends it back or approves it. Hidden tests then check approved changes before they merge. Before the full experiment, a trial ran one agent for 30 minutes, then twelve for 30 minutes. Two of the twelve were lost to a fault in our tooling, so the second half ran with ten.

The reviewer was fast: about 21 seconds a change, or roughly 170 reviews an hour, far quicker than any person, and it still became the limit. Each agent submitted about 14 new changes an hour, and the reviewer sent 39% back; counting merge conflicts and escaped defects too, 46% came back (r ≈ 0.46). With resubmissions, each agent created about 20 reviews an hour. That makes q, counted in reviews, about 8, so with no drag equation 1 puts the point where review binds at about eight agents. With ten running, the reviewer was busy 88% of the time and its queue grew throughout the window, from nothing to 29 changes waiting. With one agent it was idle most of the time. Six of the 69 changes that reached the merge queue conflicted with work merged since they started and went back; with about nine changes in flight, that is a collision chance of about 1% per pair, the paper’s default.

Automating review raised the limit, from a few agents to about eight here, but did not remove it, and a fleet of this speed reaches it quickly. Each change sent back costs a second review, so a reviewer at 39% spends about a third of its time re-reading changes it has seen before.

This is one trial on one afternoon, a rehearsal for the pre-registered experiment, so treat it as an illustration of the mechanism. The full experiment is designed and its plan is public.

10 What if the reviewers are agents?

The trial above already had one. An agent reviewer changes two numbers in the model. Review capacity V goes up several times over: the Opus reviewer could check the work of about eight agents, where a careful person can check the work of one or two. And a new number appears: the share of wrong changes it approves, its escape rate e. In the trial, 2 of the 71 changes it approved, about 3%, failed hidden tests it never saw. Two is a small count: the true rate could be anywhere from under 1% to about 10%. Finished work that is also correct becomes

and the escaped changes are unverified change that has been marked as checked. A fully busy reviewer of this speed approves about 100 changes an hour, so that is roughly three wrong changes an hour, and possibly as few as one every few hours or as many as ten an hour. Our hidden tests caught them; in most codebases nothing would.

Each extra agent reviewer catches fewer of the first one’s escapes than an independent check would, because models tend to share blind spots (section 5), so a stack of them has to stop at something that does not guess, or a person reading the change.

Agent reviewers are still worth having. They raise the review limit, and in our trial they let few wrong changes through. But they move the question from “who has time to read this?” to “who checks what the reviewer let through?”, and the answer to that one is still paid at a day rate.

10.1 Hurried reviewers let more through

Equation 7 treats e as a constant, and for people it is not. Across 617 programs, reviews at or below 200 lines an hour found 56–57% of code defects and faster ones 45–47%, and reviews above 800 lines an hour found 25 to 33 points fewer defects than the careful ones (Kemerer and Paulk). In one large open-source project, reviewers with longer queues of pending reviews were more likely to approve a change that later proved buggy, in every part of the project studied (Kononenko et al.). Both are correlations, and Kemerer and Paulk note the link may partly run the other way: a reviewer who finds more slows down to record it. Read as escapes, reviewing faster than the careful pace lets through roughly 1.2 times as many wrong changes, and above four times that pace roughly 1.7 times as many.

The model assumes that a fully used reviewer keeps the careful pace and the excess waits in a queue, where everyone can see it. The other way out is to speed up, and then the excess arrives as escapes, where nobody can. With typical values this barely arises: even at full use, with none of the 25% headroom the calculator plans for, the fleet only just peaks at what two careful reviewers can check. With one reviewer at full use it does. Take the careful reviewer’s escape rate to be the trial’s 3%. Holding the pace, two agents are best, at about 6 correct changes a day. Speeding up to keep up with eight agents gives about 11, while escapes rise from 0.19 to 0.44 a day.

On the model’s own accounting, where an escaped change costs only itself, the hurried reviewer comes out ahead. The trade turns once an escape costs more than some number of changes’ worth of later work, and that number depends on how much the careful reviewer already lets through: about 65 at an escape rate of 1%, about 20 at the trial’s 3%, and about 6 at 10%. What an escape really costs is one of the open questions below. So read the constant e in equation 7 as the rate at a careful pace, and the rule of thumb’s “no more than your reviewers can check” as meaning at that pace.

11 What is new here, and what is not

We searched the literature from Lehman and Brooks to the 2026 preprints, and read the closest neighbours in full. Each ingredient has prior art. We have not found the combination.

• EstablishedScalability laws applied to agents. Gunther applied his law to Brooks’s law in 2007. Mieczkowski et al. applied Amdahl’s law to teams of LLM coding agents and named Gunther’s law as future work. Khailo applied Gunther’s law to one developer’s parallel agents, with one measured point. Mikaduki modelled merge overhead that rises with the number of parallel candidates. Scaling laws in agent count for reasoning tasks (Bertalanič and Fortuna; Li, Gu, Cai and Feng) show the same diminishing returns, though none measures merged code. Mathews’s “Amdahl’s law for AI agents” makes the share of work needing human judgement the serial fraction.
• EstablishedVerification as the new bottleneck. Argued widely, from “verification debt” to Karpathy’s generate-and-verify loop; Bhati counts it as a “verification tax”. Stroebl, Kapoor and Narayanan showed that an imperfect verifier caps the accuracy of resampling however much compute you spend.
• EstablishedEntropy as a metaphor for software decay (Lehman, Brooks). Hassan’s change entropy made it measurable and showed it predicts faults. Casserini et al. use “agentic entropy” for the drift between what an agent does and what the design intended.
• EstablishedFlow and queueing. Sizing a system to its constraint is Goldratt’s theory of constraints; the cost of queues in product development is Reinertsen’s subject, and Tan applies queueing to verification directly.
• Partly newA rework rate that rises with fleet size. Uber measured a 5% chance of a real conflict with two changes in flight, rising to 40% at sixteen (Ananthanarayanan et al.); we put that effect into a scalability model for agent fleets. Our test in section 8 found it much weaker.
• Partly newRework applied to the verification ceiling as well as to output. Rework loops that consume inspection capacity are standard in factory queueing (Hopp and Spearman); applying them to an agent fleet’s review is what makes verification the lever.
• Partly newA review-capacity ceiling on a fleet’s finished output. Tan (2026) models a single reviewer’s queue, with a “verification capacity frontier” and a plan to keep review demand below 80% of capacity, but without agent counts, collisions or a rework term. Mikaduki treats merge and test gates as capacity limits on schedule length.
• NewThe sizing formula and a simpler rule of thumb, their accuracy against the full model, and a pre-registered test of the collision term against real pull requests. The nearest published closed form is Liang’s optimal team size for human–agent work, which counts only people and has no collision term or review-capacity ceiling.

12 Calibrate it for your team

Most of your own numbers are cheap to get: an agent can read them from your repository’s history in minutes. We publish an agent skill, Carnot, that does this. Start with the first three; they decide most of the answer.

12.1 Measure review capacity

Count who checks the work, how many focused hours a day they spend on it, and how much of the checking tests and tools already do: roughly, the share of questions a reviewer would otherwise answer by reading that the tests, types and tools answer instead. This sets q, and q sets the fleet.

12.2 Measure r₀

Take the share of changes that need a follow-up fix or revert within two weeks, or that a reviewer sends back.

12.3 Measure p

Take pairs of changes that were open at the same time, and count the share that conflicted badly enough to need real rework beyond a quick rebase. Expect it to be small.

12.4 Sweep the fleet, if you need to

α and β cannot be read from history, and for most teams the defaults are close enough. If you want your own, you do not need a long experiment: run your usual fleet size and two or three sizes around it on comparable work, a day or two each, and count changes that were merged and stayed merged. Three sizes are the minimum for a fit and four give a check. Hold p at your measured value, so conflicts are not counted twice.

13 What moves the limit

Adding agents moves you along the curve; the changes below move the curve itself.

• Review ceilingDeterministic checks that answer a question a reviewer would otherwise answer by reading: type systems, contract and property tests, architecture and effect checkers. A deterministic check also removes a whole class of uncertainty, so reviewers read less of each change, and it doesn’t get tired at the thirtieth pull request of the day.
• Rework r₀Give agents the answers before they edit: fast tests, precise tasks, and tools they can ask what a change would affect. A change that fails a check inside the agent’s own loop is rework no reviewer ever sees.
• Collisions pSplit work so agents rarely touch the same files, keep changes small, and catch the collisions that merge cleanly but break behaviour.
• Coordination βHand only finished artifacts from one agent to the next. In one study, a shared log of who has claimed which task cut the share of agents redoing a teammate’s work from 78% to none (Sarkar). Organise agents as a hierarchy of planners and workers.
• Contention αRemove steps that happen one at a time: parallel CI, and merge queues that test changes speculatively, as Uber’s does.

13.1 How far the limit moves

A plausible set of improvements, added in turn, looks like this. The inputs are illustrative.

Most of the gain comes from the first change. Raising verification capacity moves the limit from review to coordination, and the best fleet doubles from 4 agents to 8 without anyone planning for more agents. Cutting collisions is worth the least.

Our own open-source tool, Candor, is one attempt at the first row: it works out which code can reach the network, filesystem, a database or a subprocess, and fails the build when a change breaks an architectural policy. We will measure it with Carnot’s compare mode on our own repositories, beside repositories that did not change, and publish the results whichever way they come out.

14 Let your agent do it

You do not need to move the sliders yourself. The carnot skill gives a coding agent a script that reads your repository’s history and measures the inputs:

• ReworkChanges later reverted, sent back in review, or followed within 14 days by a fix to the same files.
• CollisionsReal pairs of branches that were open at the same time, replayed with git merge-tree to see whether they conflict.
• OutputFinished changes per day and lines per change.

It works from GitHub pull requests, merged branches on any host, or plain commits. It asks you only for what history cannot show, such as how many people review and how much checking is automated, and then reports your fleet’s Carnot limit: the best size, what limits it and which change would help most. Its compare mode measures the same repository before and after a change, such as adopting a new verification tool. It runs locally, so no repository data leaves your machine.

15 Crystallise the work

Everything above treats a model as a worker: it produces a change, and someone has to check that change. A second way escapes most of the limit: use the model to build a deterministic, tested and understood tool that then does the job the same way every time.

A compiler is the familiar case. Nobody reviews its output line by line, because the checking was done up front, very thoroughly, and kept up, and the result is reused millions of times. In this paper’s terms, a tool is crystallised work: once the structure is found, it stays put.

The most valuable tools to build are checkers. Each one moves another class of question out of a reviewer’s head and into a machine, which raises the automated share of verification: the lever that doubled the best fleet size in table 2. The effect compounds: models build checkers, checkers raise verification capacity, and more capacity lets you run more models safely. Carnot is an example: a tool, largely written with a model, that measures your fleet so that nobody has to guess.

This has limits. A tool is only as good as its specification, so the gap between what was specified and what was meant moves into the tool’s design, where a person checks it once instead of on every use. Tools still need maintenance: Lehman’s law of continuing change applies to them too, although maintaining one tool costs far less than reviewing every output it replaces. And not everything can be turned into a tool. Novel, one-off judgement stays with the model as worker, and stays limited by review.

16 Heat death is not inevitable

In physics, heat death is the fate of an isolated system, one that nothing flows into or out of. Living things and even hurricanes build and keep their structure because energy flows through them and they export the disorder; Prigogine called these dissipative structures, and contrasted them with equilibrium structures such as crystals, which hold their order without any further flow. A codebase under change is the first kind. A finished tool is closer to the second: it keeps its shape with little upkeep, as long as the code around it stays still. What flows through a codebase is change, and what carries the disorder back out is verification: reviewers, tests, checkers, and the tools that stay checked. While that verification is paid for, the structure holds. When it stops, each change pushes the codebase towards disorder, which for software means code that nobody understands.

17 Future work

These are the studies we would like to run, or to see someone run. Most need more compute, data or people than a working paper has, so if you can help with any of them, get in touch.

• The fleet sweepThe controlled experiment the trial above was a rehearsal for: one and twelve agents, with enough reviewers that review is not the limit, repeated enough times to tell linear scaling from the rival laws. The plan is public, and the sweep runs after a short pilot. A direct test of the review ceiling, one reviewer against several at twelve agents, is included if the budget allows.
• Bigger fleets, real codeThe same sweep at 24 and 48 agents, and on real codebases with real backlogs, where tasks overlap and depend on each other far more than in a sandbox.
• Agents reviewing agentsEscape rates for reviewers from different model families, alone and stacked, to measure how far their blind spots overlap and where a second reviewer stops paying for itself; and whether an agent reviewer, like a person, lets more through as its queue grows (section 10.1).
• Many projects, one teamA field study of a team running agents across several codebases for weeks, to test the per-codebase cap and measure what switching between projects costs the people checking the work.
• Where escaped changes goA longitudinal study of changes that passed review but were wrong: how long they stay hidden, and how much later rework they cause.
• Moving the limitBefore-and-after measurements of tools that raise verification capacity, starting with Candor (section 13.1).
• Human review of agent codeHow fast people can check agent-written changes, and how well, compared with the 200 lines an hour measured for human-written code.

18 Limits

This is a model, and its defaults rest on few studies, some from vendors. It assumes collisions between pairs are independent and that every agent’s changes are in flight alongside every other’s. It treats rework as one rate; counted per change, that understates it (section 3.1). Its collision term has now been tested once, on observational data, and mostly failed; the sizing formula was rewritten as a result. Speed-up curves for small teams of coding agents have been published, but no one has yet published a curve of merged, useful output against fleet size. Our one controlled trial shows review binding where the formula says it should, but it is a single trial, and the full sweep is still to run. We will publish its results here whichever way they come out.

References

1. Ananthanarayanan, S. et al. Keeping master green at scale. EuroSys, 2019.
2. Bennett, C. H. Dissipation-error tradeoff in proofreading. BioSystems, 1979.
3. Bennett, C. H. The thermodynamics of computation: a review. International Journal of Theoretical Physics, 1982.
4. Bertalanič, B., Fortuna, C. The Ringelmann effect in multi-agent LLM systems: a scaling law for effective team size. 2026.
5. Bhati, H. Beyond code generation: reliability, verification, and cost economics in the agentic software development lifecycle. 2026.
6. Brooks, F. P. The Mythical Man-Month, ch. 2 and 11. Addison-Wesley, 1975/1995.
7. Casserini, M., Facchini, A., Ferrario, A. Beyond the “diff”: addressing agentic entropy in agentic software development. 2026.
8. DORA. Accelerate State of DevOps Report. 2024.
9. Drake, J. W., Charlesworth, B., Charlesworth, D., Crow, J. F. Rates of spontaneous mutation. Genetics, 1998.
10. Drummond, D. A., Wilke, C. O. The evolutionary consequences of erroneous protein synthesis. Nature Reviews Genetics, 2009.
11. Ehsani, R., Pathak, S., Rawal, S., Al Mujahid, A., Imran, M. M., Chatterjee, P. Where do AI coding agents fail? An empirical study of failed agentic pull requests in GitHub. MSR, 2026.
12. Faros AI. The AI productivity paradox report. 2025.
13. Goldratt, E. M., Cox, J. The Goal. North River Press, 1984.
14. Gunther, N. J. A general theory of computational scalability based on rational functions. 2008.
15. Gunther, N. J. Modeling the Mythical Man-Month. 2007.
16. Hassan, A. E. Predicting faults using the complexity of code changes. ICSE, 2009.
17. Hopfield, J. J. Kinetic proofreading: a new mechanism for reducing errors in biosynthetic processes requiring high specificity. PNAS, 1974.
18. Hopfield, J. J., Yamane, T., Yue, V., Coutts, S. M. Direct experimental evidence for kinetic proofreading in amino acylation of tRNA^Ile. PNAS, 1976.
19. Hopp, W. J., Spearman, M. L. Factory Physics. McGraw-Hill, 1996.
20. Jones, C. Software defect origins and removal methods. 2012.
21. Kemerer, C. F., Paulk, M. C. The impact of design and code reviews on software quality. IEEE TSE, 2009.
22. Khailo, M. Why adding more AI agents makes your team slower. 2026.
23. Kim, E., Garg, A., Peng, K., Garg, N. Correlated errors in large language models. ICML, 2025.
24. Kim, Y. et al. (Google Research, Google DeepMind, MIT). Towards a science of scaling agent systems. 2025.
25. Kingman, J. F. C. The single server queue in heavy traffic. Mathematical Proceedings of the Cambridge Philosophical Society, 1961.
26. Kononenko, O., Baysal, O., Guerrouj, L., Cao, Y., Godfrey, M. W. Investigating code review quality: do people and participation matter? ICSME, 2015.
27. Kunkel, T. A. DNA replication fidelity. Journal of Biological Chemistry, 2004.
28. Kwa, T. et al. (METR). Measuring AI ability to complete long software tasks. 2025.
29. Landauer, R. Irreversibility and heat generation in the computing process. IBM Journal of Research and Development, 1961.
30. Lehman, M. M. Laws of software evolution revisited. EWSPT, 1996.
31. Li, H., Zhang, H., Hassan, A. E. The rise of AI teammates in software engineering (SE) 3.0 (the AIDev dataset). 2025.
32. Li, J., Gu, Z., Cai, Y., Feng, H. Scaling behavior of single LLM-driven multi-agent systems. 2026.
33. Liang, J. The novelty bottleneck. 2026.
34. Lin, W. (Cursor). Scaling long-running autonomous coding. 2026.
35. Mathews, K. (Electric). Amdahl’s law for AI agents. 2026.
36. METR. Many SWE-bench-passing PRs would not be merged into main. 2026.
37. Mieczkowski, E. et al. Language model teams as distributed systems. 2026.
38. Mikaduki, S. When more agents hurt: generalized Amdahl bounds for speculative parallelism in agentic software pipelines. TechRxiv, 2026.
39. Nachuma, C., Zibran, M. When AI teammates meet code review: collaboration signals shaping the integration of agent-authored pull requests. MSR, 2026.
40. Ninio, J. Kinetic amplification of enzyme discrimination. Biochimie, 1975.
41. Ogenrwot, D., Businge, J. AgenticFlict: a large-scale dataset of merge conflicts in AI coding agent pull requests on GitHub. 2026.
42. Park, J., Kim, M., Ray, B., Bae, D.-H. An empirical study of supplementary bug fixes. MSR, 2012.
43. Prigogine, I. Time, structure and fluctuations. Nobel lecture, 1977.
44. Reinertsen, D. G. The Principles of Product Development Flow. Celeritas, 2009.
45. Sarkar, D. Before the pull request: mining multi-agent coordination. 2026.
46. Śliwerski, J., Zimmermann, T., Zeller, A. When do changes induce fixes? MSR, 2005.
47. SmartBear. Best practices for peer code review (SmartBear/Cisco study).
48. Stroebl, B., Kapoor, S., Narayanan, A. The limits of inference scaling through resampling. 2024.
49. Szilard, L. On the decrease of entropy in a thermodynamic system by the intervention of intelligent beings. Zeitschrift für Physik, 1929 (English translation in Behavioral Science, 1964).
50. Tan, K. H. The verification bottleneck in AI-accelerated knowledge work: queueing epistemics, verification capacity, and adaptive human oversight. Open Access Journal of Multidisciplinary Research 2(9), 2026.
51. Thompson, R. C., Stone, P. J. Proofreading of the codon-anticodon interaction on ribosomes. PNAS, 1977.
52. Walter, P., Ron, D. The unfolded protein response: from stress pathway to homeostatic regulation. Science, 2011.
53. Xu, G., Subramanian, A., Karthik, N. AI agent pull requests on GitHub: frequency, structure, and merge conflict rates. 2026.
54. Yin, Z., Yuan, D., Zhou, Y., Pasupathy, S., Bairavasundaram, L. How do fixes become bugs? ESEC/FSE, 2011.

Revisions

This is a working paper and will change as the evidence comes in. Corrections are marked as corrections and say what was wrong.

• 1 October 2026 Section 1 is now "The formula": the sizing formula moved into it, after a paragraph on where its three equations come from.
• 30 September 2026 Added section 10.1: review escapes rise when reviewers hurry, what that does past the review limit, and how to read equation 7 and the rule of thumb in its light. The controlled experiment's plan brought up to date: one agent against twelve with reviewers to spare, after a short pilot, and the review-ceiling test if the budget allows. Future work now asks whether an agent reviewer, like a person, lets more through as its queue grows. Added section 3.1: returns cluster, so the rework rate r counted per change is a floor; no knock-on was found in review, and abandonment is unresolved.
• 29 September 2026 First published as a working paper.