程式代理和軟體交付差在哪？怎麼衡量

程式代理能更快產生程式碼，團隊就會更快交付軟體嗎？這兩件事之間還隔著審查、測試、整合與部署。哈佛大學研究者 Fiona Chen 與 James Stratton 分析企業工程活動後，觀察到程式代理採用與程式碼產量增加相關，但 Jira 工作完成量沒有統計顯著的增加。對團隊而言，關鍵是分辨「產生更多程式碼」和「讓使用者拿到更多完成的功能」，再找出產量停在哪一個環節。

程式碼產量增加，先確認軟體交付是否增加

研究樣本中的程式代理採用與程式碼行數、commit 及 Pull Request 增加相關；但研究沒有觀察到 Jira issue 與 epic 解決量有統計顯著的增加。程式活動上升是中間指標，不能直接當成交付成果。

研究使用 Jellyfish 工程分析平台中同意資料供研究的企業資料，涵蓋 718 家公司、約 72.6 萬名工作者，以及 2021 年 1 月至 2026 年 3 月的工作紀錄。資料連結版本控制、工作追蹤等系統，讓研究者可以同時觀察程式活動和工作完成情形。這個範圍比單看某位工程師的完成時間，更接近企業導入工具後的整體變化。

作者把程式活動分成程式碼行數、commit 和 Pull Request。程式碼行數記錄新增的程式碼；commit 是一次保存到版本控制系統的修改；Pull Request（合併請求）則是提交給團隊審查、準備併入共同程式庫的一組變更。

研究估計，導入程式代理後，每位工作者的程式碼行數增加約 30%，commit 增加約 20%，Pull Request 增加約 23%。三者都反映工作活動增加，卻各自只描述軟體生產流程的一部分。

工作的完成狀態由另一套指標衡量。研究以 Jira issue（工作項目）解決量代表一個離散任務完成，並以 Jira epic（大型功能或專案）解決量觀察較大的成果。

issue 通常要等程式碼經審查、測試並部署後才標記完成；程式碼已提交或 Pull Request 已合併，並不表示功能已經上線。研究在兩種完成指標上都沒有發現統計顯著的增加。這表示資料不足以支持「程式代理讓企業交付更多」的結論，也不等於證明每家公司都完全沒有變化。

「程式碼生產力的提升，沒有完全轉化成軟體產出或雇用變化。」這是 Chen 與 Stratton 對研究結果的摘要，說明衡量工具成效需要追到工作完成端。

人工審查為何可能吸收程式代理的效率收益

當更多程式碼與 Pull Request 同時進入團隊，審查者必須判斷變更是否正確、能否與既有程式整合，以及是否需要修改。研究觀察到代理採用後審查時間及修改往返增加，支持審查流程可能成為企業產出轉換的瓶頸。

研究估計，程式代理採用後，平均 Pull Request 審查時間增加 49%；要求修改的 Pull Request 比例接近翻倍；每件 Pull Request 的留言數增加 35%。參與程式碼審查的工作者比例也增加 14%。這些變化顯示，增加的程式活動需要更多檢查與協調。數字描述的是樣本企業的平均估計，不代表每一個團隊都會增加相同幅度，也不能單憑這幾個結果判定所有新增審查工作都由 AI 程式碼造成。

程式交付有先後相依的步驟：先界定需求，再撰寫程式，接著由團隊審查與測試，最後部署到正式環境。上游寫程式變快時，下游若仍以原有容量處理更多變更，等待時間就可能拉長。修改要求與留言增加，也會讓作者和審查者多幾輪往返。於是，產量增加可能表現在待審工作堆積，而非已部署功能增加。

這解釋了為什麼「生成速度」無法單獨代表交付速度。審查者要理解變更的目的、檢查邊界情況、確認測試覆蓋並評估對其他模組的影響；測試失敗或整合衝突還可能要求重新修改。每個環節都需要時間和明確責任。若團隊只獎勵程式碼量或 Pull Request 數量，指標可能鼓勵提交更多小改動，卻看不出需求是否完成、品質是否符合預期。

研究也提到，即使企業開始使用 AI 協助審查，人工審查仍占重要位置。研究資料中，截至觀察期末，約八成受觀察企業使用某種 AI 程式碼審查工具；但代理所負責的審查留言和 Pull Request 仍只是部分。因此，不能因為多了審查工具，就假設人力負荷已自動消失。團隊仍須決定哪些檢查可交由工具輔助，哪些風險與架構判斷需要人負責。

Chen 與 Stratton 在論文摘要指出，程式代理採用後，審查耗時增加、需要修改的程式更新比例提高，審查留言也變多。這些觀察讓「程式碼增加後，誰有能力驗證」成為導入評估的一部分。

這項研究能說明什麼，不能直接推論什麼

不能直接套用。研究使用同意提供資料的 Jellyfish 客戶企業，並比較不同時間採用工具的公司；結果反映企業層級的平均變化，會受樣本組成、任務類型與採用方式限制。

這篇論文是 2026 年 8 月 4 日版本的工作論文，尚非同儕審查期刊論文。研究資料來自同意供研究使用的企業，並非所有產業、公司規模或開發流程的完整樣本。

企業使用的平台和工作追蹤習慣也會影響哪些活動能被記錄，因此應把它視為企業層級的實證觀察，不能當成適用所有開發團隊的保證。

研究採用分階段差異中之差異設計，比較較早採用與較晚或未採用企業在導入前後的變化。這種設計的因果解讀仰賴一項前提：如果沒有採用工具，這些企業的結果原本會沿著相近趨勢變化。作者檢查導入前的趨勢，也控制企業規模等因素，但無法讓這項前提變成可直接觀察的事實。若採用時點同時受到企業成長策略或其他因素影響，估計仍可能受到未觀察差異干擾。

資料觀察至 2026 年 3 月，之後程式代理、審查工具與團隊流程都可能改變。研究測量的是公司層級採用效果，不能直接推論每一位工程師使用工具後都會增產 30%，更不能推論各團隊會得到相同的交付或品質結果。代理的使用頻率、工作難度、既有測試能力、程式架構和審查分工，都是可能造成差異的因素。

解讀結果時也要分開「沒有統計顯著的增加」和「證明毫無效果」。研究對程式代理影響 Jira issue 解決量的估計，信賴區間排除了高於基準平均值 12% 的增幅；這讓研究者能指出，樣本內交付量沒有跟程式活動一比一擴大。但特定小型團隊或特定任務可能有不同表現，仍需以自身流程資料判讀。

團隊如何衡量程式代理帶來的實際交付

先追蹤已完成並部署的需求，再把程式活動和品質、等待及返工指標放在一起看。這樣才能判斷產量增加後，變更是否順利通過審查、測試與整合。

導入前先定義可比較的基準期間與工作範圍，記錄已完成的 issue、已交付的 epic、部署頻率，以及回報錯誤或回退情形。試行期間沿用相同口徑，避免把工作項目拆得更小、改變標記習慣或調整發布節奏，誤當成生產力變化。若版本發布涉及不同風險或任務類型，應分層比較，避免把簡單修正與大型功能混成一個平均數。

接著觀察流程在哪裡等待。可以記錄 Pull Request 從建立到首次審查、從提交到合併的時間，要求修改的比例、每件變更的審查往返次數，以及測試和整合所花時間。這些數據能幫助團隊區分等待審查、測試失敗、需求不清或整合衝突。程式碼行數與提交次數仍有參考價值，但應作為活動量指標，和已部署成果及品質變化一起解讀。

返工也要有明確定義，例如部署後回報的缺陷、回退、重開工作項目，或因審查發現問題而重做的工時。若只記錄修改請求次數，可能把合理的設計討論和缺陷修正混為一談；把原因分類後，團隊才知道是代理產生的程式需要更仔細驗證、需求拆解不完整，還是測試環境不足。衡量目的在於找出流程中需要改善的環節，工具評價只是其中一項參考。

當審查等待變長，可以先看變更是否太大、審查者是否集中在少數人，以及是否有明確的程式所有權與風險分級。當測試與整合時間拉長，則應檢查測試覆蓋、相依套件和部署方式。若需求完成數沒有上升、但各種排隊指標增加，團隊增加的可能是待處理工作；若交付改善且缺陷沒有惡化，才有理由討論擴大採用。這些指標用來定位問題，不能取代團隊對系統風險和使用者需求的判斷。

AI 程式碼審查可以協助整理差異、指出可疑片段或補充檢查項目，但研究顯示人仍參與多數審查工作。團隊應明確設定自動檢查的範圍、升級給人的條件，以及誰對合併和部署負責。審查自動化能否減少瓶頸，應以等待時間、漏檢缺陷與返工情形檢視，不能只看工具產生了多少評論。

實際評估可從四項基準開始：需求完成與部署結果、審查等待和修改往返、測試整合時間、部署後缺陷與返工。試行期間保持相同的定義，定期比較工具導入前後各環節，再依瓶頸調整需求拆分、測試、審查分工或工具使用範圍。產量提高只是流程中的一個訊號，能否轉成穩定交付，仍要看整條生產流程是否承接得住。

• 程式碼、commit 與 Pull Request 是活動指標，不能替代需求完成和部署結果。
• 審查等待、修改往返、測試整合與返工，能協助定位產量未轉成交付的原因。
• 導入前後使用相同口徑比較，依實際瓶頸調整工具與流程。

1. 導入前記錄需求完成、部署、審查等待與返工基準。
2. 試行期間沿用同一套定義，按任務類型比較。
3. 找出新增工作停留的環節，再調整測試、審查分工或需求拆解。

常見問題

常見問題

Q1：程式碼變多是否代表生產力提高？

程式碼行數增加表示程式活動變多，但不必然代表更多需求已完成或功能已部署。應搭配 issue、epic 解決量、部署與品質指標判讀。

Q2：團隊要用哪些指標評估程式代理？

可追蹤已完成需求與部署結果，並同步觀察審查等待、修改往返、測試整合時間、部署後缺陷及返工。指標定義需在導入前後保持一致。

Q3：AI 程式碼審查能否取代人工審查？

這項研究顯示，研究期間企業仍大量依賴人工參與審查。AI 工具可協助檢查，但是否能減少特定團隊的審查負荷，要依品質、等待時間和責任分工實測。