A team of four adopts coding agents. Each engineer runs three at a time instead of typing everything by hand. Nothing else about the team changes: same four people, same working day, same standards for what lands.
Writing capacity went up by something like a factor of three. Reading capacity went up by nothing, because reading is done by the same four people it was done by last month. Everything that follows is that ratio.
The arithmetic, with its assumptions on the table
This is a model, not a study. Run it with your own numbers and it is worth something; quote ours and it is worth nothing, because ours are illustrative.
Say a reviewer reads carefully at around 300 lines an hour, which is in the range long-standing review guidance uses, and gives two hours a day to review before the rest of the job takes over. That is roughly 600 lines a day, per person, of code that gets genuinely read rather than skimmed.
Now say each engineer runs three agents and each agent produces one changeset a day at 400 lines. That is 1,200 lines produced per engineer per day against 600 read. The team is not slightly behind. It is producing twice what it can read, every day, and the gap compounds because unread code does not expire.
- writing capacity
- 3x
- reading capacity
- 1x
- the daily gap
- 2x
Change any assumption you like. The conclusion survives all of them, because the only term that scales with agent count sits on top of the fraction. There is no setting of these numbers where adding agents adds a reviewer.
What a team does when the gap opens
Nobody announces the decision. Four things happen instead, roughly in this order.
Approval gets cheaper. The first few big agent changesets get real attention. The tenth gets a scroll and a thumbs up, and the habit sets before anyone notices it forming.
Trust moves to the checks. Green CI starts standing in for a read, which is fine for the questions CI answers and useless for the ones it does not. Whether the change belongs in that file. Whether an error case got swallowed on the way past.
Then review concentrates on one person, usually whoever cares most, who becomes the bottleneck and then gets tired of being it.
And the queue quietly changes species. It stops being a queue of pull requests and becomes a queue of unread ones. On a dashboard those look identical.
Three responses, two of which do not work
Slow the agents down. This works, and nobody does it, because it gives up the one thing agents were adopted for. Worth saying out loud anyway, so the option is on the table instead of quietly ignored.
Read faster. This does not work. Reading rate is close to fixed, and skimming is not a faster read, it is a different activity with a worse error rate.
Move the read earlier and make it cheaper. This is the only lever with any room in it. A changeset read while the work is still a git worktree costs a sentence to correct, because nothing has been committed to yet. The same changeset read after a pull request exists costs a round trip through somebody else's head, on a task they left three hours ago.
What actually reduces the cost per changeset
Four things, in the order they pay off.
- 1
Scope each agent to one task
A changeset you can hold in your head comes from a prompt that asked for one thing. Costs nothing but discipline.
- 2
Put the acceptance criteria in the prompt
Then the mechanical question is answered before a human opens anything, and attention goes to judgement, which was the only part it was needed for.
- 3
Resolve compile, tests, and branch state before the reviewer arrives
A reviewer establishing those by hand for ten changesets spends the whole budget on bookkeeping and never reaches the code.
- 4
Send the correction to the agent, not to the code
A note on a diff line that becomes the agent's next prompt costs a sentence. Fixing it by hand costs your afternoon.
Where Cohalen fits, stated plainly
Cohalen is built for the reading half rather than the launching half. Every agent's changeset arrives on one surface with the mechanical checks already resolved, an outline of what changed, and notes that go back to the agent as its next prompt. On a team, a colleague's workspace streams in live and read-only while the work is still a worktree, so the read can happen before a pull request exists rather than after.
If your bottleneck is reading rather than writing, Cohalen is the tool built for that bottleneck. The limits: the team surface needs an account, and Cohalen is in early access.
Questions people ask about review and agents
Why is code review the bottleneck when using AI coding agents? Because agent adoption multiplies writing throughput and leaves reading throughput unchanged. The people reading are the same people, working the same hours, at the same reading rate.
How many lines of agent-written code can a reviewer read in a day? Careful review runs in the low hundreds of lines an hour, so a couple of hours a day is a few hundred lines read properly. Any number of agents can exceed it.
Does green CI mean an agent changeset is safe to approve? It means the mechanical questions passed. Whether the change belongs where it landed, and whether an error case was swallowed, are not questions CI asks.
What is the cheapest way to cut review time? Scope each agent to one task and state the acceptance criteria in the prompt. Both are free, and both shrink the changeset before anyone has to read it.