一篇哈佛工作論文為常見的生產力主張提供了有益的檢驗：使用 AI 撰寫更多程式碼，應該代表交付更多軟體。在使用 Jellyfish 工程分析平台的 718 家公司中，Fiona Chen 和 James Stratton 估計，採用程式碼代理後，每位活躍員工的程式碼行數增加 30%、提交次數增加 20%、pull request 數量增加 23%。他們衡量的已完成 Jira 議題和大型專案並未顯示統計上顯著的增加。論文目前版本日期為 2026 年 8 月 4 日；其工作事件資料截至 2026 年 3 月。

這種落差對工程主管很重要，因為 pull request 送出後會進入審查、測試和可能修改的佇列。同一項研究估計，採用代理後，pull request 從提交到合併所經過的時間增加了 49%。要求修改的情況變得更常見，每個 pull request 的留言也增加。這些發現顯示審查工作量加重，但並未證明每項由代理撰寫的修改都很差，也沒有測得缺陷率。

重大變化

  • 變化：在這項公司層級研究中，採用程式碼代理與大幅增加的程式碼活動及更嚴格的 pull request 審查同時出現，但已解決議題或大型專案並無統計上顯著的增加。
  • 為何重要：程式碼行數、提交次數和 pull request 數量衡量的是進入生產流程的工作。已解決的工作是較後階段的衡量指標。若團隊只憑程式碼量評估代理，可能會忽略審查階段增加的負荷。
  • 觀察重點：企業能否提高審查能力，以及後續資料是否顯示已完成工作有所增加。這篇工作論文追蹤至 2026 年 3 月的早期採用情況，無法定論較長期的影響。

助理與代理帶來不同的估計結果

作者區分助理：助理會在開發者工作時回應程式碼建議；與代理不同，代理可以接手較高層級的任務，並在開發者核准結果前執行多個步驟。作者以啟用 GitHub Copilot 和 Cursor 商業授權來衡量助理的採用情況。對於代理，他們結合 Claude Code 使用資料，以及提交或 pull request 中的機器人帳號和工具簽章等訊號。這些衡量方式可能漏掉部分個人使用或未整合的工具。代理估計值是相較於較早的助理採用期間，代理採用周邊額外的關聯；它不代表每位使用代理者的估計結果。

助理的結果較小：程式碼行數估計增加 12%、提交增加 9%、pull request 增加 5%。在論文的主要估計中，只有提交數的結果達到統計顯著。採用代理後，三項程式碼活動指標都顯著增加。提交代表程式碼更新；pull request 則是送交審查的修改。兩者都不能證明功能已送達使用者。論文以已解決的 Jira 議題和較大型專案作為較後階段的產出指標，依據的是團隊在審查、測試和部署後將工作標記為完成的追蹤流程。Jira 狀態仍是交付情況的替代指標，而非對使用者實際收到內容的獨立測量。

代理採用後，每位員工每月已解決議題數估計增加 0.12，基準為 3.67，標準誤為 0.17。這項結果在統計上與零無法區分。大型專案完成情況同樣沒有顯著變化。作者指出，信賴區間排除了研究期間議題完成數高於基準平均值 12% 的增幅。這項發現比「代理沒有產出任何有用軟體」更為有限：仍可能存在小幅增益，而且議題數無法涵蓋價值或品質的所有變化。作者使用預測任務長度的指標檢驗議題規模是否改變，在樣本中沒有發現此類變化的證據。

更多工作送到審查者手上

審查指標為產出落差提供了一個合理機制。論文估計，採用代理後，pull request 從提交到合併多花 3.45 天；基準為 7.03 天，增加 49%。這是審查流程中的日曆時間，不是用碼錶測量審查者實際投入的分鐘數。收到正式修改要求的 pull request 比例，從 13% 的基準增加約 12 個百分點；每項 request 的留言則從 1.66 則增加 0.58 則，即增加 35%。每月至少審查一項 pull request 的員工比例，從 29% 的基準增加約 4 個百分點，相對增幅為 14%。相較之下，助理的估計並未顯示審查時間、修改要求或留言有顯著增加。

光憑這些中繼資料，論文無法判斷審查者為何要求修改。更多提交可能使固定容量的審查佇列吃緊；程式碼品質或審查標準改變也可能增加審查力度。作者沒有發現 pull request 平均規模顯著增加，這削弱了「額外留言只是因為修改更大」這種簡單解釋。他們沒有檢視程式碼內容，也沒有直接計算代理生成工作的缺陷。他們的兩階段生產模型說明，寫程式碼變快與每份草稿所需審查量改變，可能共同限制已完成的產出。該模型是對觀察結果的詮釋，並非能分別驗證任一機制的獨立測試。

AI 審查工具也已在樣本中普及：截至 2026 年 3 月，近 80% 的公司曾使用其中一種。然而，論文將 23.3% 的審查留言歸因於 AI，並發現 10.8% 的 pull request 至少有一則 AI 留言。因此，在這些公司中採用審查工具，不代表審查已自動化。

研究設計能得出什麼結論

研究人員分析 718 家同意參與的 Jellyfish 客戶公司自 2021 年 1 月至 2026 年 3 月約 3 億筆工作事件，涵蓋 725,938 名員工。他們使用分期差異中的差異設計，比較公司採用助理或代理前後的結果，並與較晚採用或尚未採用的公司比較。公司與日曆月份控制項可處理部分穩定差異和共同時間趨勢。推論仍取決於若未採用，這些公司的發展路徑是否可比。大型公司較早採用，未測量的變化也可能同時影響採用與工程工作。這是一項觀察性研究，其估計結果不應視為隨機試驗，也不應當作對所有軟體團隊的預測。

就業結果也需要同樣謹慎。作者使用連結至 LinkedIn 的總就業人數，以及 Jellyfish 的活躍員工數衡量工程就業，在觀察期間無法將顯著變化歸因於代理採用。這並未說明經過較長時間調整後，或整體勞動市場的招聘情況會如何變化。

BIG CHANGE 先前報導曾檢視另一個關於 AI 程式碼與可靠交付的工程案例。本研究從多家公司觀察，並分別衡量程式碼活動、審查和已解決工作。實務上的啟示是，評估代理時要一併追蹤這些階段：更快產生初稿會改變下游等待處理的工作量，而這篇論文目前尚未顯示已完成議題或專案有相應增加。

來源與延伸閱讀