程式代理起草四成 PR 之後：軟體業最缺的不是寫手，是敢簽名驗收的人

台灣科技週刊｜AI 與軟體工程深度分析 資料查核截至：2026 年 11 月 5 日

軟體業的瓶頸正在搬家。GitHub 年度報告 Octoverse 顯示，2026 年 9 月有 1.1 億筆 PR 的初稿來自可偵測的程式代理，占當月四成以上，3 月還只有 17%。PR（pull request）是開發者提交程式變更、請同事審查後併入主線的標準流程；程式代理則是能自行讀專案、改多個檔案、執行指令的 AI 工具。寫程式變便宜了，判斷一段程式能不能上線卻沒有跟著變便宜。

本刊把這個新上限稱為「驗收帶寬」（Acceptance Bandwidth）：一個組織在判斷品質不下滑的前提下，單位時間內真正讀得懂、驗得過、也有人願意具名負責的程式變更量。過去一個月的三件事讓這個概念有了數字：Octoverse 的規模資料、一篇 11 月 1 日更新的哈佛論文，以及廠商開始把「審查」與「核准」做成可計費、可開關的產品。

程式代理真的讓軟體變多了嗎？

程式碼確實變多，完工的軟體沒有等比例變多。哈佛的 Fiona Chen 與 James Stratton 在論文〈Artificial Intelligence in the Firm〉11 月 1 日版中，分析工程分析平台 Jellyfish 的 655 家企業、72 萬名員工、4.45 億筆工作事件，比較各公司導入 AI 工具前後的變化。這是兩人的求職論文，本刊未見已經過同儕審查；資料由商業平台提供，樣本多為中大型成熟企業。

資料來源：Chen & Stratton 論文 2026 年 11 月 1 日版，資料期間 2021 年 1 月至 2026 年 8 月。

用本刊的算法，PR 增幅只有約 38% 傳到完工量（13.7÷35.7）。原因不神秘：論文估計工程師只花 30% 到 40% 的時間寫程式，其餘是審查、規劃與協調。加速其中一段，整條生產線的速度仍由最慢的環節決定。

這不代表工具沒用。研究機構 METR 2025 年那項「AI 讓資深開發者慢 19%」的實驗常被引用，但 METR 今年 2 月已表示，後續實驗顯示開發者很可能比 2025 年初更快，資料卻不足以判斷快多少：有 30% 到 50% 的開發者說，他們因為不想在沒有 AI 的情況下做某些工作而沒有提交任務。當受試者不願意回到對照組，隨機實驗本身就開始失靈，這也是企業遙測資料變得重要的原因。

GitHub 說代理 PR 合併率 90%，為什麼不能當品質證明？

因為合併率量到的是閘門有多鬆，不只是程式有多好。Octoverse 指出，有代理參與的 PR 兩週內合併的比率從 2 月的 83% 升到 9 月的 90%，未偵測到代理的對照組維持約 86%。讀起來像代理已經超過人類，但同一件事換個資料集，答案差很遠。

四個數字的母體、定義與時間都不同，不能直接比較。GitHub 沒有說明分母是否包含最終未合併的 PR，這個數字也未區分個人專案與企業團隊；本刊推論，個人專案常由作者自己按下合併，比率自然偏高。LinearB 是工程效能工具商，報告自承相關不等於因果，且未標明資料期間，較新的模型也可能已改變結果。

更值得注意的是 Octoverse 沒寫什麼。本刊逐句搜尋該報告全文，它公布了 343 億次提交、13 億筆合併 PR，卻沒有審查時間、審查留言數或人工審查覆蓋率。卡內基美隆與史丹佛研究者的論文說得直接：審查一旦變寬鬆或自動化，閘門本身就換了，合併率能說明的品質很有限。

審查跟不上時，公司實際上怎麼處理？

壓力只有兩個出口：讓程式排隊，或讓閘門變薄。哈佛論文呈現的是第一種。多數企業的人工審查者不夠，程式等得更久、審得更久，論文引述一名資淺工程師的訪談：整個專案只有一位資深工程師能核准，他的程式碼一週才等得到一次審查；AI 造成事故後，公司又要求 AI 程式碼須由資深者核准，塞車更嚴重。

第二種出口出現在卡內基美隆與史丹佛研究者 He 等人的個案研究，10 月 27 日修訂的版本追蹤一家未具名的中型公司 802 名開發者、19.6 萬筆 PR。該公司技術長 2025 年 6 月訂下「每人合併 PR 翻倍」目標，第十個月達標。代價是：PR 總量成長 3.1 倍，審查者只成長 1.5 倍，每位審查者負荷約翻倍。至少有一次人工審查的 PR 從 89% 掉到 68%，AI 審查從約 19% 升到約 84%；附人工留言的實質審查從約 39% 掉到約 21%，一般審查者的「不留言直接核准」次數約翻倍。

這家公司並未崩潰。回退（revert）比率沒有上升，合併後的修補也沒有增加，作者認為這是反對「品質急遽崩壞」的證據，但也明言這些短期指標看不到長期缺陷與可維護性，且該公司 AI 預算不設限，結果應視為上限而非業界平均。

本刊認為這兩個案例的差別才是重點。排隊的成本看得見，會出現在交付時程上；閘門變薄的成本看不見，而且會讓「合併 PR 數」這類 KPI 更好看。兩者的距離也很大：哈佛樣本中 79.1% 的企業用過 AI 審查，但只有 10.8% 的 PR 收到至少一則 AI 留言，AI 留言占全部審查留言 23.3%；前述個案公司的 AI 審查覆蓋率已達約 84%。多數企業還在第一條路上，但工具正把它們推向第二條。

AI 審查能不能代替人類簽名？

技術上已經可以，但各家廠商的答案開始分岔。GitHub 10 月 28 日宣布 Copilot 的核准功能正式上線，開啟後 Copilot 的核准可計入儲存庫要求的必要核准數；OpenAI 9 月 29 日的 DevDay 也把程式碼審查與 Codex Security Cloud 掛進 Codex。以下整理自各家目前的官方文件：

資料日期：2026 年 11 月 5 日查閱各廠商文件。

核准欄位不只是流程的一格，它是事後追查時「誰看過、誰同意」的紀錄。當 AI 可以填進這一格，組織要回答的問題就從「AI 審得準不準」變成「出事時誰負責」。GitHub 稱 Max 在其 ReviewBench 測試的高嚴重度問題上得到最高 F1 分數，這是公司自述；同一家公司的文件也寫著 Copilot 不保證抓到所有問題，並建議搭配人工審查。

計費方式同樣改變了驗收的性質。本刊在〈席位不再是答案〉談過軟體正從席位轉向用量，審查現在也上了計量表：Claude Code Review 的文件寫明，額度用盡時審查會被略過。依賴這類工具的團隊要想清楚，月底預算用完的那天，閘門由誰來守。

測試全綠，能證明程式碼安全嗎？

不能，而且最新的測試結果把差距量出來了。資安業者 Semgrep 9 月 29 日用 SusVibes 測試 Claude Opus 5.5。這套測試由 186 個來自真實漏洞的開源專案任務組成。結果 93.5% 的解答通過專案功能測試，同時通過資安修補測試的只有 54.8%；能運作的 174 份解答裡，72 份把原本的漏洞寫了回去。

這個分數其實領先榜單：先前最佳為 43.5%。但 Semgrep 自己提醒，新舊成績因提示與測試環境改動而不完全可比，公開漏洞也可能被模型背下來；Semgrep 同時銷售程式碼資安產品，解讀時應納入考量。可以確定的是，「測試全過」與「可以放心上線」之間仍有一大段距離。人類審查者也未必補得上，今年軟體工程研討會 MSR 收錄的研究發現，AI PR 的重複程式較多、重用較少，審查者的反應卻偏中性或正面。程式碼看起來乾淨，反而讓問題更難被察覺。

還有一些風險發生在審查之前，PR 根本還沒開。Manifold Security 9 月揭露的 GitSpawn 指出，代理在背景呼叫 git 蒐集資訊時，惡意專案的 git 設定可能讓程式以開發者身分執行，繞過沙箱與核准提示。這類攻擊需要對方連同 .git 目錄把專案交給你，例如壓縮檔或同步資料夾，一般 clone 不會觸發；該文列出涉及七款代理的八項問題，發表時四項未修補，目前狀態本刊未逐一複查。Accomplish 的研究者也在 9 月公布兩種 Codex 沙箱逃逸手法，OpenAI 在八天內修復。另一篇論文則在「代理本身有惡意」的假設下測試 Claude Code 的 Auto Mode 與 Codex 的 Guardian，79% 的試驗能以注入手法執行任意指令；這是刻意設計的對抗情境，不代表日常使用的出事機率。本刊在〈AI Agent 的安全盲點〉談過委託與授權的界線，開發現場的版本就是這些：把閘門全押在 PR 上，等於放著開發機這一段不管。

初階工程師的工作真的在消失嗎？

目前證據分歧，不宜下結論。史丹佛 Brynjolfsson 等人 8 月更新的〈Canaries in the Coal Mine?〉用 ADP 薪資資料發現，22 至 25 歲、高度暴露於 AI 的職業，就業比照同齡低暴露職業應有的水準低 19%，主要來自少聘，不是多裁。但作者強調沒有看到全面性的就業流失，這是描述性結果而非因果估計，而且差距在排除科技業與電腦職業後依然存在，所以不是工程師獨有的現象。

哈佛論文的結果相反：企業導入代理後，資淺與資深員工的就業都沒有顯著變化，也沒有測到資淺招聘下降。兩者可以並存，因為哈佛量的是 12 到 16 個月內單一公司的變化，看不到整個市場的外溢效果。官方調查也幫不上忙：史丹佛論文指出，美國 CPS 就業調查每月樣本裡，22 至 25 歲的軟體開發者只有 23 到 48 人。

本刊認為真正該擔心的是審查者的養成，而不是今天的職缺數。哈佛的資料顯示，82.8% 的審查發生在審查者自己寫過程式的儲存庫（存放專案程式碼的空間）；若隨機分派，只有 17.2%。資深工程師的程式也有 75.7% 由資深者審。換句話說，審查能力是靠親手碰過那份程式碼累積的。如果新人寫得少、只負責把代理的成果送出去，五年後能在關鍵系統簽名的人可能不夠。這是推論，尚無資料證實，但它的落後性正是風險所在：等數字出現時，培養期已經錯過了。

如何用「驗收帶寬五問」檢查團隊？

把產能問題改問成五個問題，比追 PR 數量有用。本刊整理如下，每一問都對應前面的證據，也都能用團隊現有工具量到。

第二問最容易被忽略，也最該列入管理報表。He 等人的建議與此一致：審查的覆蓋率與深度要和產出量一起設目標，並事先決定自動審查可以在沒有人類的情況下核准什麼。GitHub 自己的審查指南也把弱化 CI（自動測試流程）列為必須停下來處理的狀況，例如調低覆蓋率門檻、刪除或略過測試，這些正是綠燈失真的典型。

台灣的軟體團隊該從哪裡開始？

先把驗收寫進流程與合約，再談導入規模。必須先說明資料限制：Octoverse 全文沒有台灣數字，本刊也未找到台灣企業層級的審查時間資料，前述比例不能直接套用。

台灣能確定的只有招募面。104 獵才顧問 4 月的報告指出，軟體／工程類職務每月徵才 2.5 萬人，年減 5%；軟體及網路業人才缺口 6.3 萬人，低於過去 8 萬人的高峰，工作機會約三成為 AI 相關職務。這些數字沒有區分年資，也不能證明與程式代理有因果關係。

法規面反而有現成的抓手。今年 1 月修正的《資通安全管理法施行細則》第 7 條規定，公務機關與特定非公務機關委外開發客製化系統時，受託者要提供安全性檢測證明；屬核心系統或金額達新臺幣一千萬元以上者，委託機關須自行或委託第三方檢測；使用非自行開發的系統或資源，須標示來源並提供授權證明。

這一條在代理時代會出現新問題：代理產生的程式算不算「非自行開發」？本刊未見主管機關解釋。本刊建議接案公司與發包方不要等解釋，直接在契約裡約定是否使用代理、由誰審查、檢測證明涵蓋範圍。對委外與接案專案來說，「驗收」本來就是合約用語，把代理納入驗收條件並不需要新制度，只需要把既有條款寫細。

另外，歷史包袱重的系統不該照抄新創的數字。哈佛論文中，儲存庫數量最多的三分之一企業，導入代理後合併時間增加 69.7%，最少的三分之一只有 25.4%；He 等人的個案也發現增益集中在新儲存庫，舊儲存庫幾乎沒有。本刊推論，銀行、製造與政府的老系統更接近前者，但這仍待本地資料驗證。91APP 事件中攻擊者由 GitLab 取得資料庫金鑰，也提醒我們，程式碼平台本身就是高價值目標，代理權限不能只當成開發效率問題。

接下來最該看哪個數字？

最該看的是 AI 審查的生產力，它決定這波變化的規模。哈佛團隊用模型推算，代理目前讓寫程式的生產力提高 73.7%，審查生產力反而略降 7.0%，企業把人力從寫程式移往審查。往 2031 年推，若審查生產力不變，產出增加 57.8%、就業減少 10.3%；若審查與寫程式同步進步，產出增加 341.4%、就業減少 76.2%。作者明言後者是上限，而且模型未納入決定做什麼、測試與客戶溝通等其他瓶頸，這是情境推演，不是預測。

但方向很有意思：審查瓶頸一方面壓住產出，一方面也保護了工作。誰能把人類判斷安全地自動化，誰就同時掌握軟體產能的上限與工程師人數的變數。所以 Copilot 核准的開啟比率、下一版 Octoverse 會不會公布審查資料、METR 重新設計後的實驗，都比下一個模型的跑分更值得追。程式代理已經解決了「寫不夠快」，接下來的競爭在於誰敢為寫出來的東西簽名。

｜台灣科技週刊

資料與方法說明

本文根據廠商報告與官方文件、學術預印本、法規原文及媒體報導整理，未訪問報告作者或企業，也未實測任何程式代理或審查產品。

Chen & Stratton 論文為求職論文，資料由 Jellyfish 提供，8 月版與 11 月版的樣本與數字不同，本文一律採 11 月 1 日版；其長期數字是模型推算。He 等人為單一公司個案與預印本，公司未具名。Octoverse、Copilot、Claude Code Review、Codex、Bugbot 的功能與數字屬公司自述。LinearB、Semgrep、Manifold Security、Accomplish 都有自身商業利益，LinearB 報告未標明資料期間。OpenAI DevDay 官方回顧頁無法開啟，相關內容依 The Decoder 報導與 OpenAI 文件核對。GitSpawn 各項問題的目前修補狀態未複查。《資通安全管理法施行細則》條文取自臺北市法規查詢系統轉載全文，全國法規資料庫本次未能開啟。104 數字依工商時報報導，未見報告原文。

參考資料

1. GitHub，〈Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents〉，2026-10-28。
2. Fiona Chen、James Stratton，〈Artificial Intelligence in the Firm: Bottlenecks in Software Production〉，2026-11-01 版。
3. Hao He 等，〈AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise "2×" Mandate〉，2026-10-27 修訂。
4. LinearB，〈2026 Software Engineering Benchmarks Report〉，2026，查閱日 2026-11-05。
5. METR，〈We are Changing our Developer Productivity Experiment Design〉，2026-02-24。
6. GitHub Changelog，〈Copilot code review: Merge with confidence with Max and approvals〉，2026-10-28。
7. GitHub Docs，〈GitHub Copilot code review〉，查閱日 2026-11-05。
8. Jay Parikh，〈GitHub Universe 2026: Evolving every layer of the stack〉，2026-10-28。
9. Andrea Griffiths，〈Agent pull requests are everywhere. Here's how to review them.〉，2026-05-07。
10. Anthropic，〈Code Review〉，查閱日 2026-11-05。
11. Anthropic，〈Code Review costs and usage〉，查閱日 2026-11-05。
12. OpenAI，〈Code review〉，查閱日 2026-11-05。
13. Cursor，〈Bugbot〉，查閱日 2026-11-05。
14. The Decoder（Jonathan Kemper），〈OpenAI expands Codex and its API at DevDay with security scans, a Decisions API, and Ultrafast〉，2026-09-29。
15. Katie Paxton-Fear（Semgrep），〈Claude Opus 5.5 Writes Working Code but Only Half of It Is Secure〉，2026-09-29。
16. Haoming Huang 等，〈More Code, Less Reuse〉，2026-01-29。
17. Francisco Rosales（Manifold Security），〈GitSpawn: A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok〉，2026-09-01。
18. Oren Yomtov（Accomplish），〈Escaping the OpenAI Codex sandbox, twice〉，2026-09-15。
19. Alex Remedios 等，〈Red-Teaming Auto Mode〉，2026-09-27 修訂。
20. Erik Brynjolfsson、Bharat Chandar、Ruyu Chen，〈Canaries in the Coal Mine?〉，2026-08。
21. Stanford Digital Economy Lab，〈No Widespread Displacement, but the AI Employment Gap for Young Workers Has Widened to 19%〉，2026-08-12。
22. 工商時報（莊丙農），〈104：每月科技人才缺口達19.3萬 軟體業3成工作機會為AI職務〉，2026-04-28。
23. 數位發展部，〈資通安全管理法施行細則〉（臺北市法規查詢系統轉載），2026-01-05 修正。