AI 編碼代理使提交量提升高達 240%，但發布量僅增加 30%

新聞摘要

2026 年發布的兩項獨立研究指向相同的結論：AI 編碼代理讓開發者能產生更多程式碼，但額外的產出並未轉化為相應更多的完成、發布或廣泛使用的軟體。Ars Technica 於 2026 年 10 月 10 日的報導強調了一項由哈佛大學主導的軟體公司研究，而國家經濟研究局（NBER）的獨立工作論文使用 GitHub 數據得出了驚人相似的結果。

哈佛研究：更多程式碼，相同結果

哈佛大學的研究人員 Fiona Chen 和 James Stratton 分析了 Jellyfish（一個衡量工程團隊產出的平台）的匯總數據。該數據集涵蓋約 3 億個工作事件，例如提交和拉取請求，以及超過 700 家軟體公司中 70 萬名員工的問題追蹤數據。時間範圍從 2021 年到 2026 年 3 月。

為了確定每家公司採用 AI 工具的時間，團隊結合了直接測量的 AI 使用情況和對 GitHub 活動的分析。他們區分了兩類：AI 編碼助手（自動補全主要由人類編寫的程式碼）和 AI 編碼代理（從提示詞自主編寫並提交程式碼）。然後他們使用雙重差分迴歸，比較不同時間採用 AI 的公司採用前後的結果。

公司採用編碼代理後發生了什麼變化

採用編碼代理後，公司層級的平均結果如下：

• 產生的總程式碼行數增加約 30%。
• 總提交量增加約 20%。
• 拉取請求增加約 23%。
• 在 Jira 等工具中追蹤的問題和史詩的解決率沒有統計上顯著的變化。
• 追蹤問題的大小或複雜度沒有可檢測的變化，這使得團隊只是承擔更小或更簡單工作的說法難以成立。

額外程式碼的去向：審查瓶頸

根據該報導，額外的產出在下游被吸收。程式碼審查花費更長時間，拉取請求更可能需要修訂，審查者留下更多評論。作者發現很少有證據表明公司因使用這些工具而增加了整體軟體產出或減少了就業。開發者通常知道 AI 生成的程式碼需要仔細檢查，因此驗證它所需的人力是巨大的。

NBER 的第二種觀點

NBER 的工作論文《編寫程式碼 vs. 發布程式碼：AI 編碼工具各世代的生產力效應》（工作論文 35275），作者為 Mert Demirer、Leon Musolff 和 Liyuan Yang，從不同角度探討了同一問題。該論文於 2026 年 5 月發布，並於 2026 年 9 月修訂。它使用了超過 50 萬名 GitHub 開發者的數據以及 AI 使用遙測數據，並應用了匹配事件研究設計。

作者發現，每一代工具都顯著提高了提交量。累積效應約為：自動補全 30%，互動式編碼代理 180%，自主編碼代理 240%。然而，這些收益在生產鏈中遞減。對於自主代理，240% 的提交效應在專案層面降至約 80%，在發布層面降至約 30%。在四個主要軟體市場中，新應用程式的數量急劇增加，但總使用量並未增加。

請注意，該論文的早期版本在一些次要報導中被總結為使用較小的開發者樣本和 180% 的標題提交數字；上述數字反映了 NBER 頁面上列出的最新修訂。

薄弱環節的解釋

NBER 的作者通過「薄弱環節」的視角來解釋這種模式，其中最慢的人類依賴步驟限制了整個流程。他們估計 AI 與人類努力之間的替代彈性為 0.23，這表明強互補性：當審查、整合和發布仍然依賴人時，加速流程的一部分幫助不大。這與哈佛的發現一致，即當更多程式碼到達時，審查時間會增加。

更廣泛的背景和注意事項

其他 2026 年的評論描述了「生產力悖論」，即更快的拉取請求會增加錯誤、審查時間和維護負擔，除非發布流程能跟上。一些供應商報告的數字流傳，例如公司使用代理將程式碼發布速度提高 30%，但這些來自供應商材料，我們無法獨立驗證。研究小組 METR 在 2025 年進行的一項隨機試驗發現，經驗豐富的開發者在處理複雜、成熟的程式碼庫時，使用 AI 工具的速度約慢 19%，這一結果經常與這些較新的研究一起被引用。

讀者還應記住，這兩項研究都衡量了許多團隊的平均值。具有強大自動化測試、明確規格和快速審查實踐的個別團隊可能會看到不同的結果，而且工具本身也在快速變化。

這對學習者和團隊意味著什麼

對於學生和在職開發者來說，教訓是編寫程式碼只是建構軟體的一個階段。隨著程式碼生成變得更加便宜，閱讀程式碼、編寫測試、審查變更和設計系統的技能變得更加有價值。對於工程團隊來說，這些研究建議投資於審查工具、自動化測試和發布流程，而不是僅以程式碼行數或提交數量來衡量成功。