Markdown 版本

AI-translated from English; not yet reviewed by a fluent editor.

# 一項企業研究發現，AI 程式碼代理提高了程式碼產出，但已完成的工作沒有跟上

> 一篇哈佛工作論文將 718 家公司的程式碼代理採用，與更多程式碼及更長的 pull request 審查時間連結起來，但已解決工作的增幅並不顯著。

By BIG CHANGE Editorial

Published: 2026-10-10T00:19:01.727Z
Updated: 2026-10-10T00:19:01.727Z
Canonical: https://bigchange.ai/blog/ai-coding-agents-review-output-study

![Two colleagues discuss a software change beside a monitor turned away from view.](https://bigchange.ai/api/media/file/hero-v2.png)
AI-generated conceptual illustration by BIG CHANGE

一篇[哈佛工作論文](https://fion.ac/jellyfish.pdf)為常見的生產力主張提供了有益的檢驗：使用 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 先前報導](https://bigchange.ai/blog/ai-coding-ci-bottleneck-dependable-delivery)曾檢視另一個關於 AI 程式碼與可靠交付的工程案例。本研究從多家公司觀察，並分別衡量程式碼活動、審查和已解決工作。實務上的啟示是，評估代理時要一併追蹤這些階段：更快產生初稿會改變下游等待處理的工作量，而這篇論文目前尚未顯示已完成議題或專案有相應增加。

## 來源與延伸閱讀

- [Fiona Chen 和 James Stratton，*《企業中的人工智慧：軟體生產的瓶頸》*](https://fion.ac/jellyfish.pdf)：主要工作論文，目前版本日期為 2026 年 8 月 4 日。方法、圖表和附錄支持文中報告的估計及其限制；公司層級原始資料為專有資料，並以彙總形式呈現。
- [Ars Technica 於 10 月 9 日的報導](https://arstechnica.com/ai/2026/10/ai-coding-agents-generate-more-code-but-not-more-software/)：當時的獨立報導，讓外界注意到這篇論文。上文的數值和方法主張均已對照論文核實。
- [BIG CHANGE 先前關於 AI 程式碼與 CI 的文章](https://bigchange.ai/blog/ai-coding-ci-bottleneck-dependable-delivery)：相關報導，討論另一個工程案例。它為交付議題提供背景，並非本研究的後續報導。

## Sources

- [《企業中的人工智慧：軟體生產的瓶頸》](https://fion.ac/jellyfish.pdf) — 哈佛 78 頁求職市場工作論文；涵蓋截至 2026 年 3 月的工作事件、方法及數值估計。專有資料經彙總並匿名化。
- [Ars Technica：AI 程式碼代理產生更多程式碼，卻沒有產出更多軟體](https://arstechnica.com/ai/2026/10/ai-coding-agents-generate-more-code-but-not-more-software/) — 獨立的同期報導，提供發現線索和背景；研究主張均已對照論文核實。
- [BIG CHANGE：AI 程式碼讓可靠交付成為下一個工程挑戰](https://bigchange.ai/blog/ai-coding-ci-bottleneck-dependable-delivery) — BIG CHANGE 先前關於另一個 Linear 工程案例的報導，探討 AI 程式碼與可靠交付。