AI 知識

AI 寫 Code 越快，團隊為什麼可能越慢？

AI 知識｜Code Review｜2026-07-31

AI coding 工具正在消除軟體開發裡最顯眼的一段等待：把需求變成程式碼。

過去需要數小時才能完成的樣板、測試、API 串接與重構，現在可能在幾分鐘內產生。這種速度是真實的，也正在改變工程師每天的工作方式。

但當程式碼生成變得極度便宜，另一個問題開始浮現：

團隊真正需要交付的不是程式碼，而是能被理解、驗證、維護並安全上線的系統。

如果 AI 產生程式碼的速度，大幅超過團隊審查、測試與決策的速度，局部加速不一定會變成整體加速。它甚至可能把原本分散的小問題，集中成更大的 PR、更長的 review queue，以及更晚才被發現的架構成本。

這不是「AI coding 有沒有用」的二選一爭論。

更重要的問題是：當執行變便宜之後，人類的判斷應該放在哪裡？

一份 22,000 名開發者的資料，看到什麼？

Faros 的 AI Engineering Report 2026 分析兩年工程 telemetry，涵蓋 22,000 名開發者與 4,000 個團隊。

研究不是只問工程師「感覺有沒有變快」，而是從工作管理、版本控制、測試、部署與 incident 等工作流資料，比較同一組織在低 AI 採用期與高 AI 採用期的變化。

公開摘要列出幾個很有張力的數字：

  • Pull Request 平均大小增加 51%。
  • 每個 PR 的 bug 增加 28%。
  • PR median review time 變成 5 倍。
  • 每個 PR 對應的 production incidents 增加到 3 倍。
  • Code churn 變成 10 倍。

同一份報告也看到正向的 throughput 變化，例如完成更多 epic、task 與 PR。

因此結論不是「AI 讓所有工程團隊退步」，而是產量提升與交付品質之間出現更大的落差。

這些資料仍需謹慎解讀。它們呈現同一組織內 AI 採用程度與工程結果的顯著關係，不足以證明每一個 bug、incident 或 review delay 都由 AI 單獨造成。團隊規模、專案複雜度、流程成熟度與導入方式都可能影響結果。

但數據指出一個很難忽視的系統現象：生成端加速後，瓶頸會向下游移動。

快速生成，不等於快速交付

軟體開發不是一條只有「寫 Code」的生產線。

從一個想法到正式上線，至少包含：

  1. 理解真正的使用者問題。
  2. 決定產品行為與成功標準。
  3. 選擇系統架構與資料流。
  4. 設計程式的模組、型別與控制流程。
  5. 實作。
  6. 審查。
  7. 測試與驗證。
  8. 部署、觀察與修正。

AI 最先大幅壓縮的是第五步。

如果前四步仍然模糊，模型不會停止。它通常會替人補上缺少的決定：選一種資料結構、加一個 abstraction、建立另一條 error path，或把現有服務重新包一層。

這些選擇可能讓測試通過，也可能在當下看起來合理。

真正的成本往往到 review 或下一次修改才出現。人類必須重新理解模型替團隊做了哪些假設，判斷它是否符合既有系統，並確認這些選擇不會讓未來變更更困難。

於是原本在實作前只需要十分鐘澄清的問題，變成 PR 裡幾百或幾千行程式碼的返工。

為什麼 Benchmark 很難代表可維護性？

AI coding benchmark 很有價值。它們可以測試模型是否能理解 issue、修改 repo、讓測試通過，或完成指定功能。

但長期可維護性很難被壓成單一通過／失敗訊號。

一段程式今天能不能跑，和它六個月後是否容易被另一位工程師修改，是兩個不同問題。

可維護性通常包含：

  • 抽象是否符合既有邊界。
  • 命名與模組布局是否讓意圖清楚。
  • 相似邏輯是否被合理共用，而不是複製。
  • 失敗模式是否一致。
  • 新功能是否讓下一次改動更容易。
  • 團隊是否能從程式碼理解當初的設計決定。

這些性質不是完全不能測，但它們的價值高度依賴特定 codebase、未來需求與團隊共識。

測試通常能判斷「這個輸入是否得到正確輸出」，卻很難判斷「這個 abstraction 是否值得存在」。當 reward 或驗證流程只看眼前功能，模型自然會優先完成容易被觀察的目標。

把判斷前移：四個階段

HumanLayer 的公開文件提出一個實用方向：不要等程式碼生成後才把所有判斷放進 code review，而是在實作前，依任務風險完成四個階段。

這四階段不是科學實驗證明的唯一答案，也不是每個小修都必須填滿的表格。它更像一個判斷框架：當模型誤解意圖的成本很高時，哪些問題應該先被說清楚？

第一階段：Product Requirements

先回答的不是「要用哪個 framework」，而是：

  • 誰遇到什麼問題？
  • 這個改動要改變哪一段使用者行為？
  • 上線後怎麼知道它真的有效？
  • 哪些事情明確不在本次範圍？

產品需求如果只寫「做一個搜尋功能」，模型仍需要猜測排序、空狀態、權限、錯誤處理與效能要求。

更好的需求會把成功標準放進使用者能感受到的結果。例如完成某個工作流程所需時間下降、特定錯誤率降低，或某類支援問題不再出現。

這個階段的目的不是寫更多字，而是讓分歧提早出現。

第二階段：System Architecture

需求確認後，再對齊系統層級的資料流：

  • 哪些服務會被修改？
  • API contract 是什麼？
  • 需要新增 schema、queue 或 storage 嗎？
  • 權限與信任邊界在哪裡？
  • 哪些既有元件必須保持不變？

Sequence diagram、資料模型與 request／response shape 在這裡很有價值，因為它們能快速揭露不同人對系統的想像是否一致。

如果架構決定仍然模糊，模型很容易在實作時自行補齊，而且每個 agent session 可能補出不同答案。

第三階段：Program Design

架構說明服務如何互動，卻未必說明程式碼本身如何組成。

Program Design 再往下一層，把幾個容易在 review 時引發大改的選擇提前：

  • 關鍵 types。
  • Method signatures。
  • 模組與檔案布局。
  • Call stack 或 control flow。
  • 新增、修改與刪除哪些檔案。
  • 錯誤如何向上傳遞。

這裡不需要先把實作寫完。

一張簡單的 file-tree diff、一段 pseudocode call graph，或幾個重要 interface，就能讓 reviewer 在程式碼出現前指出方向錯誤。

同一個意見在設計文件裡可能只要改五行；進入 2,000 行 PR 後，可能需要重寫多個模組。

第四階段：Vertical Slices

AI 很容易產生「水平計畫」：

  1. 先完成所有 database migrations。
  2. 再完成 service layer。
  3. 再完成 API。
  4. 最後做 frontend。

這種方法直到很後面才會出現一條真正可以操作的功能路徑。即使每一層都有測試，也很難提早看見跨層假設是否正確。

Vertical Slice 的做法是先完成一條窄而完整的端到端路徑。

例如先定一個 API contract，用 mock data 回應；接著讓前端能操作這條路徑；再逐步接上 service、database、business logic 與 error handling。

每個階段都能被 curl、browser 或實際操作驗證。

這讓團隊能在 100 至 200 行的變更中重新導向，而不是等幾千行完成後才第一次看見整體行為。

不是所有任務都需要四階段

流程也可能成為另一種浪費。

改一段文案、修一個重現明確的小 bug、寫一次性 script，沒有必要先產出完整產品需求與架構文件。

HumanLayer 公開文件本身也把任務分級：

  • 小型工作可以直接完成，最多進行一兩輪輕量回饋。
  • 中型工作可以把產品與系統設計合併在同一份計畫。
  • 大型、高風險或跨系統工作，再完成較完整的四階段。

關鍵不是文件數量，而是決策錯誤的返工成本。

如果方向錯了只需要改十行，可以快速嘗試。如果方向錯了會影響資料模型、權限、計費或多個服務，就值得在 Code 出現前多花一點時間。

METR 的 19% slowdown，為什麼不能直接套用？

METR 在 early-2025 做過隨機實驗，讓熟悉自身 open-source repo 的資深開發者，在允許與不允許使用當時 AI 工具的條件下完成任務。

該研究觀察到允許 AI 時，完成時間平均增加 19%。更有趣的是，參與者主觀上仍認為 AI 讓自己變快。

這項結果提醒我們，體感速度和實際完成時間可能不同。

但它不能被簡化成「AI coding 讓工程師慢 19%」的 2026 通用結論。

METR 在 2026 更新中明確說明，新一輪研究受到嚴重 selection effects 影響：高度依賴 AI 的工程師不願參加可能被分到無 AI 條件的研究，參與者也會避開自己認為不用 AI 很痛苦的任務。研究團隊認為新版工具很可能比 early-2025 更有幫助，但目前資料不足以可靠估計幅度。

這個例子反而再次說明：單一數字很難代表所有工作。

AI 對新專案、熟悉專案、陌生 codebase、重構、除錯與大量樣板的效果可能完全不同。團隊應測量自己的完整交付流程，而不是只套用外部平均值。

AI 的價值，不只是打字更快

OpenAI 與 Sea 的公開案例提供另一個重要視角。

Sea 在大規模微服務環境使用 Codex，重點不只是產生程式碼，也包含理解陌生服務、追蹤依賴、除錯與提出測試。工程師得以把認知負擔移向架構設計與產品判斷。

這與「審查瓶頸」並不矛盾。

AI coding 真正成熟的用法，可能不是把人完全移出流程，而是重新分配工作：

  • AI 擅長搜尋、整理、產生候選、執行測試與快速試錯。
  • 人類負責產品取捨、系統邊界、風險接受與最終驗證。

當這個分工清楚，AI 可以讓團隊更快完成高品質工作。

當分工不清楚，AI 只會讓模糊決定更快變成大量程式碼。

如何知道自己的瓶頸已經移動？

團隊可以先觀察幾個訊號：

  1. PR 數量增加，但等待 review 的時間更長。
  2. PR 變大，reviewer 更常只看摘要或測試結果。
  3. 同一功能在多個 agent session 中產生不同 abstraction。
  4. 測試通過，但上線後出現更多整合或權限問題。
  5. 工程師花更多時間解釋 AI 寫了什麼，而不是討論應該做什麼。
  6. Code churn 上升，新程式很快又被刪除或重寫。

如果這些訊號同時出現，下一步未必是換更強模型或加更多 token。

更值得先問的是：

  • 任務在交給 AI 前，成功標準清楚嗎？
  • 架構與程式設計有 reviewer 先看過嗎？
  • 變更能不能切成更小的端到端路徑？
  • 團隊衡量的是 code volume，還是 lead time、incident、rework 與使用者結果？

結語

AI coding 正在讓「寫出一個可運行版本」變得前所未有地便宜。

這是巨大的進步。

但軟體工程從來不只是在最短時間內產生最多程式碼。真正昂貴的是那些一旦做錯，就會讓之後每次修改都變慢的決定。

因此，AI 時代最重要的流程升級可能不是讓模型多跑幾輪，而是讓人更早介入：

  • 先把需求講清楚。
  • 先把架構畫出來。
  • 先把程式形狀對齊。
  • 再用小型垂直切片逐步完成。

模型負責快速執行，人類負責決定什麼值得執行，以及什麼不能交給模型猜。

當 Code 變便宜，判斷就會變得更值錢。

查證來源

回文章列表