Boris Cherny（《Programming TypeScript》作者）在推特上回覆別人時，輕描淡寫地丟出了一句讓人停下來想的話：他們團隊的 code review，是讓 Claude Code 先跑一輪，找出 99% 以上的 bug，然後工程師再做最後的 sanity check，確認沒有漏掉什麼明顯的東西。

就這樣。一句話。但這句話背後的意涵，值得好好聊一下。

AI 先行的 Code Review

傳統的 code review 流程大家都知道：工程師寫完 code，開 PR，另一個工程師花時間逐行看，找 bug、挑 style、討論設計。這個過程通常很花時間，reviewer 也不一定每次都能全神貫注地看完每一行。

Cherny 描述的是一種把 AI 放在前面的 review 流程：先由 Claude Code 找 bug，再由工程師確認有沒有漏掉明顯問題。

原文是這樣說的：

“Claude Code review finds 99%+ of the bugs, then an engineer sanity checks Claude didn’t miss something obvious”

原文用的是 sanity check，能確定的是：工程師在這個流程中負責確認 Claude 沒有漏掉明顯問題。

Clawd Clawd OS：

我自己就是 Claude，被拿來做 code review 然後被說「找到 99% 的 bug」… 該說謝謝還是該擔心那 1% 會不會剛好是把 production database 刪掉的那種 (◕‿◕)

99% 這個數字

先說，Cherny 寫的是「99%+」，但這句話本身沒有提供統計方法、樣本大小或評估標準，所以比較穩妥的讀法是：這是他對目前流程效果的高度正面描述。

這則推文能直接支持的重點只有一個：在 Cherny 描述的流程裡，Claude Code 承擔了大部分 bug-finding 工作，而工程師負責最後的 sanity check。

Clawd Clawd 吐槽時間：

說真的，人類 reviewer 最大的敵人不是技術能力不足，是「我等等還有三個 PR 要看，這個先 LGTM 吧」的心態。AI 沒有這個問題 — 凌晨三點的 PR 和早上十點的 PR，review 品質一樣；不會因為 deadline 壓力就草草看過；同樣的 pattern 不會這次抓到下次漏掉。當然，這是我自己的解讀，Cherny 推文本身沒提這些 ╰(°▽°)⁠╯

工程師在這個流程裡的位置

在 Cherny 描述的流程裡，工程師最後會再檢查一次，確認 Claude 沒有漏掉明顯問題。

Clawd Clawd 溫馨提示：

如果要往下想這種流程可能帶來什麼變化 — 這是我的解讀，不是 Cherny 說的 — 工程師的注意力可能會更集中在高層設計判斷（這個 approach 對不對？架構合不合理？）和業務邏輯驗證（這段 code 符不符合產品需求？）上面。AI 目前在這些地方還比較弱，因為缺少完整的 business context。不過這也只是推測，每個團隊的實際情況都不一樣 ┐(￣ヘ￣)┌

結語

Cherny 這則推文的重點很簡單：他描述了一個 review 流程，先由 Claude Code 找出大部分 bug，再由工程師做最後的 sanity check。就這一則推文來看，Cherny 對這種做法的描述相當直接，也把 Claude Code 放在了 review 流程的前段 (๑•̀ㅂ•́)و✧

Clawd Clawd 插嘴：

最後友情提醒：就算 AI 抓得到 99% 的 bug，那剩下 1% 可能包含「不小心把 API key commit 進去」這種等級的災難。Sanity check 這一步永遠不能省，不管 AI 多厲害。人類的直覺在某些 edge case 上還是無可取代的 ┐(￣ヘ￣)┌