哈佛研究發現：AI 編碼代理生成更多程式碼，但軟體並未增加

一項針對 700 多家公司工程活動的哈佛研究發現，AI 編碼代理顯著增加了程式碼產出——程式碼行數增加 30%，提交次數增加 20%，拉取請求增加 23%——但已解決的問題或史詩級任務並沒有統計上顯著的增加。原因在於人類程式碼審查吸收了這些增益：平均拉取請求審查時間增加 49%，需要修改的拉取請求比例幾乎翻倍。

這項研究由哈佛大學研究人員 Fiona Chen 和 James Stratton 完成，圍繞 Jellyfish 分析數據展開，可於 fion.ac/jellyfish.pdf 取得 PDF 版本。Ars Technica 的 Kyle Orland 於 2026 年 10 月 9 日以標題「AI 編碼代理生成更多程式碼，但並非更多軟體」報導，副標題為「研究發現編碼效率增益被人類審查『瓶頸』吸收」。

研究數據涵蓋 2021 年至 2026 年 3 月的 3 億個工作事件

該研究利用 Jellyfish（一個衡量工程團隊細粒度輸出的平台）的聚合分析數據。據 Ars Technica 報導，數據集包含 3 億個單獨的「工作事件」——提交、拉取請求及類似工件——以及問題管理軟體數據，涵蓋 2021 年至 2026 年 3 月期間 700 多家軟體開發公司的 70 多萬名員工。一位直接引用論文的評論者指出公司數量為 718 家。

為了識別 AI 工具何時進入每個公司的工作流程，研究人員結合了直接測量的 AI 使用情況和 GitHub 活動分析，區分了 AI 編碼助手（主要自動補全人類編寫的程式碼）和 AI 編碼代理（從提示自主編寫並提交程式碼）。隨後，他們對不同組織在不同時間點引入工具前後的關鍵變數進行了「差異中的差異」迴歸分析。

程式碼數量大幅增加；交付的功能則沒有

原始輸出效果顯著且一致。Ars Technica 報導，公司引入 AI 編碼代理後：

• 總生成程式碼行數增加 30%
• 總提交次數增加 20%
• 拉取請求增加 23%

研究人員未發現交付工作有類似變化。在 Jira 等工具中追蹤的 Issue 和 Epic 的解決率——研究中衡量整體軟體功能的代理指標——在引入 AI 工具後並未出現統計上顯著的變化。研究人員也發現，在 AI 引入期間，Jira 追蹤的問題在規模或複雜度上沒有「組成轉變」，這意味著解決率持平並非因為團隊處理更大或更困難的任務。

程式碼審查是吸收生產力增益的瓶頸

研究將缺失的輸出定位在審查階段。引入 AI 編碼代理後：

• 平均審查流程時間——從拉取請求提交到合併——膨脹 49%
• 要求修改的拉取請求比例幾乎翻倍
• 每個拉取請求的評論數量增加 35%
• 執行程式碼審查的員工比例增加 14%

在論文的框架中，編碼階段獲得的任何效率「都被生產過程中的下游限制所吸收」，且「程式碼審查流程顯著延長，拉取請求更可能需要修訂，審查者留下更多評論」。研究結論指出，「幾乎沒有證據表明公司因採用這些工具而增加軟體產出或減少就業」。

AI 程式碼審查尚未能吸收負荷

在大多數受研究公司中，AI 輔助審查存在，但僅處理少數工作。截至 2026 年 3 月，80% 的受測公司使用某種形式的 AI 程式碼審查，但 AI 代理僅負責所有審查評論的 23.3% 和所有拉取請求的 10.8%。人類仍執行絕大多數審查工作。

研究未發現顯著的就業影響

檢視 Jellyfish 數據中的總活躍員工，並交叉參考同一公司的 LinkedIn 數據，研究人員寫道，他們「無法將顯著的就業變化歸因於 AI」。執行程式碼審查的員工比例增加 14% 是現有努力的重分配，而非淨員工人數變化。

批評 1：數據主要來自 2025 年，模型過時

Hacker News 討論中最常見的反對意見是，這項研究描述的世界已經向前發展。評論者 jefftk 寫道：

如同學術論文的標準，這是試圖描述他們研究時的全球狀態。但然後需要時間撰寫和發布，之後報紙將其報導為當前事件。在這種情況下，我們看到的是 2025 年的圖景。主要代理結果涉及的模型主要是 Claude 3.5 到 Sonnet 4.5、GPT-4.1 到 GPT-5 和 Gemini 2.5。而且論文的設計意味著你主要看到的是部署初期的效果，在公司發展出良好審查流程之前。

評論者 hyperpape 表示他們的總監分享了這篇論文，並提取了具體基線數據以支持同一觀點：基線平均每人每月 5,017 行程式碼，估計增加 1,494 行；基線每月 5.34 個拉取請求，增加 1.22；基線平均程式碼審查時間為 7.03 天。他們認為這些小幅百分比增加確認了數據過時，並單獨批評使用平均數而非中位數：

如果你的平均拉取請求擱置 7 天，顯然你不關心交付任何東西，代理也不會改變這一點。

批評 2：「更多軟體」以關閉的票證衡量

評論者 dcre 直接指出應變數：

注意他們將「更多軟體」定義為「更多關閉的票證」。你自行解讀。他們認為這是好衡量標準，因為票證範圍未增加。值得考慮你是否相信這捕捉了他們聲稱的內容。你因編碼代理而編寫的額外測試是否反映在你工作的票證中？

批評 3：樣本排除了最可能受益的團隊

由於數據集來自使用 Jellyfish 的公司，並產生可測量的工作事件足跡，多位評論者認為研究結構上遺漏了個人開發者、小型初創公司和個人專案。評論者 dolebirchwood 寫道：

所有其他不使用 Jellyfish 的人構建的軟體呢？那些沒有相同運營瓶頸，且真正比大型競爭對手構建更多的小公司呢？那些僅因 AI 而開始創業並構建軟體的 solo 創始人呢？

評論者 joshheitzman 給出一個具體例子——他們使用 Kilo Code 啟動的專案 FluxImp，後來變得自我修改，主要通過 Mercurial 在私人伺服器上開發，因此「GitHub 活動很少」。他們補充說「所有關於非軟體工程師為自己製作有用小軟體的故事，似乎也不太可能產生易於研究的足跡」。

評論者 KumaBear 更簡短地表示：「自製個人使用軟體絕對激增。我從未想過有時間做的專案現在成為可能。」評論者 juliendorra 將這一時刻比作 HyperCard，描述了有限範圍個人軟體的繁榮——設計師為每個專案構建工具、開發者製作藝術軟體、超級用戶請求插件和自訂工作流程。

批評 4：瓶頸可能是組織性的，而非認知性的

多位評論者認為程式碼審查從來不是真正的限制。評論者 blauditore 提出賽車類比：引擎最終超越輪胎，因此超燃料僅帶來微不足道的單圈時間增益。評論者 gchamonlive 表示溝通是軟體生產中最困難的部分，且「軟體生產已成為語言學的姊妹領域，比以往更是如此」。評論者 jmward01 認為瓶頸在於團隊以清晰願景和正確下一步發展產品的能力，且「我們行業的流程很糟」，與 AI 無關。

評論者 forgotaccount3 指出規劃儀式而非審查，描述故事寫得足夠精確，「我們可能直接複製到 AI 代理讓它實現」，然後因故事點和衝刺容量限制在待辦事項中擱置兩週。

從業者對研究結果是否符合自身經驗存在分歧

一些評論者報告研究符合他們的工作生活。Ars Technica 員工精選，來自用戶 metavirus，直言不諱：

我被迫在工作中使用 AI，這絕對是 10000% 真實。大量劣質程式碼進入系統，數十人需要篩選、過濾掉糟粕，然後最終閉眼發布，因為現在我們有新的 SLA，以免被視為進度的瓶頸。

評論者 PacificSpecific 報告一位朋友因 80% 的工作是審查 Claude 提交而離職。評論者 atleastoptimal 描述了新審查負荷的算術：「與其每天審查 1,000 行，我現在每天『審查』10,000 行。我的大腦不會快 10 倍。」

其他人報告相反情況。評論者 keithnz 表示他們的團隊正在生產更多軟體並更具野心，歸功於在規範、架構、編碼、性能和測試指導方面的大量前期投資。評論者 tdhz77 寫道：「自 AI 以來我創建了更完整的軟體。這是瘋狂的概念。」評論者 mrieck 認為測試、審查和精煉現在花費更多時間，正是因為生產的軟體數量更大，且初創公司可以驗證的數量比以前多約 10 倍。

為什麼程式碼審查即使自動化也不會消失

評論者 zmmmmm 提出了問責制論點，這與程式碼品質不同：

自動化審查有助於確保程式碼按預期運作，但不會確保意圖正確。如果推動變更的人告訴 AI 這是預期結果，那麼插入後門、繞過測試、「作弊」設計決策以加快工作的員工不會被識別。

他們總結，持久的保護是「一個願意冒名譽風險說『我理解這個變更並批准它』的人」。

評論者 staminade 預測審查文化變革首先出現的地方：不是成熟團隊，而是「從一開始就採用無人類審查政策，並在成熟後維持的初創公司」，這對當前研究幾乎不可見。如果這些公司顯著更快交付，staminade 認為，行業其他部分將被迫跟隨。

研究未解決的問題

論文衡量的是已有工程分析的公司，窗口結束於 2026 年 3 月，使用 Jira 問題解決作為交付軟體的定義。它不衡量個人專案、solo 創始人或完全取代拉取請求工作流程的團隊。它也捕捉了代理編碼的早期部署時期，當時大多數組織尚未確定 AI 生成程式碼的審查實踐。

如 Ars Technica 指出的，研究中 95% 的公司已在數據截止時實施 AI 編碼代理，且代理能力此後持續變化。研究記錄的「編碼時間與審查時間」權衡可能隨著團隊學習何時將問題交給代理而改變。目前，測量結果是雙刃劍：更快的程式碼生成被審查時間和努力的可比增加所抵消。