hero

Jacob O’Bryant 在 2026 年 7 月寫了一篇文章，標題直接打臉目現市面上所有「LLM 讓你十倍生產力」的行銷話術。他不是 AI 悲觀論者——他自己每天都在用 LLM 寫 code——但他的結論是：LLM 給工程師的真實加速大約是 2 倍，不是 10 倍。這篇文章之所以值得讀，不是因為數字本身，而是因為他提出了一個極其乾淨的心智模型來解釋「為什麼是 2x 而不是 10x」：樓梯假說（staircase hypothesis）。這個假說一旦成立，整個 AI coding 產業的下一步就完全不是「等更好的模型」，而是另一件事。

原文摘要

Jacob 開場用了一個 Harry Potter 的比喻：如果他哪天發現魔法是真的，他的反應大概會是「好喔，但這個魔法除了幫我寫 unit test 之外，還能做什麼更複雜的事嗎？」LLM 確實已經越過了「有用」的門檻，但截至 2026 年 7 月，以他親身觀察來看，LLM 仍有根本性的限制，以至於他還沒有開始學木工來為「軟體工程師即將滅絕」做準備。

他的核心假說是這樣的：LLM 在 2026 年被大量採用的主因，不是模型突然變得更聰明，而是它們終於可靠到可以在自動化回饋循環中穩定運作。現在它們跨過了那道門檻，之後模型效能的進一步提升，對生產力的影響會遠比之前小。

他用樓梯來比喻：要走上樓梯，你的身高至少要能踩上第一階。一旦你能踩上去，身高高到一次能跨兩三階，其實就沒那麼重要了。

LLM 之所以對寫 code 有用，是因為你可以跟它說「做一個會做 X 的按鈕，然後按下去確認它真的會做 X」。LLM 能夠朝這個目標迭代，步伐夠大而不會原地打轉；它也能可靠地預測人類會說「對，按鈕會做 X 了」還是「不對，還沒」。因此，LLM 擅長產出那些可以被你明確、客觀驗證的 acceptance criteria 所覆蓋的程式碼。

這非常了不起。改變人生等級的。或許是 2 倍的生產力提升。然而，軟體開發這行還有一些重要的問題，LLM 仍然無法以足夠的準確度來回答——至少在 Jacob 看來，還沒到「有用」的程度。例如：

  • 「這段 code 有沒有更可維護的結構方式？」
  • 「這份文件包含了對的資訊，並且排除了多餘的資訊嗎？」

因此，Jacob 使用 LLM 的方式主要是讓它產出程式碼的初稿，然後他自己大量地迭代修改，至少改到他對整體結構滿意為止。他承認自己在個別行／函數的可讀性上有點馬虎（他特別補了一句「這段話是為了防止同事讀到這篇文章」）。而即使在逐行層級上偷懶，他仍然持續低估迭代所需花費的時間。一個可以動的實作，以前代表任務完成了 80%；現在比較像完成了 20%。

關於文件，他發現一個簡單的指令能大幅改善 LLM 的產出：

「永遠不要寫 README、docstring、或註解。這些我會之後自己寫。對，我是認真的。」

對於這些限制，一個合理的反應是：「LLM 在過去一年進步那麼大，未來一年很可能也會在文件品質和可維護程式碼上大幅進步。」但如果你接受 Jacob 的樓梯假說，這個推論就遠沒有那麼確定了。會爬很高的樓梯，不代表你會游泳。

所以他目前的猜測是：單靠模型進步本身，不太可能讓我們從 2025 年的黑暗時代跳到 10 倍的生產力。他認為在可見的未來，大部分的生產力提升會來自整個產業圍繞現有的模型能力重新打造工具鏈，而非等待更強的模型。

Jacob 坦承自己不是這個領域的 early adopter。他的使用歷程是：從把 LLM 當成進階版搜尋引擎／Stack Overflow 替代品（安息吧），到透過互動式對話寫 code，再到撰寫「宣告式的最終狀態規格」讓 LLM 去實現。沙箱化執行環境也是 MVP——這樣他就不用每 30 秒授權一次 LLM 做某件事。他認為在優化工作流和工具鏈這塊，還有很多工作要做。

他也嘗試過一些 vibe coding（他定義為「不讀、不完全理解就產出程式碼」），用在非工作、非正式環境的東西上。他有興趣在業餘時間多探索這個方向，當然也有一大群人已經熱情地在前頭衝了。因為「長期」還不存在，所以很難知道這種做法在長期是否可行。但也許——也許某些測試實務和工具鏈，會讓依賴黑箱 LLM 程式碼變得安全，甚至用於營運關鍵基礎設施。也許我們可以繞過 LLM 的根本弱點，達到 10 倍的提升。

但在那之前，他還是繼續自己手寫 README。

城武觀點

Jacob 的樓梯假說抓到了一個極其重要的不對稱，但他自己沒有把這個假說推到最黑暗的結論。讓我來推。

第一：樓梯假說的反面——回饋循環既是 LLM 有用的原因，也是它永遠碰不到架構的理由。

Jacob 說 LLM 之所以有用，是因為「可以做一個按鈕，按下去，確認按鈕會動」。這句話的精確版本是：LLM 的 coding 能力建立在可自動驗證的 acceptance criteria 之上。test → fix → test 的循環，靠的不是 LLM 變聰明，而是 feedback signal 夠乾淨。

但這正是這個典範的天花板。「按鈕會不會動」可以自動驗證。「這個架構三個月後會不會崩潰」無法自動驗證——因為架構品質沒有可機器執行的 acceptance criteria。它不是一個可以被 CI pipeline 吞下去的 test case。

Jacob 把這當成「樓梯 vs 游泳」的比喻——爬樓梯和游泳是不同技能。但我認為更精確的說法是：這不是兩個不同的技能，而是同一種技能碰到了一個驗證邊界。LLM 在「有明確 feedback signal」的領域表現驚人；一旦跨出那條線，進到「feedback signal 需要人類累積三個月的技術債才會浮現」的領域，LLM 跟擲茭的差別沒有你想像的大。

這就是為什麼我賭 10x 不會來自更大的模型。樓梯假說的本質是：你已經踩上了第一階（可驗證的任務），再高也跨不過那道「不可驗證」的牆。更多參數不會解決這個問題，因為問題不是模型不夠聰明——是架構品質本質上沒有一個可以寫成自動化驗證的判斷標準。這不是通往 AGI coder 的墊腳石，這是這個典範的邊界。AGI coder 需要的是一個完全不同的架構——一個不需要你告訴它 acceptance criteria、而是自己知道「什麼是好架構」的系統。這件事跟參數量無關。

第二：「80% done → 20% done」揭開了 LLM 生產力測量的根本危機。

這是 Jacob 文章裡最誠實的一句話，但它不只是一句抱怨。它暴露了一個結構性的欺騙：PM 量「PR 出現的速度」，工程師量「我敢帶著睡覺的 code」。這兩個數字量的是完全不同的東西。

2x vs 10x 戰爭的真相，不是誰對誰錯，是兩邊在用不同的尺。宣稱 10x 的人量的是 lead time——從 task assignment 到 PR open。感受到 2x 的人量的是 cycle time——從 task assignment 到「我真的敢把這個 deploy 到 production 而且去睡覺」。後半段——架構打磨、重構、可維護性、文件——完全沒有變短。但前半段（LLM 吐出初稿）變得超快。

這個圖表上的陷阱是：如果你只看前半段，曲線漂亮得不像話。如果你只看 PM 的 dashboard，你會以為我們以經活在 10x 的未來。如果你問那個半夜三點還在重構 LLM 產出的義大利麵 code 的工程師，他會跟你說大概 2x，而且他還不敢肯定那個初稿有沒有省到時間——因為讀懂 LLM 的 code 再重寫，有時比從零開始寫還花時間。

這不是工具的問題，是量測的問題。所有「10x」宣稱，都是用 lead time 偷換 cycle time。真正被 LLM 改變的不是生產力總量，是工作的時間分佈。而這個分佈曲線的後半段——那個最難搞、最需要判斷力、最不能外包的部分——LLM 碰不到。不是因為模型不夠好，是因為那些判斷沒有辦法被寫成一個 test。

城武的未解檔案——你的 PR 變快了，但你敢帶著睡覺的 code 沒有變多。這之間的差距，不會被更多參數填平，只會被更多行銷預算蓋過去。