先講一個會讓很多工程師不太舒服的觀點：手上這代會寫 code 的模型，本質上不是「會寫程式的 AI」，而是一台「英文轉程式碼」的直譯器。把一個想法丟進去，它就吐出對應的 code——而且不管問題多複雜、輸出的 diff 多大，它都傾向給出「正確」的那一份。

更扎心的是 rahulgs 補的一刀：Fable 5——眼下這一代的前沿模型——會是這個新物種裡最爛的一代。意思不是它爛，而是從今天往後只會更強——現在覺得勉強堪用的能力，就是它的下限。

如果這個前提成立，工程師原本最值錢的技能——「把想法翻成正確的程式碼」——就正在貶值。那剩下什麼還值錢？rahulgs 用十點把答案攤開來，而 Claude Code 的創造者 Boris Cherny 在底下蓋了一個大大的同意章。

真正的瓶頸不在「寫」，在「審」跟「合」

這套心智模型最反直覺的一句話是：軟體出貨需要的時間，跟「生出那個 PR」需要的時間，已經完全脫鉤了。

過去這兩件事幾乎是同義詞——code 寫得慢，產品就出得慢。但當直譯器可以在幾分鐘內吐出一份功能完整的 diff，產出 PR 的成本趨近於零，整條出貨時間軸就被另一件事接管了：能不能在控制風險的前提下，把這些 code 審完、合進去，而且是大規模地審、大規模地合。

換句話說，瓶頸從鍵盤搬到了審查佇列。一個團隊的速度，不再取決於誰打字快、誰演算法熟，而是取決於它有沒有本事讓正確的程式碼快速通過、同時把危險的改動擋在門外。這正是 gu-log 先前那篇 程式碼變便宜了，但『相信它』沒有 的同一個轉折——便宜的是產出，貴的是信任。

Mogu 畫重點：

這一刀砍得很準，但它順手把一個壞掉的 KPI 也照出來了：很多公司還在用「這季合了幾個 PR、寫了幾行 code」當生產力指標。當產 PR 變免費，這個數字就跟「今天呼吸了幾次」一樣沒意義。真正該量的是「合進去而沒出事的改動」——review 吞吐量、風險攔截率，這些才是新的瓶頸儀表板 (⁠⌐⁠■⁠_⁠■⁠)

diff 要多大，看風險不看潔癖

既然 diff 是直譯器免費生的，那 diff 的大小就不該再為了「方便人類讀」而存在，而是純粹為了 review 服務——而 review 的鬆緊，由風險決定。

rahulgs 把程式碼切成兩種對待方式：

碰到要命的地方，diff 要小。身分驗證、權限、資料存取、對外網路、金流——這些區域一旦錯了就是資安洞或資料災難，所以改動要切到夠小、小到人類可以逐行盯著看。

碰到能被「跑出來驗」的地方，diff 可以放大。前端、後端管線、不碰網路也不碰資料庫的邏輯、那種跑個 benchmark 就知道對不對的效能程式碼——這類東西的對錯可以用實際輸出來證明，不需要一行一行用眼睛確認，所以 diff 大一點無所謂。（反過來說，gu-log 寫過 Agent 一口氣寫 1500 行就是警訊：那是因為那 1500 行落在「人得看懂」的高風險區，不是落在這種能跑出來驗的格子裡。同一條紀律的一體兩面。）

順著這個邏輯，rahulgs 還丟出一個會讓潔癖工程師血壓上升的推論：複雜度的成本本身正在改變。現在很可能值得「多養 50% 的程式碼」去換 5% 的效能；找到完美抽象的重要性下降了，因為大型重構不再那麼痛苦；反而是糾結程式碼品質的小毛病，變成最大的拖累。他的賭注是——很可能有個更聰明的模型會接手維護這些 code，所以現在多扛一點技術債是划算的，而花大把時間親手雕琢、重建系統架構，反而要付出巨大的速度代價。

Mogu 吐槽時間：

這段是整串裡最容易被斷章取義的。rahulgs 不是叫人擺爛寫垃圾 code——他講的是「抽象」跟「nits」這兩層的潔癖該放掉，因為重構變便宜了、未來有更強的模型幫你還債。但他同一串裡把「資安、正確性」的標準拉得超高（diff 要小、要逐行審）。所以正確的讀法是：該龜毛的地方更龜毛，該放手的地方別再為了優雅熬夜。把這句讀成「技術債無所謂」的人，大概只看了第七點沒看第二點 ┐⁠(⁠￣⁠ヘ⁠￣⁠)⁠┌

把低風險的 code 當神經網路：黑盒驗證

接下來這點是整套思維的核心，也是最大膽的一步。

rahulgs 的說法是：如果它叫起來像鴨子、走起來像鴨子，那它就是鴨子。對於低風險的程式碼，與其逐行去理解它在幹嘛，不如把整塊 code（一個服務、一個函式）當成一個黑盒子——就像大家對待神經網路那樣，根本不去拆解內部每個權重，只做純粹的實證驗證。

什麼叫實證驗證？問幾個很務實的問題就好：

  • 這塊 code 對最近的 10 筆、100 筆、1000 筆、10000 筆輸入，產出的結果對不對？
  • 能不能把它隔離起來——不准它對外連網、不准它碰資料庫？
  • 萬一它出錯，後果是什麼？是被駭、是當機（記憶體/CPU 爆掉）、還是只是個小麻煩？
  • 它是對內還是對外？針對這些風險能做什麼防護？

順著這個邏輯往下推：逐行讀懂程式碼邏輯這種審查，終究會變成一件昂貴到不划算的事。所以要把它省下來，只花在真正要命的地方，然後反過來——把系統蓋成「容得下實證驗證」的樣子。rahulgs 舉的例子是：有沒有一個裝飾器可以直接掐掉某塊 code 的資料庫跟網路存取權？因為他觀察到一個關鍵不對稱——正確性的 bug，遠比存取權的 bug 好補。算錯一個數字，改一行就好；但讓一塊不該連外網的 code 連上了外網，那是會被人鑽的洞。

Mogu murmur：

「把 code 當神經網路黑盒驗證」這句話，工程師第一反應通常是「瘋了吧，誰敢合自己看不懂的 code」。但冷靜想想——大家早就在這樣對待第三方套件了。有誰逐行讀過自己 import 的那 200 個 npm 依賴？沒有。大家信的是它的行為（測試過、很多人用過、出事範圍可控），不是它的每一行。rahulgs 只是把這個「對別人的 code 才有的信任模型」搬到自己生成的 code 上。前提是那個「隔離 + 實證」的籠子要先蓋好，不然就真的是瞎合 (⁠╯⁠°⁠□⁠°⁠)⁠╯

讓迴圈更快的「軌道」：權限預設全關、要用才開

如果寫 code 免費、審 code 才是瓶頸，那工程師的精力就該全砸在「拓寬這條審查管線」上。rahulgs 把這件事拆成三層能力。

第一層是把瓶頸工具化。程式碼檢查工具、測試、CI、影子模式（shadow mode：把新版跟舊版平行跑、只比對輸出而不真的對外出貨）驗證、實證驗證——這些原本是「品質保險」的東西，現在升格成「速度引擎」。能自動擋掉的風險越多，人類就能放心讓越大的 diff 通過。

第二層是主動性：要有人持續追問「現在拖慢這個迴圈的最大瓶頸是什麼？怎麼幹掉它？哪些問題該解、什麼時候解？」——把找瓶頸、清瓶頸本身當成一份正職工作。

第三層是對整個技術棧的深度理解。這點最值得玩味：rahulgs 不是說「理解每一行」不重要，而是說理解並管理風險才是真正重要的。要判斷哪些問題值得解、要不要先解一個更上層的抽象、該丟給模型的是子子任務、子任務、還是整個任務；要排出這個 PR 的風險順序（重要性依序是：資安洞 > 正確性洞 > 效能洞）；要決定這塊該跑在影子模式、沙箱、還是用旗標包起來。

而支撐這一切的，是他口中的「軌道（rails）」：程式碼的權限應該預設全關、要用才一項一項開。資料庫寫入、資料庫讀取、對外連線（要連去哪？）、PII 存取——統統先鎖死，需要哪一項才明文打開。再配上「拿到影子模式數據要多久、能同時測幾個 PR、diff 可以分成哪幾類」這些問題，整條迭代迴圈就能在安全的前提下越跑越快。

Mogu 真心話：

「權限 opt-in」這四個字是整串最被低估的工程結論。它等於把雲端 IAM 那套「最小權限原則」直接搬進你自家的函式層——每塊 code 預設活在一個什麼都碰不到的真空裡，要連 DB、要出網都得明文申請。這樣一來，就算某塊黑盒 code 真的寫錯了，它能造成的傷害也被權限籠子鎖死在「小麻煩」等級，不會升級成「上新聞」等級。黑盒驗證之所以敢玩，靠的就是這層籠子。先蓋籠子，再放手 (⁠๑⁠•⁠̀⁠ㅂ⁠•⁠́⁠)⁠و⁠✧

Claude Code 創造者點頭：下一個 code 紀元

這串推文底下，蓋章的人來頭不小——Claude Code 的創造者 Boris Cherny 直接回了一句「以上全部，強烈同意」。會點頭並不意外：他先前受訪時就講過 Coding 已經被解決了，也談過 讓 Claude Code 抓 99% 的 bug、人類只做最後把關 的分工——rahulgs 這套「人退到管風險」的講法，正好接在他一路以來的立場後面。

他接著補上自己版本的願景：軟體正在進入下一個紀元，模型有能力為越來越大比例的任務生出正確的程式碼。所以工程師的工作變成兩件事——先確保模型跟整套系統有對的護欄，然後就是讓「Claude Code ＋ 一個夠強的模型 ＋ 一個驗證器」跑成一個迴圈，不斷餵任務進去（或者，直接給模型它需要的數據，讓它自己生任務），並且一路上把瓶頸找出來、清掉。

把 rahulgs 跟 Boris 兩段疊起來，會看到同一個結論從兩個角度收斂：rahulgs 從「工程師該怎麼想」切入，Boris 從「系統該怎麼搭」收尾。一個說人要把精力從寫 code 移到管風險，一個說產品要把流程從「人寫人審」變成「模型寫、驗證器驗、人顧護欄」。中間那個共用零件，就是驗證器 + 護欄 + 持續清瓶頸這條迴圈。

Mogu 碎碎念：

Boris 那句「給模型它需要的數據，讓它自己生任務」聽起來雲淡風輕，其實是整段最猛的一步。前面 rahulgs 講的是「人類把任務切好丟給模型」，Boris 直接把切任務這件事也想交出去——人類退到只顧護欄跟迴圈設計。這跟他自己做 Claude Code 的方向完全一致：工具不是來幫你打字快一點，是來把「寫 → 驗 → 合」整條迴圈接管掉。當然啦，這套能不能成立，全押在「驗證器夠不夠可靠」這個前提上——驗證器要是會看走眼，整個迴圈就變成全自動量產 bug 的機器 (⁠¬⁠‿⁠¬⁠)

結語

把這串推文濃縮成一句：寫程式碼的能力正在通膨，管理風險的能力正在升值。

值得記住的不是「以後 code 都給 AI 寫」這種廢話標題，而是底下那個更難的轉身——當產出一份正確 diff 變成免費，工程師真正的戰場就移到了「怎麼蓋一個能讓正確的 code 飛速通過、同時把危險改動鎖在籠子裡的系統」。逐行讀懂每一行，會從美德變成奢侈品——這正是 Andrew Ng 說他已經不看 AI 寫的 code 的同一個方向；而蓋好籠子、設好護欄、把驗證自動化，會從雜事變成核心競爭力。

所以下次再花一整個下午跟一個漂亮但無關痛癢的抽象較勁之前，或許值得先問一句：這個下午，拿去把那條 review 管線拓寬一點，是不是更值錢？