AI 爆發後代碼審査成新瓶頸，工程師開始「餬弄式」過 PR

BiRun 消息，作者： The Pragmatic Engineer 編譯：深潮 TechFlow 深潮導讀： AI 寫代碼越來越快，但審査代碼的還是人。這個矛盾正在演變成一場危機：工程師被 AI 生成的 PR 淹沒，要麼疲於應付審査不仔細，要麼幹脆看 AI 沒報錯就點通過。大廠紛紛自建工具應對，但目前沒人有標準答案。 嗨，我是 Gergely ，這是 Pragmatic Engineer Newsletter 的一期免費增刊。每期我都從資深工程師和工程領導者的視角報道大型科技公司和初創公司。今天我們討論過往 The Pulse 期刊四個話題中的一個。完整訂閱用戶一週前就收到了這篇文章。如果這封郵件是轉發給你的，你可以在這裡訂閱。 我聽到許多工程領導者最關心的一件事是如何應對持續增長的代碼審査負載。這個話題已經存在一段時間了，現在這類對話似乎越來越多。 對我來說，這始於今年 1 月，噹時 Opus 4.5 和 GPT 5.4 開始在大多數公司寫出更多更好的代碼。大約從那時起，總監級別的人開始討論軟件開發的瓶頸正從編碼階段轉向審査階段。 AI 代碼審査工具的爆發 2 月以來， AI 代碼審査工具出現了爆發式增長來應對負載增加，專門的 AI 代碼審査工具如 CodeRabbit 、 Greptile 、 Qodo 、 SonarQube （現在還有 Gitar ）的實驗和採用呈爆炸式增長。還有編碼工具本身提供的工具，比如 Claude Code review 、 Cursor review 、 GitHub Copilot review 。然後之前不涉及代碼審査但對代碼庫有上下文的工具也在加入這個領域，比如 Sentry 的 Seer AI reviews 、 Linear code reviews 。 大廠自建內部工具： Uber 的 Code Inbox 大公司正在構建內部工具來改善代碼審査體驗。 Uber 的 Code Inbox 就是一個案例： 智能分配是 Code Inbox 內的一項功能，用於推進審査進程： 圖：Code Inbox 的智能分配（Smart assignment）設置，用於推進審査流程。來源：The Pragmatic Engineer 還有風險檔案功能，用於評估變更的影響，並鼓勵開發者對高風險變更格外注意： 圖：Code Inbox 的風險檔案（Risk Profiles）功能，估算代碼變更風險並提示重點關注。來源：The Pragmatic Engineer 我們報道過 Uber 如何使用 AI 進行軟件開發，而且不只是 Uber ： Cloudflare （ AI Code Reviewer ）、 Faire （ Fairey ）、 HubSpot （ Sidekick ）以及許多其他公司也構建了工具來使他們的代碼審査流程更流暢，因為他們發現內部實現比集成供應商的方案效果更好。 從「審査」轉向「驗証」 另一種方法是思考如何驗証代碼，而不是審査代碼。說起來容易做起來難；理論上，徹底的測試應該能夠驗証代碼按預期工作。但多少測試才算「徹底」？我們說的是什麼類型的測試？集成測試和端到端測試也包括嗎？模餬測試呢？形式化方法呢？如何驗証新測試按預期覆蓋了功能？我們如何將所有這些與可觀測性連接起來？ 過度審査正在拖垮工程師過多徹底的代碼審査正在讓工程師精疲力竭，並導致審査質量下降。我聽到很多傳聞說開發者們看到其他人不再能夠用心審査代碼，如果 AI 代碼審査沒有實質性意見，他們就直接通過了。與此衕時，那些像以前一樣投入衕樣精力和時間進行代碼審査的。