背景
AI 程式碼助理與 AI Agent 常被視為提升軟體開發效率的重要工具，但「產生更多程式碼」不一定等於「完成更多工作」。InfoQ 於 2026 年 10 月 22 日報導哈佛大學的一項研究，指出 AI 工具雖然能增加程式碼產量，實際交付成果卻受到後續流程限制，其中最明顯的瓶頸是程式碼審查。
這項研究以 718 家企業使用 Jellyfish 軟體工程分析平台時累積的資料為基礎。Jellyfish 是用於衡量與分析軟體工程效能的平台，可整合人力資源、版本控制、議題管理、行事曆與 AI 開發工具的資料，以觀察工程活動與交付結果之間的關係。資料涵蓋 2021 年 1 月至 2026 年 3 月，約有 70 萬名工作者、700 多家企業及 3 億筆工作事件；其中也納入 GitHub Copilot、Cursor 與 Claude Code 等工具的使用紀錄。
核心發現
研究先以新增程式碼行數、提交紀錄與拉取請求三項指標衡量寫程式產量。AI 程式碼助理帶來的增幅相對有限：程式碼行數增加 12%，提交紀錄增加 9%，拉取請求增加 5%，其中只有提交紀錄的變化達到統計顯著。相較之下，AI Agent 在三項指標上的成長更明顯，分別為 30%、20% 與 23%，而且均具有統計顯著性。
不過，研究改用 Jira 議題與 Epic 的完成數量評估實際工程產出。Jira 議題代表一項可交付的個別工作，Epic 則是涵蓋多項任務的較大型功能或專案。結果顯示，程式碼助理並未增加每名工作者每月完成的議題數；AI Agent 雖使完成數增加 12%，仍明顯低於新增程式碼行數所呈現的 30% 增幅。這道落差顯示，單純用程式碼量衡量 AI 生產力，容易高估交付效率。
真正的瓶頸在哪裡
軟體開發並非只有寫程式。從需求與範圍規劃、程式碼審查、測試到部署，許多工作都會影響功能能否真正交付。研究根據 Jellyfish 資料推估工程活動的時間分配，並以 100 名 Prolific 平台工程師的調查進行驗證，結果顯示工程師約有 30% 至 40% 的時間用於撰寫程式碼，其餘時間則投入上述輔助工作。
當 AI 讓寫程式變快，原本足以消化新增內容的後續流程可能來不及跟上。資料顯示，使用 AI 後，平均每個拉取請求的審查時間增加 49%，每個請求收到的審查留言增加 53%，需要修改后才能合併的拉取請求比例則翻倍。參與程式碼審查的工作者比例增加 14%，但採用 AI 輔助審查並未帶來相應改善。研究者也確認，拉取請求相關投入的增加，不能單以每個請求的程式碼規模變大來解釋。
影響與限制
這項結果不代表 AI 程式碼毫無價值，而是凸顯產量與交付之間存在結構性落差。若組織只計算新增行數、提交或拉取請求數，可能會誤以為 AI 已有效提升工程生產力；真正需要追蹤的是完成並可使用的議題、部署成果、審查耗時、修改比例及缺陷修復效率。AI 產生更多程式碼時，團隊也必須同步強化審查、測試與部署能力，否則瓶頸只會向下游移動。
研究同時帶來幾項限制。其資料來自採用 Jellyfish 的企業，涵蓋多種工具與工作情境，結果主要反映平台使用者的實際活動；部分產量指標的變化未達統計顯著，也表示不能把觀察到的關聯直接視為所有企業都會出現的因果效果。以 Jira 議題完成數代表工程成果，雖然比程式碼行數接近交付，但仍可能受到議題拆解品質、專案優先順序及外部依賴影響。
受訪者在討論中提出的風險，也值得與研究結果分開看待。AI 可能產生幻覺，即生成看似合理但實際錯誤的內容；當工程師對所交付程式碼的理解下降，故障診斷與復原可能更加困難。因此，平均恢復時間可能成為評估 AI 對軟體交付影響的另一項重要指標，但該研究本身並未直接驗證這項效果。
整體而言，這項哈佛研究提供的主要觀點是：AI 確實能提高寫程式活動的數量與速度，卻未必能按相同比例提高整體開發產能。當程式碼審查、測試、部署與維護成為瓶頸時，增加上游產量反而可能放大下游負擔。評估 AI 開發工具時，應以完整交付流程及最終成果為核心，而不是只看模型寫出了多少程式碼。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。