I agree that those things could be issues with code reviews, but I don&#x27;t see how &quot;promiscuous pairing&quot; helps with most of them.<p>* They delay integration.<p>Pairing by definition slows down <i></i>all<i></i> work on code(you have 1 person working instead of two). Also, code reviews need not delay integration, even if you&#x27;re following the article&#x27;s suggestions. You can still merge all work in an integration branch, and pull it if it eventually doesn&#x27;t pass code review.<p>* They tend to encourage focus on abstract code polishing without proportionality or relation to the value of the code.<p>This is an issue with the priorities of the people doing the code review, and thus applies just as much to pairing.<p>* They favor superficial improvements, while increasing the costs sunk into paths that may be deeply flawed. (They facilitate late code-structural feedback, but not early directional&#x2F;problem-analytical feedback.)<p>I have no idea how pairing is possibly different from code review in this case.<p>* They often discourage more collaborative work and therefore quicker and richer feedback, by their presence as a substitute for pairing.<p>This is possibly true, so I&#x27;ll just take the assertion at face value.<p>* They create impediments to work moving quickly to completion.<p>This is pretty much the same as #1.<p>&quot;Of these, the most egregious is the distraction from value.&quot; - so the most egregious problem with code reviews is the people that do them might have wrong priorities. I don&#x27;t see how pairing would change this.<p>A benefit of pairing that I can see over code reviews is <i></i>when<i></i> you get feedback - instant, real-time in pairing vs late in code reviews. The useful scenario I envision is when you start implementing a feature and your pair-buddy steers you away from dumping time into a poor solution. That and #4 seem to be significant reasons why you might want to introduce pair programming. However, pair programming is not without drawbacks when compared to code reviews - it takes up more time in most cases(this is where it derives its main benefit), some people work better solo, a mismatch of skill or expertise means one person has to slow down to work with the other. I wouldn&#x27;t really say code reviews are &quot;far inferior in every respect&quot; to pairing, I think both have their place.