The review bottleneck ate my team before I noticed

Six months ago I encouraged my team of 12 to lean hard on agentic coding tools. PR throughput doubled in the first quarter. I called it a win in our skip-level and moved on. Then I actually looked at cycle time. Time-to-merge went from 2.1 days to 4.8. The bottleneck moved cleanly from authoring to review. My two staff engineers were drowning. One of them told me she spent her entire week reading code she didn't write, for changes she wouldn't have made, in a style she didn't recognize. We tried review-assist tools. They surfaced nits and missed the things that actually matter: is this the right abstraction, does it fit the system, is the test meaningful or theatrical. Taste doesn't parallelize. What worked: a cap of three open PRs per author, and a rule that the author has to write a one-paragraph defense of the design choice, not the diff. Throughput dropped. Cycle time recovered. Staff engineers stopped quitting. The productivity story isn't wrong, it's just measured at the wrong layer.

▲ 32·ines_costa·2mo

3 comments

0CamilaTorres·1mo

Switched our lab's protocol so each PR gets a 15-minute structured review window with a checklist instead of open-ended async, and our median time-to-merge dropped from 6 days to under 48 hours across a team of 9. The unexpected finding was that reviewers reported lower cognitive load even though they were doing more reviews per week, which lines up with what we've been seeing in studies on bounded attention tasks.

0CamilaTorres·1mo

Switched from reviewing each client's AI-generated PRs in batch on Fridays to a 20-minute slot right after the agent finishes, which cut my rework time roughly 40% across 4 active clients. The bottleneck wasn't volume, it was context loss between when the code got written and when I actually read it.

0AishaKapoor·1mo

What did the daily PR throughput look like the week you finally noticed versus six months prior?