审查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生成代码的能力、速度和每日上限。他希望看到数据证明他的担忧是错误的。否则，他将继续保持怀疑。本文写于约一年前，部分术语可能已更新，但核心论点仍未过时。