结对编程能否解决 AI 代码 PR 审查瓶颈？

Can pair programming embed peer review directly into the development workflow? And could that be an answer to the PR review bottleneck AI-assisted delivery has created?

Some teams think so. I've heard of pairing used exactly that way to combat review bottlenecks. Not because two people type faster than one. They don't.

Because the review can happen while the work is being done. Context shared in the moment. Standards applied as the code takes shape. Assumptions challenged before they harden into a design. By the time the PR opens, most of the judgement has already been exercised. The queue moves because there's less left to argue about.

The obvious pushback is cost: two engineers on one piece of work. The counter from teams who run it is that the review was getting done anyway — doing it in-flight just removes the queue time, and the pairing pays twice more in knowledge sharing and upskilling along the way. I've got no dog in that fight — it's just something that's interested me lately. What matters is the mechanism underneath it.

Because that mechanism holds whether or not pairing fits your team: review confidence is created during the work. Afterwards you can only check for it.

And that's exactly the problem AI has scaled up. An agent produces more code, faster, than any pair ever did. If all the judgement waits at the PR, the bottleneck doesn't shrink — it compounds. The reviewer inherits every decision the agent made alone: the shape it chose, the patterns it followed or invented, the tests it decided were enough.

The teams that cope with agentic volume won't be the ones adding reviewers at the end. They'll be the ones applying the pairing idea: moving the standards, the challenge, and the judgement into the work itself, so the evidence arrives with the PR instead of being excavated from it.

Pair programming was never really two people writing code. It was review moving closer to the work.

Same lesson, new era: build review confidence before the PR, or queue behind it after.