The Multiplier and the Bottleneck Are the Same Job

Coding agents do not spread evenly. The engineers who already know the system, the failure modes, and what done looks like get a genuine multiplier. Everyone else gets a faster way to produce diffs that still need a judgment call. That is not a training problem you solve with a lunch and learn. It is a capacity problem, and it shows up in the merge queue.

Look at who is sitting on both sides. The senior engineers running agent sessions all day are the same people the organization trusts to approve a change. Product managers are now expected to land pull requests, not just write the spec. The set of people producing code just got wider. The set of people allowed to merge it did not. If agents increase output by an order of magnitude, the review load lands on a handful of humans who are already the most productive generators in the building. You cannot ask them to type faster at review. There are not enough of them. Google’s engineering guidance puts team velocity ahead of individual coding speed and warns that slow reviews delay the whole team’s work.^[1]

Generation feeling solved is a warning, not a victory. The queue only stays attached to engineering judgment if no human sees the pull request until it has been beat up by other agents: tests, a security pass, a second run that argues with the first. That is not a polish step once seniors are the scarce resource. It is the only way their attention survives contact with the volume. Human approval still matters. It should arrive after the software has already done the first several rounds of rejection.

Stop treating review as the senior engineer's leftover hours. Put a real environment behind every change, run the adversarial passes there, and let the senior spend attention on the calls that still require taste. The power law does not go away. You either build a review layer that absorbs it, or you watch your best people become the constraint on everyone else's output.