How many coding agents can one team actually run?

Stefan-Iulian Tesoi · 17 September 2026 · 6 min read

How many coding agents one person can run is decided by two human queues: writing the work before an agent starts, and reading what came back after it finishes. Neither is compute, both are the same person, and the limit is whichever fills up first. Counting only the second is why the usual answer of two or three tends to disappoint.

The reason this matters more than it looks is that the wrong constraint is cheap to buy more of. Another agent costs a subscription. Another hour of specification costs an hour.

What limits how many coding agents you can run?

The rate at which specified work arrives, and the rate at which returned work is accepted. An agent sits between them and can do neither.

This is an old shape with a new cast. GNU Make's parallel execution has warned for decades that -j beyond what the machine can feed does not go faster and often goes slower, which is why it also offers a load limit rather than only a job count. Agents are the same: -j 6 against a build that can only produce two jobs' worth of input is six processes waiting.

So the useful question is not how many agents a licence allows. It is how many specified items a day the team can produce, and how many returned diffs a day it can accept.

The two queues, and why only one gets counted

Specification runs ahead of the agents; review runs behind them. Teams measure the second because it is visible, and the first is where the ceiling usually is.

The asymmetry is the whole thing. A review backlog is a stack you can see and a number someone will quote in a standup. An empty specification queue looks like agents being quiet, which reads as an agent problem rather than a person one — and the usual response is to add another agent, which makes the queue emptier per agent rather than fuller.

What breaks first when you add another one?

Specification, and earlier than the arithmetic most people have done.

Take one agent finishing an item every forty minutes or so. Fed continuously, that is ten to twelve items a day. Reviewing each against criteria written in advance takes ten to twenty minutes, so a single agent generates roughly three hours of review. That is where the familiar figure comes from: on review alone, one person saturates at about two agents, maybe three.

Now count the other queue. Writing an item well enough that an agent can execute it without a follow-up question takes most of an hour. Twelve items a day is therefore eight hours of specification for the same one agent — before any of it is reviewed. A person with perhaps five focused hours for this work produces five or six specified items a day and can review them comfortably.

Counting review alone, one person supports two or three agents. Counting both queues, one person supports about one — and that one spends half its day waiting. The agent supervision ratio everyone quotes is the ceiling of the queue that is easier to see.

Which is not an argument against parallel AI agents. It is an argument that the second agent is worth adding only once something other than a person is drafting the items, because until then the second agent divides a supply that was already short.

How do you raise the ceiling without lowering the bar?

Take work off the two human queues in the order they bind: drafting first, then review, then batch size.

The tempting alternative is to lower the bar — accept on the summary, skip the criteria, let items go out vaguer. That raises the number of agents you can run and lowers the number you should, because unspecified work comes back as plausible wrong work and lands in the review queue twice.

Four things that actually move it, in the order they pay:

1. Draft the items rather than typing them. This is the binding queue, so it is the only lever that changes the number rather than the comfort. A draft a person corrects in five minutes replaces forty minutes of writing and keeps the judgement where it was.
2. Make criteria mechanically checkable. A criterion naming a command and an expected result turns twenty minutes of review into two, because re-running it is the review.
3. Attach the evidence to the item. Most review time is reconstructing what an agent did from a diff. Having the commands and their outcomes on the item removes that work rather than speeding it up.
4. Shrink the items. A diff nobody finishes reading is a diff nobody checked, and small items also fail earlier, which shortens the loop when the specification was wrong.

Only the first changes how many agents can be fed. The other three raise how many can be accepted, which matters once drafting has stopped being the constraint — and not before.

This is the work Laimonade does: drafting items with criteria, paths and dependencies already in them, and reading returned work against the criteria the item was accepted on. A person still decides what is worth building and still closes it — an agent reaches In Review and no further. That division is what lets the first queue be automated without the second becoming a rubber stamp. What this means for the person holding a team is set out in for engineering leaders, the mechanics are in the sprint workflow, and the role itself in what an AI product owner actually does.

Scaling coding agents therefore has a fixed order: fix the supply of specified work, then the cost of accepting it, then add agents. Teams that reverse it buy compute to sit idle, which is the cheapest thing on the list and the least useful. The wider shape this fits into is in the coding agent workflow a team can actually run.

Frequently asked questions

Does running more agents always increase throughput?

No, and past the constraint it reduces it. An extra agent draws from the same supply of specified work and adds to the same review queue, so beyond the limit you get more work in progress, more context switching for the reviewer, and the same completion rate. The symptom is agents finishing quickly and items sitting in review for days.

Can agents work on the same repository at once?

Yes, with a worktree each. They must not share a working directory: two agents in one checkout share its HEAD, so when one switches branches the other's uncommitted work travels with it, silently. Overlapping work is a separate problem and belongs in the backlog as a dependency, not in the tooling.

What is the first thing to automate to add capacity?

Drafting the items, because that is the queue that binds first. Automating review before specification produces faster acceptance of work that was underspecified, which is the expensive direction — the defects that come back are the ones criteria would have caught, and they return as rework rather than as a rejection.

Is the answer different for a solo founder?

The ceiling is lower and arrives sooner, because one person holds both queues with no one to hand either to. The arithmetic is the same and the slack is not: a team of four can absorb a bad week in specification, and a founder cannot. Start with one agent and a genuinely executable backlog rather than three and a hopeful one.