AI 程式設計智慧體寫出更多程式碼，卻沒有交付更多軟體

長期以來，業界預設一條樸素的推論：只要 AI 程式設計助手和程式設計智慧體能把程式碼寫得更快，軟體的產出就會按比例增加，企業甚至可以據此精簡工程團隊。Ars Technica 報道的一項新研究卻給這條推論潑了冷水。哈佛大學的研究者 Fiona Chen 與 James Stratton 分析了數百家公司的真實工程資料，結論是：幾乎沒有證據表明採用這些工具的企業提高了軟體產出或減少了僱員。換句話說，程式碼確實變多了，但軟體並沒有因此變多。 這項研究的資料基礎相當紮實。它使用了工程度量公司 Jellyfish 彙總的分析資料，涵蓋約 3 億個「工作事件」，例如提交和拉取請求，並結合議題管理軟體的記錄，覆蓋超過 700 家軟體開發企業、70 餘萬名員工，時間跨度從 2021 年到 2026 年 3 月。研究者既用了直接測得的 AI 使用情況，也透過分析 GitHub 上的活動，判斷每家公司究竟從何時開始引入工具。他們還區分了兩類產品：一類是輔助補全、程式碼主要仍由人撰寫的 AI 程式設計助手，另一類是根據提示自主編寫並提交程式碼的 AI 程式設計智慧體。在此基礎上，他們採用「差分之差」迴歸，比較各公司在引入工具前後的關鍵變數變化。這種設計的價值在於，它把時間趨勢和公司之間的固有差異拆開，比簡單對比使用者與非使用者更接近因果判斷。

真正有意思的是研究對原因的解釋。作者認為，編碼階段獲得的任何效率提升，都被生產流程下游的約束「吸收」了，而最突出的約束就是人工程式碼評審。資料顯示，隨著 AI 的引入，程式碼評審所需的時間明顯拉長，拉取請求更容易被要求修改，評審者留下的評論也更多。這與每一位程式設計師的親身體驗吻合：AI 生成的程式碼看上去能夠執行，但沒有人敢不加檢查地信任它，於是正確性的核驗成本從作者一端轉移到了評審者一端。生產線上一個環節被大幅加速，而相鄰環節的產能沒有變化，整條產線的吞吐量就由最慢的那一環決定。這正是制約理論中的老道理，只不過這次的瓶頸從「寫」變成了「讀」。 對行業而言，這一發現有幾層含義。第一，單純以生成程式碼的行數、提交數或工具採用率來衡量 AI 的價值，很可能產生誤導，因為這些指標恰好處在流程中被放大的那一端。第二，企業若希望真正兌現生產力紅利，就不能只採購更強的生成工具，還要同步投資評審環節：更好的自動化測試、靜態分析、規範約束，以及能夠輔助評審而不是隻會生成的智慧體。第三，「AI 讓工程團隊縮編」的敘事缺少資料支援，至少在研究覆蓋的時間視窗內，僱傭規模並沒有出現明顯下降。需要強調的是，這並不等於 AI 沒有價值，研究所說的是公司層面的產出與僱傭指標沒有可見變化，而不是個別任務上的速度沒有提升。

從工程管理的角度看，這一結果還揭示了一個常被忽視的事實：軟體交付是一條由需求、設計、編碼、評審、測試、釋出和運維串聯起來的鏈條，編碼只是其中一環，而且往往不是耗時最長的一環。當 AI 把這一環的成本壓得很低時，原本被掩蓋的下游問題就會暴露出來。評審者需要理解不是自己寫的程式碼，需要判斷它與既有架構是否一致，需要確認邊界條件是否被覆蓋，這些工作依賴上下文與經驗，很難隨著模型變強而自動消失。更棘手的是，生成越快，積壓的待評審改動就越多，評審者的注意力成為稀缺資源，質量把關反而可能因疲勞而鬆動。因此，團隊在引入智慧體的同時，需要重新設計工作方式：限制單次改動的體量，要求智慧體附帶測試與變更說明，把可自動判定的檢查前移到提交之前，讓人類評審者把精力留給真正需要判斷力的部分。

這一發現也為工具廠商提出了新的課題。過去幾年，競爭的焦點集中在誰的模型寫得更準、誰的智慧體能獨立完成更長的任務，評價標準多半是基準測試的透過率。然而，如果企業層面的產出並未隨之改善，那麼下一階段的差異化就很可能來自「可審查性」：智慧體能否把改動拆成易於理解的小塊，能否解釋自己為何這樣修改，能否主動給出可復現的驗證證據。對採購方來說，更合理的問題不再是「它能寫多少程式碼」，而是「它交付的程式碼需要多少人工時間才能放心合併」。 當然，這類研究也有侷限。資料截止於 2026 年 3 月，而模型和智慧體的能力、企業的工作流程都在快速演進，評審瓶頸未必是永久性的。如果未來的智慧體能夠生成更小、更易驗證的改動，或者能夠附帶可檢驗的測試與證據，評審成本有可能下降。同樣，軟體產出的度量本身就困難，提交和拉取請求只是代理指標，並不能完全反映交付給使用者的價值。但無論如何，這項研究提醒我們：在智慧體時代，真正稀缺的不再是寫出程式碼的能力，而是以可接受的成本確認程式碼正確的能力。誰能把驗證環節做得更快、更可靠，誰才更有可能把「更多程式碼」變成「更多軟體」。