軟體交付智慧平臺 LinearB 的資料科學團隊研究了來自 2.6 萬名開發者的 73.3 萬個 PR 和 390 萬條評論，發現：
-
50% 的 PR 在其生命週期的 50.4% 的時間裡處於閒置狀態 ；
-
33% 的 PR 在其生命週期中閒置了 77.8%（高達）的時間；
-
參與調查的開發人員的平均週期時間為 6 天 + 5 小時；
-
這些開發人員的平均 PR 審查時間為 4 天 + 7 小時。
對此，LinearB 的 COO 兼聯合創始人 Dan Lines 則，PR 過程中的閒置時間就是開發者流程中的一個 killer。並表示，PR 悖論給自己和團隊帶來了很大的困擾。根據解釋，所謂 PR 悖論（Pull Request Paradox）就是：我剛剛寫了一些程式碼，可以對我們的客戶產生積極的影響，我有動力盡快釋出它。我需要你的幫助，但你卻很忙，而且有動力繼續寫你自己的程式碼。這種衝突就是 PR 悖論。
Dan 稱，研究所得的資料意味著：
- 每塊工作平均有兩天的閒置時間，造成了生產力浪費。
- 此舉損害了開發團隊合併和釋出程式碼的能力，從而阻止價值交付。
- 閒置的時間會導致情景意識的降低、程式碼品質的降低和努力的浪費。「在我們開啟一個新的 PR 之後，每過一個小時，重新審視我們的程式碼的認知負荷就會增加。如果我在一兩天後收到問題或修改請求，就很難再回到我原來的流程狀態。閒置時間損害了品質，因為當生產中出現我幾天或幾周前寫的程式碼的問題時，就更難偵錯了。」
- 導致團隊承諾無法兌現。
不過 Dan 的觀點也遭到了一些網友的反駁，以下是 上網友討論中的一些高贊回答：
：
文章中提到，在任務之間很難找到時間進行 quick review。這就是你的問題所在。審查 PR 應該是一項與建立 PR 同樣重要的任務。如果有公開的 PR，就不要開始工作。開始在一個新問題上工作只會使一切變得更糟，並使你的團隊更加緩慢。
顯然，要鼓勵提交小的 PR；如果是大的 PR，則至少要儘量把它分成明確的提交。
：
審查 PR 應該是一項與建立 PR 同樣重要的任務。
大眾需要理解這一點。高品質的程式碼並不 cheap，尤其是在為專案定義設計模式的初期。
如果你在這一步上偷懶，你的程式碼將很快變得雜亂無章（big ball of mud）。
：
請告訴我的同事這個。他們認為「agile」意味著「we don't plan we just react」。
此外，Dan 還在文章中列舉了一些 PR 的替代方案。首先是"真正的"持續整合。現在很流行的一種說法是，CI 和 PR 是相互排斥的。基於主幹的開發允許開發人員直接提交到主分支，而不需要任何形式的審查或合併過程。但 Dan 認為，這種方法可能只適用於最精英的團隊；對 95% 的人來說，它的缺點要大於優點。
其次是有人提出了一種 Ship / Show / Ask 策略：這是一種分支策略，它結合了 PR 的功能和保持傳送變更的能力。Changes 被歸類為"Ship"（不經審查合併到主線）、"Show"（開啟 PR 進行審查，但立即合併到主線）或 "Ask"（在合併之前開啟 PR 進行討論）。總的來說，此策略對於低風險的工作，選擇直接合並而不審查或事後審查是有一定道理的。但是 Dan 指出它也存在一個問題，即目前大多數團隊都沒有適當的定義、流程和自動化來使其發揮作用。
此外還有結對程式設計（Pair programming），不過這一方法好像也不盡適用。「我知道很多開發團隊使用結對來補充非同步拉取請求審查，而我個人從未在一個使用結對來取代 PR 的團隊工作過。」
Dan 表示，他不認為 PR 會消失。「根據我的經驗，在合併之前讓隊友審查你的程式碼是提高品質和減少錯誤的最好、最實惠的方法。PR 在捕捉可維護性錯誤方面特別有效，而這些錯誤是很難通過自動測試發現的」。且很多開發人員都同意 PR 是提高學習和教學品質的好工具。
而 LinearB 團隊也針對 PR 悖論推出了一個相關的提升 PR 審查效率的方案，並表示已收穫了積極地反饋。詳情可檢視。