Code Review 將死于 2026 年

人類寫代碼死于 2025 年，Code Review 將死于 2026 年。

這是 Latent Space 上周發(fā)的一篇客座文章的核心觀點(diǎn)。

作者 Ankit Jain 是 Aviator 的創(chuàng)始人兼 CEO，專門做 AI 原生工程團(tuán)隊(duì)的基礎(chǔ)設(shè)施。

Latent Space 編輯在開頭就說：

我們不完全同意，但這件事「顯然就在眼前」。而 Simon Willison 上個(gè)月也已經(jīng)點(diǎn)名了 StrongDM 的「Dark Factory」模式，說的是同一件事。

01 審不過來了

先看個(gè)數(shù)據(jù)。

Faros.ai 對 10,000+ 開發(fā)者、1,255 個(gè)團(tuán)隊(duì)的調(diào)研發(fā)現(xiàn)：高 AI 采用率的團(tuán)隊(duì)完成了多 21% 的任務(wù)，合并了多 98% 的 PR，但 PR Review 時(shí)間增加了 91%。

產(chǎn)出暴漲，審查拖后腿。

其實(shí) Code Review 的歷史也沒多久，直到 2012-2014 年才在業(yè)界真正普及。在那之前，很多團(tuán)隊(duì)靠 feature flags 和 rollback 來兜底，也沒見天塌下來。

而現(xiàn)在，代碼量和 PR 體量同時(shí)指數(shù)級增長。人工 Review 在人類寫代碼的時(shí)代就已經(jīng)吃力了，AI 一天能寫出過去一周的量，根本跟不上。

02 Dark Factory

StrongDM 走得更激進(jìn)。它們的「Dark Factory」模式就兩條規(guī)則：

• 代碼不允許人寫

• 代碼不允許人審

全是 AI 寫的代碼，也沒有人類 Review 的環(huán)節(jié)。Simon Willison 專門把這事拿出來說了一嘴，意思是：這個(gè)方向已經(jīng)有人在跑了。

03 AI 也救不了

有人說，人審不過來，那讓 AI 來審唄。

Ankit 的看法是：AI Review 只是在拖延死亡。如果 AI 寫代碼、AI 審代碼，那中間那個(gè)好看的 Review 界面存在的意義是什么？

LLM 偏離指令是常事，讓它自己審自己，可靠性也存疑。AI Code Review 工具只是把瓶頸從「人審不過來」變成了「為什么還要審」。

問題的本質(zhì)在于：我們在錯誤的環(huán)節(jié)投入精力。

04 換個(gè)審法

Ankit 提出了一個(gè)范式轉(zhuǎn)變：把人類的檢查點(diǎn)從下游搬到上游。

過去我們問的是「這段代碼寫對了嗎？」

以后應(yīng)該問的是「我們在解決正確的問題嗎？」

具體來說，就是把 spec（規(guī)格說明）變成核心產(chǎn)物。代碼只是 spec 的副產(chǎn)品。人類審的是 spec、plan、約束條件和驗(yàn)收標(biāo)準(zhǔn)，代碼 diff 交給機(jī)器去看。

這個(gè)思路其實(shí)不新鮮，但當(dāng) AI 寫代碼成為常態(tài)時(shí)，它突然變得很緊迫。

05 五層信任

Ankit 設(shè)計(jì)了一個(gè)五層信任體系，層層設(shè)卡：

第一層：多方案競爭

別只派一個(gè) Agent 寫代碼。派三個(gè)，用不同方案實(shí)現(xiàn)同一個(gè)任務(wù)，然后根據(jù)驗(yàn)證結(jié)果選最優(yōu)解。選擇標(biāo)準(zhǔn)也可以自動化：哪個(gè)通過的測試最多、哪個(gè) diff 最小、哪個(gè)沒引入新依賴，排個(gè)序就行。

第二層：確定性護(hù)欄

測試、類型檢查、契約驗(yàn)證，提供客觀的「過 / 不過」信號。關(guān)鍵是，這些護(hù)欄要在代碼生成之前就定好：

• 編碼規(guī)范（自定義 linter）

• 組織級紅線（禁止硬編碼密鑰）

• 領(lǐng)域契約（框架特定要求）

• 驗(yàn)收標(biāo)準(zhǔn)（任務(wù)級要求）

第三層：人定驗(yàn)收標(biāo)準(zhǔn)

行為驅(qū)動開發(fā)（BDD）成為核心。用自然語言寫出期望行為，Agent 照著實(shí)現(xiàn)。

Ankit 稱：spec 不是額外的工作，spec 本身就是最核心的產(chǎn)出。

第四層：最小權(quán)限

給 Agent 設(shè)定精確的權(quán)限邊界。任務(wù)是「修復(fù) utils/dates.py 里的日期解析 bug」？那它的文件系統(tǒng)訪問權(quán)限就只限于這個(gè)文件和它的測試文件，別的碰都不能碰。

第五層：對抗性驗(yàn)證

寫代碼和驗(yàn)證代碼的 Agent 互相不知道對方的存在。一個(gè)寫，一個(gè)驗(yàn)，還有第三個(gè)專門搞破壞，針對邊界情況和失敗場景做攻擊測試。

06 瑞士奶酪

這五層堆在一起，形成了安全工程中經(jīng)典的「瑞士奶酪模型」。

一層都有洞，但多層疊加之后，洞不會對齊。沒有哪一道關(guān)卡能擋住所有問題，但五道關(guān)卡一起上，能穿透的東西就很少了。

07 好代碼變了

在 Agent 生成代碼的時(shí)代，「好代碼」的定義也在發(fā)生變化。

Agent 寫出來的代碼天然趨向標(biāo)準(zhǔn)化，因?yàn)樗鼈冏裱y(tǒng)一的模式和規(guī)范。當(dāng)代碼變成可預(yù)測、可替換的產(chǎn)物，代碼長什么樣已經(jīng)不重要了，能不能滿足需求才是關(guān)鍵。

Ankit 對未來的判斷是：「快速發(fā)布，全面監(jiān)控，更快回滾」，取代過去那種「慢慢審查，還是漏掉 bug，最后在生產(chǎn)環(huán)境里 debug」的老路子。

如果 Agent 能把代碼處理好，那代碼可不可讀，還重要嗎？

人類應(yīng)該在上游 outthink 機(jī)器，在決策真正發(fā)生的地方發(fā)揮作用，而不是在下游試圖 outread 它們。

來源 | AGI Hunt（ID：）

作者 | Ankit Jain ; 編輯 | 蝦餃

內(nèi)容僅代表作者獨(dú)立觀點(diǎn)，不代表早讀課立場