AI 寫碼快 100 倍，為什麼生產力沒跟上？

AI News · 2026-04-18

原文連結： AI-Assisted Coding: Why a Distinguished Engineer Stopped Reading Code

摘要

• Claude Code 幾分鐘就能吐出大量程式碼，但真正的工作沒有因此等比例變快。
• 工程師現在最花時間的，反而是驗證 AI 產物、把問題回饋回去，以及補足團隊脈絡。
• 這篇文章把「寫 code」從瓶頸變成了前置條件，真正的成本轉移到判斷、溝通與上下文搬運。
• 作者認為實際生產力提升比較接近 2 到 3 倍，而不是外界常喊的 100 倍。
• 未來若想再往上拉，關鍵可能不是更會寫 code 的模型，而是更會抓組織脈絡的工具。

· · ·

Claude Code 可以在五分鐘內產出 2 萬行程式碼。光看輸出量，一位軟體工程師的生產力似乎理應提升 10 倍到 100 倍，但現實並不是這樣。原因在於，原本看得見的瓶頸，也就是「寫 code」，其實只是最容易被觀察到的一段。把它拿掉之後，其他更隱形的瓶頸就全冒出來了。

現在卡住工作的，變成了程式碼周邊的那些事，像是判斷什麼才是正確的、把需求講清楚，還有替 AI 補上它從未擁有的上下文。這三件事，正逐漸吃掉整個工作日。

1. 驗證 AI 產出的程式碼

最直接的反駁是，既然 AI 寫 code 這麼快，那就讓 AI 也一起驗證啊。問題是，生成和驗證本來就是兩種完全不同的能力。模型可以很有自信地產出看起來合理的程式碼，卻還是漏掉細節：商業邏輯錯了、一個 off-by-one、或是 UI 乍看正確，其實有微妙偏差。

所以最後還是得人類自己點過 UI、讀 diff、跑邊界案例，而且速度就是人類速度。管線雖然幾秒就出來了，但把它確認到能上線，還是得花原本差不多的時間。

2. 回饋給 AI

驗證完，就接著進入下一個瓶頸，回饋。只要發現哪裡不對，就得把問題用足夠清楚的方式再講回 AI，讓它修正，而且還不能引入新的問題。這變成一個反覆迴圈，檢查、解釋、等待、再檢查，而每一輪都受限於人類能把問題說多清楚，而不是受限於模型產碼有多快。

實際上，一個原本幾秒鐘就能寫出的功能，常常要來回十幾次，甚至幾十次，才真的做對。生成是即時的，對話不是。

3. 搬運組織脈絡

這其實是最被低估的瓶頸。在真實組織裡，很多「什麼才算正確」的答案根本不在程式碼庫裡，而是在會議、Slack 討論、現場口頭決策，或是某些只有老鳥才知道的默會知識裡。AI 沒有這些上下文，所以人類就變成了翻譯機，得手動把組織知識轉成 prompt。

作者把這件事叫做 context porting，成本很高。每個專案一開始，都得先寫一大段背景說明，這些內容如果是同事早就知道的資訊，AI 卻得從頭補課。AI 一旦理解問題，速度很快，但讓它理解問題本身，卻慢、手工、而且完全靠人類。

真正的公式

AI 並沒有消滅軟體工程裡最難的部分。它只是消滅了最容易看見的那一部分，把 code 打出來，然後把真正困難的東西完整留下：判斷、溝通、上下文。這些事情依然是人類速度，所以現在就成了主要成本。

所以，生產力有提升，但比較像 2 到 3 倍，而不是 100 倍。三個瓶頸裡，最有機會先被削薄的，是組織脈絡搬運。越來越多上下文擷取工具，正在讓會議紀錄、決策與內部知識更容易直接進到 AI 工作流裡。不過驗證和回饋就難多了，這需要 AI 變得更成熟，而現在還差得遠。只要這點還沒解掉，人還是整條流水線的限速器。也就是說，軟體工程師還是會被繼續聘用。

· · ·

速度真的變快了，但流程沒有一起變簡單

對開發者來說，這篇文章最有價值的地方，不是又一次宣告「AI 會取代工程師」，而是把工作流拆開來看。寫 code 只是其中最顯眼的一段，真正吃時間的是驗證、協作、與把組織知識轉成可執行的指令。

這也提醒了一件事，當模型能力繼續往前推時，最先被重寫的未必是 IDE，而是團隊如何定義需求、怎麼做 review、以及哪些資訊應該被系統化保存。能把這些周邊成本降下來的團隊，才會真正吃到 AI 的紅利。