代碼審查假設存在作者

代碼審查的傳統依賴於一個基本假設：有一個對代碼有足夠理解的人類作者，能夠解釋並操作它。然而，隨着AI生成代碼的普及，這一假設正在迅速瓦解。

在傳統的工作流程中，當你詢問某段代碼為何以某種方式實現時，總能從作者那裏得到答案，無論是編碼時遇到的約束，還是與隊友的非正式討論。審查者發現作者遺漏的問題，但這一切始於作者腦中有一個關於變更的模型。現在，AI代理開發改變了失敗模式：系統可以在任何人類理解其變更內容之前，迭代自己的輸出並生成一個拉取請求形態的工件。

大量交付的代碼表面流暢，逐行看似合理，但背後沒有能解釋其選擇的人類。作者只是一個代理人。差異是真實的，測試通過了，拉取請求上有一個人類的名字，但這並不意味着背後的推理存在於那個人的腦海中。當你問為什麼時，答案有時只是：“那是我接受的輸出。”這是一種不同的作者身份。更糟糕的是，他們直接把問題輸入另一個模型，確保過程中沒有任何思考。

瓶頸

通常的抱怨是，一旦代碼生成變得廉價，審查就成了瓶頸。這是事實，但這是目前發生的最無趣的部分。更重要的問題是，這個瓶頸現在被要求做什麼。審查原本設計用來挑戰某人已經（某種程度上）理解的工作。現在我們卻將其用作理解應當首次出現的地方，這是一個更重的任務。

用另一個模型來輔助審查有所幫助，但僅限於一定程度。它可以捕捉風格問題、缺失的空檢查、顯而易見的安全隱患。這很有用，值得儘可能自動化。但在一個大型系統中，審查者的真正價值在於知道差異沒有説明的內容。例如，三個倉庫之外的服務依賴於這個重試行為；一個一年沒人打開的夜間作業讀取那個字段；這次遷移對新客户安全，但對老客户危險；代碼看起來冗餘是因為有人在一次事故後移除了明顯的抽象，而那個測試通過是因為測試夾具錯誤。

部分上下文可以被檢索，未來會更多。模型將讀取更多文件，並更深入地遍歷倉庫和日誌。這會使審查變得更好，但不會消除根本問題。最難的上下文通常根本不在代碼庫中，它存在於事故歷史、團隊邊界，以及從沒寫下來過的記憶中——為什麼明顯的解決方案在三年前被拒絕。模型可以檢索工件，但它不能對將它們聯繫起來的判斷負責。

代碼審查註定失敗嗎？

第一個適應方案可能簡單得令人尷尬。一個AI輔助的拉取請求，在提交它的人類能夠解釋意圖、它所觸及的不變量以及安全的證據之前，不算是準備好審查。生成那個解釋正是將所有權推回流程的方式；它產生的文檔幾乎不重要。如果作者無法解釋變更，拉取請求就沒有準備好，它仍然只是生成的輸出。

這並沒有解決整個問題。它沒有告訴你如何審查一個大型的代理生成的變更，或者如何分配所有權。我會懷疑任何這麼早就兜售完整替代品的人。但我相當確定一件事：我們今天實踐的拉取請求是一個前LLM時代的產物。它編碼了關於作者身份、所有權和理解的假設，這些假設在人類鍵入代碼時基本成立，但在模型生成時則不那麼可靠。我們保留了儀式，卻改變了它賴以存在的基礎，且沒有承認。

每個人都在致力於更快地用更多AI來審查AI生成的代碼。更難的問題是，當請求批准的人可能根本不理解底層代碼時，審查到底意味着什麼。