Code review when four engineers merge 844 PRs a month
Published 2026-07-27 by Fredrik Wollsén
In June 2026 the four-engineer team I lead at F-Secure opened 892 pull requests and merged 844 of them, which is 95%. I opened 500 of those myself and merged 490. We have been operating this way since September 2025, and the monthly team total has gone 33, 158, 229, 242, 217, 318, 211, 273, 354, 618, 892 over eleven months.
The correct first reaction to that number is suspicion, and I had it too. Published benchmarks put a median developer somewhere around 1.2 to 1.4 merged PRs a week, and the elite band at roughly 2 to 2.5, so 892 from four people is off the end of every curve I can find. Either we're doing something categorically different or we're counting something that isn't there, and the only way to tell the difference is to look at the PRs one at a time.
So we did, and this post is what that found, including the parts I'd rather it hadn't.
Whether they're real PRs
The obvious failure mode is that high PR counts are an artefact — commit-sized fragments, or the same work split eight ways to make a graph look good. Title regexes can't tell you that, because the question is about what a change is, not what it's called, so the classification has to happen per PR and in the context of its neighbours.
The method has two stages. First a deterministic pre-grouping into candidate work units: union-find over cross-references in PR bodies, plus adjacency by same author, same scope, 48-hour window and file overlap, plus revert and re-land pairs matched up. Then 32 parallel LLM agents triaging each unit against a written rubric, which took about 2M tokens and roughly seven minutes and cost less than lunch. The method and the rubric are version-controlled, so it re-runs every month rather than being a thing we did once to win an argument.
What it says about June:
- The 892 raw PRs collapse to about 577 logical work items, and to about 739 traditional-PR-equivalents once you account for fragmentation. Fragmentation in the hot workstreams runs around 1.46×, so a 31-PR feature build-out is really about 15 changes. Bundling in the other direction was rare, with only 15 PRs carrying two or three PRs' worth of work.
- Median merged PR is 122 lines across 3 files. LinearB's "good" band is 100 to 155 lines, and the classic open-source median is about 20, so these are normal-sized changes rather than micro-commits. The mean is 482 lines and 37% of PRs are over 200.
- On substance, 30% of standalone PRs are trivial or mechanical, 54% routine, and 17% substantial in the sense of carrying real design judgement.
- Net of rework, about 620 useful traditional-PR-equivalents from four engineers, which is roughly 155 per engineer per month.
There's a coherence check that made me trust the numbers more than the numbers themselves did. Measured independently with scc, the codebase grew by 94,000 net lines in June. Divided by 739 equivalents that's 127 lines each, against the triage's measured median of 122, and those two came from methods that don't know about each other.
The part I'd rather not report
Reverts were 2, which is 0.2% of merged PRs, and if that were the only quality number I looked at I'd conclude we were flying. Going PR by PR says something else: at least 16% of PRs inside active workstreams are self-inflicted rework, meaning 70-odd PRs fixing something a sibling PR had just shipped. That's a floor rather than a ceiling, because rework that crossed between work units went untagged. On top of it, 21 PRs were review-driven polish and 11 were requirements moving underneath us.
The framing that survived being argued with internally is that this is iteration made visible. A traditional team does the same iterating in private, on local branches and across review rounds and force-pushes, where no metric ever sees it. When merging is the cheapest checkpoint you have, the iteration lands in public as merged PRs and shows up in your own statistics. I believe that, and I'd also say it's the kind of explanation that would be very convenient if it were wrong, which is why the trend line matters more than the number: if self-inflicted rework starts growing faster than throughput, that means we're merging faster than we're verifying, and that's a real problem rather than a presentational one.
The other half of the control loop is production rollbacks and incidents. Deploys went 12, 17, 32 across April, May and June, so delivery roughly doubled month over month while PR volume grew 44%, and that ratio is about 26 merged PRs per production deploy. When those numbers turn, the response is to improve the skills and guardrails so the mistake can't recur, rather than to add another human reading another diff, because adding human reading is the one response that definitely doesn't scale.
What we actually changed about reviewing
Reading every line of 844 PRs a month is not something four people can do, and pretending otherwise would just move the lie somewhere less visible. What we do instead:
PRs get a directional review rather than a line-by-line one. The question is whether this is the right change and whether it fits the architecture, and most of the time that takes about thirty seconds and the answer is yes. A one-line feature flip can carry more weight than a 900-line refactor that changes no behaviour, so scaling review time with diff size stopped making sense the moment average PR size dropped and count went up.
The heavyweight human review happens at the production deploy gate, a couple of times a week, and policy requires it to be a different person than whoever is deploying. That's the checkpoint where someone reads carefully, and it's positioned at the last reversible moment rather than at every intermediate one.
Authors drive the change end to end before review, human or agent alike — scripted browser flows, integration tests, and a rule we had to learn the hard way: verify the mechanism, not the outcome. An agent will report success on ambiguous evidence with total confidence, so "the page loads and the value looks right" is not evidence that the code path you think you changed is the code path that ran.
AI reviews AI, continuously. Automated diff review on every PR, adversarial multi-agent verification where independent agents are prompted to refute the findings rather than confirm them, and the ordinary CI wall of types, lint, tests, SAST and end-to-end.
Humans own the irreversible things without exception: contracts, data models, security boundaries, migrations, anything that can't be walked back with another PR.
Do we understand every line that ships? No, and I don't think there's a version of this volume where we do. What we own is the shape of the system and everything that's expensive to undo, and the honest description of the rest is that it's verified by machinery rather than read by people.
Where this sits against everyone else's numbers
The published research on AI-assisted engineering measures something much smaller than this. Copilot randomised trials across 4,867 developers found 8 to 26% improvements. DX's telemetry across 51,000-plus developers found daily AI users up about 60%. The METR trial found experienced open-source developers were 19% slower while believing they were 20% faster, which is the study I'd point at first if I wanted to argue against myself. DORA's 2024 report found a slight org-level decline alongside AI adoption.
None of those predict 155 useful PR-equivalents per engineer per month, and I don't think they're wrong. They're measuring assisted typing, and this is a different operating mode — five to ten agents per engineer working in parallel all day, where the engineer's job is briefing and directing rather than writing. The claim I'd defend is "observed outlier off every published curve, with the receipts attached", and not "AI made me twenty times better at my job."
The only public numbers that look like ours come from the company that makes the model. Anthropic have published that their engineers ship about 8× more code per quarter against their 2021–2025 baseline, and that over 80% of code merged to production there is authored by Claude as of May 2026. They also say the 8× figure is "almost certainly overstated" and that lines of code is a vanity metric, which is the same posture the triage above is trying to take. And the conclusion they report is the one I'd underline: the cost of producing code collapsed, and the constraint moved to review and verification.
Caveats, because they matter more than the headline
Useful PR-equivalents are not the same denominator as the benchmarks' merged PRs — our mix includes docs work, and our review loop is four people who are all awake at the same time rather than a formal process. Vendor benchmarks skew toward the kind of organisation that buys metrics tooling. The 16% rework figure undercounts, since cross-workstream rework went untagged. Both PR counts and lines of code are inflatable by an AI that wants to look busy, which is the entire reason the triage, the deploy count and the rework cut exist. And our own before-and-after isn't a clean experiment, because the whole industry has been ramping AI tooling underneath us the whole time.
My personal anchor is the cleanest comparison I have. In the years before this I shipped 5 to 10 PRs a week, which is exactly the published elite band, at a median PR size six times larger than the classic open-source median. Same person, same rough PR size, now around 36 a week.
If your team is somewhere on this curve and reviewing has become the thing that hurts, I'd like to hear what's working for you. Find me on LinkedIn, or read how the parallel-session practice works day to day.