審查AI代碼並非可行論點

作者Thomas Depierre是一位對LLM在軟件開發中的效用持懷疑態度的人。他並非因為知識產權、生態或資源消耗問題，也不是因為“它們都很糟糕”而質疑，而是基於科學證據：他看不出LLM編碼助手如何幫助開發者更好或更快地編寫代碼。

最讓他惱火的是，LLM編碼助手的支持者在辯護時似乎從未正面回應這一核心問題，反而經常在反駁懷疑論者時無意中強化了他的論點。因此，他決定剖析問題所在，展示實證科學研究的支持證據，並指出支持者如何適得其反。

Depierre將LLM編碼助手的根本問題歸結為它們出錯的風險較高，包括幻覺、錯別字、偏離任務等。許多人形容它們“像實習生”——不能期望過高，但充滿熱情。而支持者的典型回應是：只需像對待實習生一樣審查所有代碼即可，因為開發者本來就應對所有代碼負責，且代碼必須經過審查才能入庫。

但Depierre指出，“審查”一詞在實踐中含義多樣。對於LLM編碼助手，我們需要的是真正的“代碼審查”，而非輕量級的分佈式審查。後者雖有益處，但主要適用於知識分享和表面規則檢查。而LLM生成的代碼可能包含複雜問題，必須仔細檢查。

然而，實證研究揭示了審查的侷限性：審查時間超過1小時後效率急劇下降；有效審查的速度不能超過400行代碼/小時。這意味着，對於LLM編碼助手生成的每400行代碼，需要一名資深開發者花費1小時審查，而每週最多隻能進行10-40次這樣的審查（且需要恢復時間）。這還忽略了會議、設計等其他消耗注意力的活動。因此，一個使用LLM編碼助手的開發者，每天最多隻能寫、審、提交幾千行代碼（實際可能不到1000行），包括樣板代碼、測試、遷移等，效率並不高。

更糟糕的是，人類審查LLM生成代碼的效果可能不如審查人類寫的代碼。初步證據表明，審查LLM代碼的開發者更自信，但實際發現的缺陷更少，質量更低。因此，“只需審查”的做法不僅限制了生產力收益，而且是否能真正解決問題也缺乏可靠證據。

此外，Depierre批評了支持者將LLM編碼助手的主要用途定位為編寫“最痛苦”的代碼，例如Bash腳本。Bash代碼語法寬鬆、語義重載，極易出錯且難以審查。將這類代碼交給LLM生成，再指望審查捕捉所有錯誤，邏輯上自相矛盾。因為最難審查的代碼恰恰是最不該由LLM生成的部分。

最後，Depierre呼籲進行實證研究：人類審查LLM生成代碼的能力、速度和每日上限。他希望看到數據證明他的擔憂是錯誤的。否則，他將繼續保持懷疑。本文寫於約一年前，部分術語可能已更新，但核心論點仍未過時。