Code Review 不會消失，但「逐行讀碼」會越來越不值錢

重點：AI 時代 Code Review 不會消失，但「逐行讀碼」會越來越不值錢。重點移到結構審查、驗證閉環、組織瓶頸。

最近 AI 工程圈很熱：OpenClaw（連續更名，原本叫 Clawdbot，名字太像 Claude，聽說被 Anthropic 盯上才改名，先改為 Moltbot，現在又改為 OpenClaw）。

我想聊的不是工具評測，而是作者 Pete 在 The Pragmatic Engineer Podcast 的一場訪談。我看完影片後，把我覺得可能會影響軟體工程工作方式的幾個點抓出來。

先講結論

Code Review 不會消失，但「逐行讀碼」會越來越不值錢

不是完全不看，而是別把注意力浪費在 plumbing 那種「看了也沒太多價值」的程式碼。

重點會移到三件事：架構、邊界、驗證迴路。

註：plumbing 指的是「把系統各部件接起來、讓資料與呼叫能順利流動的管線式程式碼」，例如：重試、超時、序列化、驗證、mapping、授權、記錄、追蹤這類程式碼。

瓶頸多半不在「寫 code」

未來工程師的價值，可能會更偏向：你能不能把系統設計成「AI 容易做對、也能自己檢查」。

PR 的重心會變

看 diff、挑格式、抓 bug 這種事情，AI 非常適合。

人更該花力氣的是：把需求寫清楚、把 prompt 變成可重複使用的「規格」。理想情況下，PR 更像 Prompt Request，而不是 Pull Request。

AI 協作的關鍵不是提示詞，是 Close the Loop（驗證閉環）

你要讓它自己跑測試、自己除錯、自己迭代。做不到這件事，就很容易掉進「越修越亂」的地獄。

註：驗證閉環指的是把 AI 寫程式變成「產出 → 立即可重複驗證 → 根據結果修正 → 再驗證」的超高速迴圈。作法是：要求 agent 自動跑 lint / build / tests / 可執行檢查，必要時把核心功能做成 CLI 或測試入口，讓迴圈足夠快、足夠自動化，讓 AI 自己寫，變成「可控的工程」。

吃不到 AI 紅利，常常不是工具問題，是組織問題

分工切太細、流程太厚、交接太慢，工具買再貴也沒用。真正能吃到紅利的，通常是那種：高主動性 + 跨域 + 結果導向的人。

為什麼我覺得這會翻轉？

敏捷把交付拆小、讓團隊端到端，這 15~20 年大家都做過了。

但老實說，多數公司的開發真正慢的地方，不是工程師寫 code 不夠快，而是：

• 等 review
• 等 CI
• 等 QA
• 等上線窗口
• 等跨組協調

你會發現「人月神話」根本沒被打破，卡的一直是整條流程。

概念 1：他不是「不 Code Review」，而是「不逐行 Code Review」

Pete 有一句話我很有感：他在意的是 system architecture，不是 line-by-line code understanding。

因為很多程式碼本質上就是 plumbing：資料搬來搬去、轉格式、接 API、塞 DB。你逐行讀，真的只是在耗注意力。

但注意：他不是放飛。他還是花大量時間在做「結構」：模組化、外掛化、子系統邊界。

所以對他來說，品質的核心不再是「我把每行都看過」，而是：我有沒有一個可靠的驗證閉環。

概念 2：Close the Loop 才是 AI 寫程式的正確姿勢

很多人早期用 AI 寫 code 會失望很正常。看起來像樣，但就是會冒怪東西，越修越亂。

Pete 的意思是：你丟一次需求就期待「零錯誤」，那本來就是錯的期待。人寫 code 也不是一次就寫好，我們靠的是迭代：跑起來 → 修 → 再跑 → 再修。

差別只是：他把這件事變成「強制規格」：

• 會 compile / build / run
• 會跑 lint / tests
• 出錯會自己看 log、重現、修掉、再跑一次

做得到這個，AI 才會變成「越用越強」；做不到，就會變成「越修越爛」。

概念 3：要 Close the Loop，就會被迫把系統設計得像工程，而不是魔法

如果你希望 AI 自己驗證、自己修正，就會逼出三個工程要求：

• 可測試
• 可重現
• 可觀測

不然你根本不知道它做對還是做錯。

他甚至提到：為了讓迭代更快，會把 UI 驗證改成 CLI 驅動的核心邏輯，因為 GUI／瀏覽器互動太慢。

概念 4：大公司難吃到紅利，斷層在組織

他的批判很真實：

• 角色切太細
• 流程太冗長與繁瑣
• 缺少 high agency 的人

所以他才會說，公司可能只要留 30% 的人，就能做完原本的事。這句話很衝擊，但他的邏輯是：高能動性的人 + AI，生產力會被全面解放。

要落地，一定要變成工程規範，不然就是賭誰的人品好

如果要讓團隊真的吃到紅利，至少要把三件事真的落實成規則：

1. 權限邊界與可稽核

工具呼叫、寫檔、外部 API 呼叫要留紀錄；高風險動作要有人二次確認。

2. 品質門檻（Quality Gate 變成固定流程）

lint / build / test 不是選配。你可以不逐行讀程式碼，但不能不把關品質門檻。

3. 可維運：跨邊界路徑要可觀測

結構化日誌（含 correlation id）、指標、追蹤、回放。這原本就很重要，但做起來其實不容易。

當你要 Close the Loop，就會逼你做到這些事情。

一個我自己的實戰感受

我最近也遇過一次：Claude Code 解 bug 越解越糟（一開始用 Sonnet 真的慘烈，後來用 Opus 有好一點）。

後來我自己追程式碼，找到問題丟給它處理，並請它整理「解題思路」＋把整個流程變成可重複的 prompt instruction。

經過實測我才發現：不是 model 不行，而是一開始我沒有把「正確的解 bug 流程」設計給它用。

這種做法，會讓它下一次遇到類似問題時自己解決，非常高效。

一句話收尾

AI 時代工程師的核心競爭力，會從「寫程式」，轉向**「設計可驗證的系統與回饋迴路」。**