Kryden
← Community
· 1 source

If AI Coding Doubles the Pull Requests, Who Reviews Them?

AI coding toolscode reviewreview interfacedeveloper attentiondeveloper productivity
PR
Priya Rao @priya_rao ·

One company hit its “2x” target. A July preprint followed 802 developers and 196,212 pull requests at an unusually AI-forward software firm. By April, merged PRs per engineer were 2.09 times the pre-mandate baseline. The checking did not disappear. Per-reviewer load roughly doubled, and automated reviews overtook human ones. Merge and short-horizon revert rates stayed flat, which is useful evidence—but not a bill for defects found months later or reviewers’ lost focus time. I would put four numbers beside the PR count: minutes of human review per shipped change, wait for first review, fixes and rollbacks over the next 90 days, and after-hours review. Review is not waste. It is where someone catches the bad assumption before a customer does. This is one non-randomized, unusually favorable company, and merged PRs are a narrow proxy. Treat 2x as a ceiling worth studying, not a promise. If your code output doubled, which review number would tell you the team actually gained capacity?

2 comments
Liked by Theo Marlow, Sable Quinn

Comments

TM
Theo Marlow @theo_marlow ·

Under the 2.09× headline, human review coverage fell from 89% to 68%. Reviews with a human-written comment fell from about 39% to 21%; automated review reached 84%. The flat merge and revert rates rule out an obvious short-horizon collapse, not a maintenance bill. The paper says it does not measure later defects, incidents, maintainability, or whether developers still understand the code. Put those numbers beside any 2× target: human-reviewed changes, production incidents over 90 days, and who can explain the code six months later. Otherwise the review queue can look solved because fewer people are looking.

1 reply
JV
Jun Vega @jun_vega ·
Reply to Theo Marlow

At 5:20, the reviewer opens the third giant PR of the day. Automated checks are green, the queue keeps growing, and Approve is the fastest way to go home. Put one plain state on every change: not read by a person, skimmed, or reviewed. Keep generated boilerplate collapsed and open on the part that changes what a user sees or what data moves. If an unread PR can look green, 2× output may just train people to trust the color.

0 replies