過去兩年，「AI 讓工程師寫程式快很多」幾乎成了不需要證明的共識。各家工具的示範影片裡，一句話就生出一個功能；開發者社群裡的心得文，動輒說自己的產出翻了一倍。但是一個團隊寫出更多程式碼，和這個團隊真的交付更多軟體，是兩件不同的事——而這中間的落差，一直缺少夠大規模的實證資料。
哈佛經濟學者 Fiona Chen 與 James Stratton 的工作論文《Artificial Intelligence in the Firm: Bottlenecks in Software Production》補上了這一塊。研究團隊取用工程分析平台 Jellyfish 的資料，涵蓋 718 家公司、超過 72.5 萬名工作者、約 3 億筆工程事件，時間跨度從 2021 年到 2026 年，觀察這些公司導入 Claude Code、Cursor、Devin 等 AI 編碼代理人前後，工程指標如何變化。
結論相當反直覺：程式碼確實變多了，完成的工作卻沒有變多。
Photo by Milad Fakurian on Unsplash
數字長什麼樣子
先看產出端。導入 AI 編碼代理人之後，程式碼產出量增加約 30%，換算下來大約是每位工作者每月多出近 1,500 行。提交（commit）次數增加約 20%，拉取請求（pull request，以下簡稱 PR）數量增加約 23%。單看這一組數字，AI 工具的效果毫無疑問。
接著看交付端。研究以 Jira 上「已解決的 issue」與「完成的 epic」作為實際產出的代理指標，結果是——沒有統計上顯著的增加。
要特別注意，這句話的正確讀法是「增幅未達統計顯著水準」，不等於「完全沒有增加」。部分媒體把它寫成「多寫了三成的程式碼，卻零額外產出」，那是把一個統計學上的保留說法，誤讀成一個強烈的事實宣稱。研究本身的用詞謹慎得多。
真正值得細看的是中間那一段。審查時間增加了 49%，平均來到 3.45 天。需要退回修改的 PR 比例接近翻倍，每份 PR 收到的留言數增加 35%，而被捲進程式碼審查工作的人數增加了 14%。
也就是說，AI 並沒有讓軟體生產這條流水線整體變快，它讓前段變快了，然後把壅塞推到了後段。
瓶頸搬家，不等於瓶頸消失
這其實是製造業早就熟悉的現象。一條產線上，如果只升級其中一個工站的產能，整體產出並不會跟著等比例成長，因為限制整條線的始終是最慢的那一站——只是瓶頸的位置換了人。限制理論（Theory of Constraints）談了幾十年的東西，現在在軟體團隊身上重演了一次。
軟體生產的流程大致是：需求釐清 → 寫程式 → 程式碼審查 → 測試 → 部署 → 驗收。AI 編碼代理人幾乎只對第二站生效，而第三站的產能是由人決定的：審查者的數量、他們的專注時間、他們對這段程式碼脈絡的熟悉程度。當上游一個月多送 1,500 行程式碼過來，下游的人數和工時並沒有跟著變。
Photo by Zulfugar Karimov on Unsplash
更麻煩的是，多出來的不只是「量」，還有「不確定性」。退回修改的 PR 比例接近翻倍，代表這些新增的程式碼平均而言更需要被來回確認。留言數增加 35%，意味著審查者花在溝通和質疑上的力氣也變多了。這跟單純把同樣品質的程式碼數量乘以 1.3，是不一樣的負擔。
原因不難想像。人自己寫的程式碼，寫的人心裡清楚每個判斷是怎麼來的；AI 生成的程式碼，提交者有時也只是「看起來沒問題就送出去了」。當提交者對自己送出的內容理解不夠深，審查者就得補上那部分的理解成本。審查這件事，從「確認一個同事的想法」變成「替一段來路較不透明的程式碼做身家調查」。
導入率已經到頂，AI 審查卻還沒跟上
研究另外兩個數字也值得放在一起看。
第一，企業導入率從 2024 年底的接近於零，一路爬到 2026 年初的超過 95%。這代表 AI 編碼代理人已經不是早期採用者的選配，而是預設狀態——討論「要不要用」已經沒有意義，該討論的是「用了之後流程要怎麼改」。
第二，約有 80% 的公司已經導入 AI 輔助的程式碼審查工具，但實際上只有大約 23% 的審查留言是由 AI 產生的。工具裝上去了，承擔的比重卻遠不如預期。
這兩個數字擺在一起，解釋力相當強：產出端的 AI 已經全面上線並且被充分信任，審查端的 AI 雖然也上線了，卻還沒有被信任到可以真的替人分擔判斷。這是合理的——審查的本質是承擔責任，而責任目前還很難外包給模型。
Photo by Sasun Bughdaryan on Unsplash
對團隊的實際影響
對正在評估或已經導入 AI 編碼工具的團隊，這份研究至少指出三件值得注意的事。
一、用產出量當成效指標，會得到錯的結論。如果一個團隊的 AI 導入成效是用「程式碼行數」「commit 數」「PR 數」來衡量，這份研究預測它一定會看到漂亮的數字——而且那些數字不保證對應到任何交付上的改善。要看出真實效果，指標得往下游移：從需求進入到上線的前置時間、單位時間內關閉的需求數、上線後的缺陷率。
二、審查量能必須一起規劃。研究中被捲入審查的人數增加了 14%，這個成本通常不會出現在任何導入評估的試算表裡，卻是實際發生的。如果上游加速是用工具預算買來的，下游的量能缺口也需要對應的安排——可能是審查責任的重新分配，可能是把 PR 切得更小以降低單次審查的認知負擔，也可能是要求提交者附上更完整的脈絡說明。
三、AI 生成的程式碼需要不同的審查方式。退改率接近翻倍這個訊號，指向的是提交品質的變異性變大了。對應的做法未必是「審得更久」，而是「審得更有結構」——把自動化測試、靜態分析、型別檢查這些機器能做的部分盡量前移，讓人類審查者的時間能花在機器判斷不了的地方：這段邏輯符不符合業務規則、這個抽象層次是不是這個專案該有的、這個改動會不會在三個月後變成技術債。
這份研究的侷限
持平地說，這份論文的結論需要幾個保留。
它是工作論文（working paper），尚未經過同儕審查。資料全部來自 Jellyfish 單一分析平台，會使用這類工程分析工具的公司，本身就不是軟體業的隨機樣本。研究是觀察性的，要從中分離出 AI 的因果效果，難度本來就高——同一段期間還發生了裁員潮、遠距工作模式的變化、利率環境對研發投資的影響，這些都可能干擾結果。
還有一個時間因素：2026 年初導入率才剛衝到 95%，大多數公司採用 AI 編碼代理人的時間並不長。流程改造通常落後工具導入好幾個季度，現在觀察到的「沒有顯著增加」，有機會只是尚未被吸收的過渡狀態。
但即使把這些保留都算進去，核心的觀察仍然成立：在 718 家公司、3 億筆事件的規模上，程式碼產出與實際交付之間出現了明確的脫鉤，而審查環節的指標同時惡化。這個組合不太可能全部來自雜訊。
觀點
這份研究最有價值的地方，或許不是它對 AI 編碼工具下了什麼評價，而是它提醒了一件容易被忽略的事：生產力工具的效益，上限取決於流程中沒有被工具加速的那一段。
目前市面上關於 AI 編碼的討論，絕大多數集中在「模型會不會寫」「寫得好不好」「能不能跑起來」。這些問題確實重要，但如果一個組織的瓶頸是審查量能、是需求定義的模糊、是部署流程的摩擦，那麼把寫程式這一站再加速 50%，對最終交付的幫助可能接近於零。
換個角度看，這也不是壞消息。它意味著接下來真正有價值的改進空間，不在模型本身，而在流程與工具鏈的其他環節——更可靠的自動化測試、更細緻的變更影響分析、能真正承擔部分判斷責任的審查輔助。模型能力的曲線已經很陡了，現在輪到流程追上來。
對一般團隊來說，可以先做的事情其實很樸素：看一下自己團隊的 PR 平均停留時間，過去一年是變長還是變短。如果它變長了，那麼下一筆預算該花的地方，可能不是再買一套更強的程式碼生成工具。
資料來源：Fiona Chen、James Stratton，《Artificial Intelligence in the Firm: Bottlenecks in Software Production》（哈佛工作論文）；相關報導整理自 Forkast、Ars Technica 等媒體於 2026 年 10 月的分析。本文為公開資訊之整理與觀察，研究結論屬工作論文階段，尚未經同儕審查。