Adding coding agents can increase the number of proposed changes before it increases the number of changes a team can safely deliver. If review capacity stays fixed, the immediate result may be a longer queue, more interrupted reviewers and more code waiting to become useful. The management decision is how much work to start, and what evidence each proposal must bring with it.
GitHub's November 5 account of its new Git storage architecture includes an internal test with 5,000 concurrent agents and 7,200 pushes per second. That is evidence about a storage workload under GitHub's test conditions. It does not measure reviewed pull requests, successful deployments or business value. GitHub's architecture report
For an agency or product team, the useful comparison is closer to home: how quickly reviewable proposals arrive, how quickly they receive a decision, and how much rework comes back. A simple queue worksheet can reveal whether more generation capacity will help the current bottleneck.
- 01Separate activityCount pushes, proposals, review decisions and accepted changes separately.
- 02Watch the queueA sustained arrival rate above review capacity creates a growing queue, even when every agent works quickly.
- 03Make changes reviewableSmall, self-contained changes need enough context and verification to be reviewable.
- 04Charge for reworkRework consumes capacity and must remain visible instead of being counted as new output.
- 05Control concurrencySet agent concurrency from downstream capacity and change risk, then adjust using observed outcomes.
01 — Work definitionDefine the unit of work before measuring productivity
A push is a repository operation. A pull request packages proposed work. A review decision may approve that work, request changes or reject it. A deployment can include several approved changes or none of the latest proposals. Treating these events as interchangeable makes an activity dashboard look like a delivery dashboard.
Choose a stable unit for the question you are answering. To investigate a review bottleneck, start with a proposal that is ready for a named person to review. A draft with missing tests or unresolved scope does not belong in the same arrival count as a complete proposal.
Record what makes a proposal ready: a clear objective, bounded scope, relevant verification and enough explanation to assess the change. Keep the definition consistent across human and agent authors. Otherwise, a rise in “ready” work may simply reflect a lower admission standard.
Next, define the outcomes. Accepted, rejected, superseded and returned for rework are different dispositions. A declined duplicate can leave the queue without creating a delivered feature. That may still be the correct decision, but it is not equivalent to a successful release.
Our guide to AI code review automation covers review tools and checks. Capacity analysis asks a separate question: whether the team can absorb the amount and complexity of work those tools produce.
02 — Queue arithmeticCalculate the queue before adding another agent
Use a transparent hypothetical example. Suppose 40 new proposals become review-ready each working day, and the team can complete an initial review of 30. Starting with an empty queue, and assuming no withdrawals or other changes, ten proposals remain unreviewed at the end of day one.
| Day | New ready proposals | Initial reviews completed | Awaiting initial review |
|---|---|---|---|
| 1 | 40 | 30 | 10 |
| 2 | 40 | 30 | 20 |
| 3 | 40 | 30 | 30 |
| 4 | 40 | 30 | 40 |
| 5 | 40 | 30 | 50 |
This is arithmetic, not observed team performance. The calculation is ending queue = starting queue + arrivals − initial reviews completed, assuming the result cannot fall below zero.
It also makes a deliberately narrow claim. The 150 completed initial reviews are not necessarily 150 accepted changes. Some proposals may need revision, be declined or duplicate existing work. A separate queue is needed for proposals awaiting another review after changes.
If rework uses the same reviewers, the assumed capacity of 30 fresh initial reviews may be impossible to sustain. Measure available reviewer time across all their work, including incident response, planning and mentoring. Do not allocate their entire working day twice.
The example shows why adding another generator can make delivery slower in elapsed time. It increases arrivals to a constrained stage. The remedy depends on whether that stage lacks capacity, receives unsuitable work or spends time reconstructing missing evidence.
03 — Review timingSeparate review effort from waiting time
Two proposals can each take three days from submission to approval for very different reasons. One may wait almost the entire period for a reviewer and require twenty minutes of inspection. Another may involve hours of investigation, revisions and discussion. Those cases call for different interventions.
Track active review effort separately from elapsed waiting time. Active effort helps estimate staffing and the cost of difficult changes. Waiting time shows how the work competes for attention and how predictable the process is for authors and customers.
A compact record should include the first ready time, first substantive review, requested changes, author response and final disposition. Record why work returns: a defect, missing verification, unclear requirements or an intentional change in scope. Those reasons are more useful than a single count of review comments.
Avoid interpreting a large comment count as quality or a small count as efficiency. Some comments catch important mistakes; others reflect ambiguity that could have been resolved before implementation. The metric needs the outcome attached to it.
Measure the distribution as well as the average. One proposal waiting for a specialist can age while easier work moves through quickly. Group by relevant change types, such as presentation changes, dependency changes and data migrations, so the aggregate does not hide a persistent queue for higher-consequence work.
This measurement does not require intrusive monitoring of individuals. A shared workflow record can identify capacity constraints without converting review into a competition over speed.
04 — Proposal qualityMake proposals easier to assess without hiding risk
Reviewers need to understand what changed, why it changed and what evidence supports it. An agent can help by producing a concise change description and relevant verification results. More prose is not automatically more evidence: a long generated explanation can increase inspection time if it repeats the diff or asserts conclusions without support.
Google's engineering guidance recommends small, self-contained changes because they are easier to understand and review thoroughly. It also stresses that a change should make sense on its own. This is engineering guidance, not a measured estimate of AI-related productivity gains. Google's guidance on small changes
Apply that principle to agent assignments. A proposal that changes validation, database structure, permissions and interface behaviour may require several kinds of expertise. Splitting independent work can help; splitting a single invariant across disconnected changes may make it harder to assess.
Use a short review contract for each task. State the concrete trigger and expected behaviour, the files or components likely to change, and the evidence needed to demonstrate success. Require authors to identify important limitations rather than burying them in a generic checklist.
Complete the evidence
For example, a form correction might need a reproduction of the failing input and evidence of the corrected result. A data migration needs a different level of validation and recovery planning. Uniform paperwork for every task wastes attention, while uniform minimal checks conceal meaningful risk.
Match the checks
The aim is to reduce avoidable reconstruction work while preserving the reviewer’s ability to challenge the implementation.
05 — Shared capacityBudget for rework and conflicting changes
Parallel agents can create independent proposals that compete for the same files, assumptions or release window. Isolation protects working directories, but it does not guarantee that the resulting changes agree. Two agents can each implement a reasonable solution to different interpretations of the same requirement.
Give each task a clear owner and define overlapping responsibilities before dispatch. If changes share a contract, settle that contract early. Review the dependent work in an order that makes the combined behaviour understandable.
Our guide to worktree isolation for parallel coding agents addresses separate working environments. The review queue still needs explicit coordination of shared interfaces, migrations and configuration. A clean merge is not proof that two changes work correctly together.
Include rework in the capacity model. In a second hypothetical example, assume a team has 300 review minutes available in a day. If returning proposals consume 90 minutes, only 210 remain for first reviews. At an assumed seven minutes per first review, that supports 30 new reviews—not the roughly 43 implied by assigning all 300 minutes to fresh work.
Those minute values are illustrative. Real review times vary, and a single complex change may exceed the allowance. The point is to allocate one finite pool of time across all demands rather than treating re-review as free.
When rework repeatedly comes from the same cause, improve the task or evidence contract. Increasing reviewer capacity without correcting recurring ambiguity can simply fund a larger loop.
06 — Intake controlUse concurrency as a control, not a target
The number of agents running simultaneously is an input to the delivery system. It is not an achievement by itself. Increase it when downstream stages can absorb the additional work and the selected tasks are sufficiently independent.
Set a limit on proposals waiting for review as well as a limit on agents executing. If the ready queue reaches its agreed bound, route available effort toward revising existing work, clarifying upcoming tasks or reducing a known source of review delay. Starting another implementation should be a deliberate decision.
Keep the limit sensitive to complexity. Ten small content changes and ten access-control changes can represent very different review obligations. A simple team can begin with separate limits for ordinary work and work requiring specialist approval, then refine them as evidence accumulates.
Avoid solving a full queue by automatically approving the oldest proposal. Age indicates delay, not correctness. If something is stuck, identify whether it lacks an owner, evidence, a decision or a dependency.
An admission rule can be as straightforward as: an agent starts a new implementation only when its current proposal has an owner and the relevant review queue has room. This preserves useful parallelism without allowing unlimited work to accumulate invisibly.
The appropriate limit is local. There is no universal number of agents per developer that follows from a storage throughput benchmark, a model evaluation or another company's organisation chart. Adjust the limit using your own arrival rates, review outcomes and delivery requirements.
07 — Review assistanceEvaluate review assistance by accepted outcomes
Automated checks and AI review can screen proposals before a person examines them. The relevant question is whether they reduce total effort while preserving the required standard, including the work caused by incorrect findings and missed defects.
Give each tool a defined role. A deterministic check can enforce a known rule; a model can propose concerns that require examination. Keep the distinction visible in the review record. A confident explanation does not establish that a reported issue is real.
Use a fixed sample of representative changes to assess assistance. Record valid findings, invalid findings, material misses and the time required to resolve them. Include a consistent definition of a material issue so the comparison does not reward large volumes of trivial comments.
If a generated fix is applied, verify the changed behaviour. A proposal to repair a defect can introduce another defect, and a successful check of the original version does not validate the edited version.
For the business comparison, use cost per successful task alongside review effort and quality outcomes. Counting comments or generated patches alone cannot establish that the organisation delivered more useful work.
A limited rollout can compare matched work categories over a defined period. Preserve rejected proposals and failed checks in the record. If the tool speeds easy reviews but adds work to complex ones, a narrower deployment may be more useful than a single team-wide setting.
08 — Delivery decisionsBuild a weekly delivery picture that leads to action
A useful review dashboard can remain small. It should make visible where work waits, how much requires another pass and what ultimately becomes an accepted change. Avoid dozens of metrics that nobody uses to change a decision.
| Signal | Question it answers | Possible response |
|---|---|---|
| Ready proposals arriving | How much work enters review? | Adjust new task intake |
| Queue age by change type | Where does work remain stuck? | Assign ownership or expertise |
| Returns by cause | What creates repeated effort? | Improve requirements or evidence |
| Accepted changes and defects | Is delivery improving safely? | Refine checks and rollout scope |
Read these signals together. A shrinking queue could mean faster decisions, fewer arrivals or more rejected work. A higher acceptance count could reflect smaller changes rather than more customer value. Explain the cause before announcing a productivity improvement.
Choose one intervention at a time when possible. If the team changes its model, concurrency, task selection and review rules simultaneously, it becomes difficult to tell which change affected the result. Where changes must coincide, record that limitation instead of claiming a clean experiment.
For an agency, connect the delivery picture to client commitments. More proposals do not help if approved work misses a launch because a critical review was never scheduled. Plan specialist attention and release dependencies as deliberately as implementation time.
The weekly decision should be specific: admit more work, reduce parallel starts, improve proposal evidence, assign a reviewer or change the task mix. That is how measurement becomes useful management rather than a report of activity.
Match new starts to the work reviewers can absorb
Before adding more coding agents, count the work already waiting for review and the time available to assess it. Define review-ready proposals, keep rework visible and use a queue limit that matches real capacity. Increase generation when it helps accepted delivery, with the quality standard intact.
Digital Applied's web development services can help structure agent-assisted implementation, review and release checks around the changes your business actually needs to deliver.