Build1 publisher3 min readPublished
A six-person team's weekly review load grew 7.6x in a quarter
One engineer's quarter of data has median merge time going from 4 hours to 14 while median diff size climbed from 90 lines to 310, and the way both ends of the latency distribution moved points at PR size rather than reviewer saturation.
The Engineer · Build desk
What happened
- An engineer writing on dev.to logged a quarter of data from a six-person team, over which pull requests opened per week rose from about 31 to about 68.
- Median time-to-merge over the same period went from about 4 hours to about 14, with no change in the number of reviewers.
- The 90th percentile stretched from a day and a half to five days, so the slowest tenth of pull requests now span most of a working week.
- Adding an AI reviewer bot did not clear the queue; by the author's account it only added a second stream of plausible text for humans to read.
- What worked was policy: a hard diff-size cap, a mandatory section on what the author actually verified, and refusing to review code the author cannot explain in one sentence.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint On this team's numbers, upstream throughput gains land in the review queue rather than in production, so tooling that makes agents faster buys queue depth instead of shipped code.
- cost A diff-size cap moves the cost onto authors, who now have to decompose an agent's session output into reviewable units before any of it can land.
- exposure If generated tests inherit the implementation's misreading of the requirement, a green CI run no longer carries the weight that most merge gates are built to assume.
- decision Agent tooling purchases have to be scored on how much reading they remove from a human, which is a different question from how much code they produce.
Multiply the two series and the load looks worse than the PR count implies. Median diff size went from about 90 lines to about 310 over the quarter, according to the dev.to account [7]. At 31 PRs a week, that is roughly 2,790 lines of review surface. At 68 PRs of 310 lines, it is about 21,080 [8]. Arrivals rose 2.2x. The reading rose 7.6x [9][10]. Headcount stayed at six [1].
The author's explanation is utilisation: review capacity is fixed, queues are not linear, and moving reviewers from 60 percent busy to 90 percent busy costs a multiple rather than 30 percent [13][14]. Standard M/M/1 agrees on direction. Mean wait scales with rho/(1-rho), so 0.6 to 0.9 goes from 1.5 to 9, a factor of six [15]. For that to be the story here you would need Poisson arrivals, one pooled server, and no working-day boundary. A team that admits to leaving nine open PRs alone until a clear block appears has none of the three [16].
The two latency numbers point somewhere else. The median moved 3.5x, from 4 hours to 14 [11]. P90 moved about 3.3x, from 36 hours to 120 [12]. Saturation stretches the tail faster than the middle; a distribution that scales by the same multiple at both points looks like service time inflation, which is exactly what a median diff going from 90 to 310 lines is, especially if review effort is superlinear in size as the write-up argues [17]. That is also why the cap on diff size was the intervention that worked. It attacks minutes per PR rather than PRs per week, and it breaks the bundling loop in which slow reviews teach authors to open bigger PRs [18][19].
The bot result is the more useful finding. A second reviewer that emits text adds no acceptance capacity, because the scarce thing is a human willing to say the change is correct [20]. Four properties of generated diffs make that harder to reach: even confidence with no rough edges to follow [21], no author intent to interrogate, which leaves the reviewer as the only judgment in the pipeline [22], code written to work rather than to be small [23], and generated tests that encode the same misunderstanding as the implementation, so a green CI run stops being evidence [24].
Provenance is one engineer, six people, one quarter, self-reported, no error bars, and the claim that generation got roughly 5x cheaper in a year is asserted rather than sourced [25]. What transfers is the diagnostic, not the multipliers: put PRs opened per week and median time-to-merge on one chart for six months [26]. If arrivals rose while median diff stayed flat, the bottleneck really is utilisation, and a size cap will not move it.
The opening anecdote deserves its own arithmetic. A 1,140-line PR approved in forty minutes is about 28 lines a minute [2][3][27]. That is a reading rate, not a review rate.
What to watch
- Whether the diff-size cap survives changes that do not decompose cleanly, such as large refactors, and what exception rate the team ends up granting.
- A second quarter of the same two series, showing whether median merge time falls back toward 4 hours under the cap or settles at a new floor set by overnight batching.
- Another team publishing arrivals and merge latency with median diff size held flat, which would separate a utilisation problem from a service-time problem.