AI並未將瓶頸從編碼轉移到代碼審查

許多人認為AI已經將軟件開發的瓶頸從編碼轉移到了代碼審查，但這一觀點並不準確。事實上，編碼從來不是瓶頸，代碼審查也並非真正的約束。真正的瓶頸在於部署批次——大量已審查的變更堆積在等待部署的隊列中。

一個簡單的測試可以揭示真相：你的應用程序或服務有多少已通過代碼審查但尚未部署和啓用的變更？如果答案是沒有或只有一個，那你的情況可能是個例外。但大多數情況下，這個數字超過一個，説明瓶頸在其他地方。我們的研究顯示，一半的團隊有2到10個變更堆積在批次中，四分之一有11到50個。超過90%的團隊以批次而非單次變更的方式交付。

“編碼從來不是瓶頸，現在也不是代碼審查。”這一數字暴露了行業範圍內的可見性差距。人們相信Claude Code、Cursor和GitHub Copilot將瓶頸從編碼轉移到了代碼審查，但這忽略了審查之後發生的一切。這不是個人的失敗，而是整個行業的誤解。

我們如此習慣於批次工作，以至於它看起來像是理所當然的。它長滿了苔蘚，與周圍的山丘難以區分。當你尋找加速軟件交付的方法時，你不會看到它，因為它看起來不像一個問題，而是像事情一直以來的樣子。

AI洪水湧入批次時會發生什麼？編寫代碼是更長價值流中的一小部分，該價值流從機會開始，到用户獲得所需價值結束。AI在某些領域比其他領域更有幫助，而端到端的收益取決於你是否注意到工作積累的領域。GitLab的2026年AI問責報告發現，85%的受訪者同意AI已將瓶頸從編寫代碼轉移到代碼審查。然而，從部署批次可以看出，這些人中有92%可能是錯誤的，因為如果審查後有積累，説明代碼審查不是瓶頸。加速審查只會讓真正的瓶頸更嚴重。

這並不是説編碼速度的提高不會給代碼審查帶來壓力。Faros AI對10,000名開發者的研究發現，AI採用率高的團隊合併的拉取請求增加了98%，但審查時間增加了91%，平均拉取請求大小增加了154%。Cursor自身的研究也發現，公司在使用其編碼代理後合併的拉取請求增加了39%。然而，更快地批准變更只有在變更隨後順利流向生產環境時才有效。在大多數情況下，它只是進入等待進一步處理的隊列，如測試和部署。如果提高通過審查階段的變更速度和規模，壓力就會轉移到真正的瓶頸。

代碼審查看起來像是一個約束，只是因為它有一個可見的隊列，而下游隊列因其在行業中的普遍接受而被隱藏。你的管道的任務是將變更送到生產環境供用户使用，而不是將它們收集在“待部署”隊列中。隨着所有未發佈變更的積累，風險也隨之增加。

批次是路標。詢問批次大小問題，你會發現真正約束價值流的是什麼：一個手動驗證步驟、一個繁瑣的變更審批或發佈列車流程，或者沒有簡單的部署方式。不是編碼，不是代碼審查。很可能在AI計劃之前你就已經在以批次方式工作。AI的引入會增大批次大小，這可能帶來問題。提高代碼審查吞吐量並不能解決問題，它只是更快地將變更移到瓶頸處。

利用真正的約束來設定整個價值流的節奏，將幫助你投資解決正確的問題。如果回顧會議未能產生顯著改進，你很可能會錯過批次問題。這就是為什麼一些AI計劃成功而另一些失敗的原因。

研究也忽略了這一點。關於AI影響的研究是有用的，但像許多研究一樣，它們在代碼合併處停止。它們考察開放的拉取請求、合併的拉取請求和審查花費的時間。沒有一項研究詢問變更在審查後等待了多久，或者有多少變更被捆綁在一起才有人在生產環境中看到它們。沒有這個數字，你就無法找到真正的約束。

投資AI來加速編碼之後，你可能會想修復代碼審查，或者完全放棄代碼審查。如果你以批次方式交付，這兩者對於快速消除風險或向用户交付價值都無濟於事。你的組織抵制修復批次問題的原因才是你需要解決的真正問題。