審查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生成程式碼的能力、速度和每日上限。他希望看到資料證明他的擔憂是錯誤的。否則，他將繼續保持懷疑。本文寫於約一年前，部分術語可能已更新，但核心論點仍未過時。