哈佛研究：AI 程式碼增加審查負擔，未顯著提升整體開發產出
文章摘要
哈佛大學針對718間企業、橫跨2021至2026年的研究顯示，儘管AI程式碼輔助工具與代理程式提升了程式碼產出量，卻未顯著提高整體開發成果。數據指出，AI代理程式雖使程式碼行數增加30%、提交量增加20%、合併請求（PR）增加23%，但每人每月解決的專案任務僅成長12%，遠低於代碼成長幅度。研究發現開發流程後端出現瓶頸，尤其是程式碼審查負擔加劇：PR審查時間平均增加49%，單一PR的評論數量上升53%，需修改的PR比例更翻倍成長，參與審查的工程師比例亦增加14%，且AI並未顯著改善審查效率。分析指出，工程師實際撰寫程式碼僅佔工作時間30%至40%，其餘時間投入規劃、測試與部署。當AI加速代碼撰寫，其他環節便成為限制因素。此外，AI生成內容可能隱含幻覺風險，導致工程師對程式碼掌握度降低，隨系統擴展，修復問題的複雜度與頻率恐將成為衡量AI影響力的關鍵指標。該研究整合人力資源、版本控制與Jira等跨系統數據，共涵蓋約3億筆工作紀錄。
AI 大叔解析
## 【核心判斷】
AI 代理（Agent）雖然讓程式碼產出效率大幅提升，但隨之而來的「審查後遺症」已成為壓垮開發產出的瓶頸；這份涵蓋 2021 年至 2026 年、分析 3 億筆工作紀錄的哈佛研究，明確揭示了當前工程界過度迷信產量指標的盲點。
簡單說，現在的 AI 就像一個拼命幫你塞雜物的實習生，雖然填滿了倉庫（程式碼），但卻讓後續負責清點與驗收的工程師（審查者）陷入了無止盡的重工循環。當程式碼行數增加 30%，但實際交付的 Jira 任務僅成長 12% 時，這中間的「溢價」全被程式碼審查（PR）過程中的時間增加 49%、評論增加 53% 給吃掉了。更諷刺的是，審查負擔加劇並非單純因為 PR 變大，而是品質與可控性出現了結構性問題。
## 【毒舌吐槽】
這場景實在太熟悉了，管理層最愛看什麼「提交次數」或「程式碼行數」這種充滿欺騙性的 KPI（關鍵績效指標），彷彿程式碼是用斤兩在賣一樣。AI 代理確實達成了一次「垃圾生產力的偉大躍進」，但工程師花在檢查這堆「AI 隨機生成物」的時間，遠遠超過直接手寫的成本。這不僅是典型的 Infra Bottleneck（基礎設施瓶頸，此處指審查環節的處理能力），更像是用 AI 製造了更多需要人肉除錯的「技術債」，最後還得由人類工程師在最後一哩路幫這些不具惡意的「幻覺產物」擦屁股。
## 【為什麼重要？】
這項研究數據顯示，現代軟體開發中真正撰寫程式碼的時間其實僅佔 30% 至 40%，其餘大把時間都花在規劃、測試與部署。當我們導入 AI 工具（如 GitHub Copilot、Cursor 或 Claude Code）加速了那 30% 的環節，原本隱藏在開發流程後端的瓶頸就立刻顯形。特別是當審查 PR 時需要修改的比例翻倍，代表 AI 生成的內容若非邏輯有問題，就是缺乏維護者所需的脈絡，導致工程師對程式碼的「擁有感」與掌握度急速下降。
隨著系統規模擴張，當開發者無法完全理解自己送出的程式碼時，系統的「平均修復時間」（Mean Time to Recovery）勢必成為比產出量更核心的指標。這意味著企業如果還在吹噓 AI 帶來的產能提升，卻沒看到審查環節正在崩潰，那這波技術升級帶來的只是「提早發生的維運災難」。
## 【影響對象與建議】
- **軟體開發團隊主管**：停止將「程式碼產出量」作為效能考核基準。請重新調整審查機制，將「審查後的重工率」與「修復複雜度」納入開發流程的監控指標，優先解決審查瓶頸，而非盲目追求 PR 數量。
- **資深架構師**：務必建立嚴格的 AI 代碼審查準則。既然 AI 代理生成的程式碼無法確保邏輯品質，請強制要求 AI 產出內容必須經過自動化測試驗證後，才能進入人工審查環節，降低人類工程師在無意義改動上的時間損耗。
- **技術決策者**：不要誤以為導入 AI 工具就能直接線性提升產能。請預留 20% 至 30% 的專案時程用於處理 AI 生成代碼的額外審查負擔，並確保團隊在擴展系統時，具備對 AI 代碼的解構與維護能力。
## 【逆風觀點】
原文並未提供針對 AI 工具細部設定（如 Prompt 工程或限制條件）對審查負擔的影響差異，因此目前難以斷定這是否僅為過渡期的摩擦，或 AI 輔助開發的內在侷限。證據不足以斷言 AI 代理在所有軟體架構規模下都無法提升產出，僅能確認在當前 2026 年前的開發環境中，審查環節的效率優化尚跟不上程式碼生成的速度。
AI 代理（Agent）雖然讓程式碼產出效率大幅提升，但隨之而來的「審查後遺症」已成為壓垮開發產出的瓶頸；這份涵蓋 2021 年至 2026 年、分析 3 億筆工作紀錄的哈佛研究，明確揭示了當前工程界過度迷信產量指標的盲點。
簡單說，現在的 AI 就像一個拼命幫你塞雜物的實習生，雖然填滿了倉庫（程式碼），但卻讓後續負責清點與驗收的工程師（審查者）陷入了無止盡的重工循環。當程式碼行數增加 30%，但實際交付的 Jira 任務僅成長 12% 時，這中間的「溢價」全被程式碼審查（PR）過程中的時間增加 49%、評論增加 53% 給吃掉了。更諷刺的是，審查負擔加劇並非單純因為 PR 變大，而是品質與可控性出現了結構性問題。
## 【毒舌吐槽】
這場景實在太熟悉了，管理層最愛看什麼「提交次數」或「程式碼行數」這種充滿欺騙性的 KPI（關鍵績效指標），彷彿程式碼是用斤兩在賣一樣。AI 代理確實達成了一次「垃圾生產力的偉大躍進」，但工程師花在檢查這堆「AI 隨機生成物」的時間，遠遠超過直接手寫的成本。這不僅是典型的 Infra Bottleneck（基礎設施瓶頸，此處指審查環節的處理能力），更像是用 AI 製造了更多需要人肉除錯的「技術債」，最後還得由人類工程師在最後一哩路幫這些不具惡意的「幻覺產物」擦屁股。
## 【為什麼重要？】
這項研究數據顯示，現代軟體開發中真正撰寫程式碼的時間其實僅佔 30% 至 40%，其餘大把時間都花在規劃、測試與部署。當我們導入 AI 工具（如 GitHub Copilot、Cursor 或 Claude Code）加速了那 30% 的環節，原本隱藏在開發流程後端的瓶頸就立刻顯形。特別是當審查 PR 時需要修改的比例翻倍，代表 AI 生成的內容若非邏輯有問題，就是缺乏維護者所需的脈絡，導致工程師對程式碼的「擁有感」與掌握度急速下降。
隨著系統規模擴張，當開發者無法完全理解自己送出的程式碼時，系統的「平均修復時間」（Mean Time to Recovery）勢必成為比產出量更核心的指標。這意味著企業如果還在吹噓 AI 帶來的產能提升，卻沒看到審查環節正在崩潰，那這波技術升級帶來的只是「提早發生的維運災難」。
## 【影響對象與建議】
- **軟體開發團隊主管**：停止將「程式碼產出量」作為效能考核基準。請重新調整審查機制，將「審查後的重工率」與「修復複雜度」納入開發流程的監控指標，優先解決審查瓶頸，而非盲目追求 PR 數量。
- **資深架構師**：務必建立嚴格的 AI 代碼審查準則。既然 AI 代理生成的程式碼無法確保邏輯品質，請強制要求 AI 產出內容必須經過自動化測試驗證後，才能進入人工審查環節，降低人類工程師在無意義改動上的時間損耗。
- **技術決策者**：不要誤以為導入 AI 工具就能直接線性提升產能。請預留 20% 至 30% 的專案時程用於處理 AI 生成代碼的額外審查負擔，並確保團隊在擴展系統時，具備對 AI 代碼的解構與維護能力。
## 【逆風觀點】
原文並未提供針對 AI 工具細部設定（如 Prompt 工程或限制條件）對審查負擔的影響差異，因此目前難以斷定這是否僅為過渡期的摩擦，或 AI 輔助開發的內在侷限。證據不足以斷言 AI 代理在所有軟體架構規模下都無法提升產出，僅能確認在當前 2026 年前的開發環境中，審查環節的效率優化尚跟不上程式碼生成的速度。