· 約 3 分鐘閱讀 · AI 與 Agent
AI Agent 讓程式碼多了三成，交付卻沒變多：瓶頸其實在 Code Review
哈佛一份橫跨 700 多家軟體公司的研究發現：導入 AI coding agent 後，程式碼、commit、PR 都明顯增加，但完成的 issue 數沒有顯著變化。整理研究重點，以及團隊該把投資放在哪裡。
AI Agent 讓程式碼多了三成，交付卻沒變多
10 月中，Ars Technica 報導了一份哈佛工作論文（Fiona Chen、James Stratton，尚未經同儕審查）。標題很直白：AI coding agent 產出更多程式碼，但沒有產出更多軟體。
這份研究值得花五分鐘看，因為它用的不是問卷或實驗室任務，而是真實公司的工作紀錄。
一、研究怎麼做
- 資料：工程分析平台的遙測資料，涵蓋 700 多家軟體公司、約 3 億筆工作事件，時間從 2021 年到 2026 年 3 月。
- 方法：各公司導入 AI 工具的時間點不同，研究比較「已導入」與「尚未導入」的公司，看導入前後的變化。
- 區分兩種工具：自動補完型的 coding assistant，以及會自己接任務、產出修改的 coding agent。
二、結果：上游變多，下游沒動
導入 coding agent 之後，每位工程師平均：
| 指標 | 變化 |
|---|---|
| 程式碼行數 | 約 +30%（每月多近 1,500 行） |
| Commit 數 | 約 +20% |
| Pull request 數 | 約 +23% |
| 完成的 Jira issue | 沒有統計上顯著的變化 |
公司層級的人數也沒有因此明顯減少。作者的結論是：生產力的提升，沒有完整傳遞到軟體產出或人力上，而是被流程下游的限制吸收掉了。
三、被吸收到哪裡？Code Review
報導裡最有意思的是 review 端的數字：
- PR 從送出到合併的 review 時間增加約 49%
- 被要求修改的 PR 比例幾乎翻倍
- 每個 PR 的 review 留言數增加約 35%
- 參與 code review 的工程師比例增加約 14%
換句話說，寫程式變快了，但 review 的人變忙、退件變多、等待變長。到 2026 年 3 月，約 80% 的公司已經在用某種 AI code review，但 AI 只貢獻了 23.3% 的 review 留言、出現在 10.8% 的 PR 上——review 這一段，主要還是靠人。
作者的建議也很明確：要拿到 AI 的效益，需要同步投資下游的 review 能力，而不是只追求更多程式碼。
四、我怎麼解讀：這不是「AI 沒用」
這份研究很容易被讀成「AI 寫 code 是假的」。我不這麼看。它真正說的是：軟體交付是一條產線，只加速其中一站，整條線的速度由最慢的那站決定。
這和我在 AI 導入實戰 裡談的原則一樣：自動化可以接手執行，但驗收與權限要留在人手上。而一旦執行變便宜，驗收就成了新的瓶頸。
需要注意的限制：
- 這是工作論文，還沒經過同儕審查。
- 「完成的 issue 數」是很粗的產出指標，品質、可維護性、事故率都沒算進去。
- 資料截至 2026 年 3 月，之後的 agent 與 AI review 工具又進步了不少。
五、給團隊的四個調整
1. 不要再用行數和 commit 數衡量效益
研究直接點出，很多主管依賴這類中間指標。導入 agent 後它們一定會漲，但那不代表交付變多。改看 lead time（從開單到上線）、每個 PR 的 review 等待時間、退件率。
2. 讓 PR 變小、變好審
agent 很容易一次改一大片。在指引或 AGENTS.md 裡寫清楚：一個 PR 只做一件事、附上驗證步驟、說明改了什麼與為什麼。好審的 PR 比多寫的程式碼更有價值。
3. 把機械性檢查交給 CI，人只看判斷題
型別、lint、測試、建置、安全掃描，全部在 PR 進到人手上之前跑完。人的 review 時間留給架構、邊界條件和商業邏輯——也就是我在 Code Review Checklist 裡列的那些。
4. 把 review 當成正式產能來規劃
如果團隊導入 agent 後產出多了兩成 PR，review 的時間就要跟著編列，而不是默默壓在資深工程師的下班時間上。AI review 可以先過濾，但最後的放行要有明確的負責人。
AI 工具讓「寫出程式碼」變便宜了，真正的競爭力轉移到「確認它是對的、然後安全地交付」。如果你的團隊導入 AI 後感覺很忙、但上線速度沒有變快，可以預約 30 分鐘初談，一起找出卡住的那一站。