审查AI代码并非一个站得住脚的论点（2025）

# 审查AI代码不是一个可行的论点 来源：https://www.softwaremaxims.com/blog/reviewing-ai-code 我对LLM在软件开发中的实用性持怀疑态度。这不是因为知识产权法律问题（即使它们问题很大），也不是因为生态和资源消耗的原因。甚至不是因为“它们都是垃圾”的原因。我对LLM编码助手的问题是，面对科学证据，我看不出它们如何能帮助某人更好或更快地编写代码。 而让我恼火的是，似乎没有一个LLM编码助手的支持者在捍卫他们的工具选择时，愿意正视这个问题和这些证据。更糟糕的是，每次他们反驳怀疑论者时，似乎都在给我们的论点火上浇油。那么，让我们来看看我究竟对什么问题有异议，实证科学研究如何支持这一观点，LLM编码助手的支持者如何证明这不是问题，以及他们现在实际上在反其道而行之。 *注：这篇文章写于将近一年前，因此你可能会发现一些词汇，比如“编码助手”，现在大多已被替换。遗憾的是，在当前用于编码的genAI词汇中，我找不到一个涵盖所有用例的术语。所以我保留了“编码助手”这个说法。* ## 实习生问题 我对LLM编码助手批评的核心根本问题，是它们出错的风险相对较高。出于各种原因，有些是LLM运作方式的结构性原因，有些更像我们与它们交互的界面所致，LLM编码助手会出错。可能是幻觉、拼写错误、干脆做了与要求任务无关的事、走向不同的路径，等等等等。 很多我聊过、尝试过LLM编码助手的人都解释说，他们感觉“就像一个实习生”。就像一个实习生，你不应该对他们期望太高，你应该预期他们做的每件事或多或少都会出错，他们完全不知道自己在做什么，但非常热情。我看他们没让我当过实习生。我绝对是不热情的那个。 而他们对这个问题的回答，这个你在网上随处可见的回答，很简单。你只需像对待团队里的实习生和初级开发人员一样对待他们。不，他们不是说把你做的一切都扔进垃圾桶然后忘掉。他们的意思是，你应该亲自审查所有代码。我的意思是，你才是那个更懂的人。而且不管怎样，你都要对代码负责。最重要的是，你本来就在审查进入代码库的所有代码，你不会让代码不经审查就进入，对吧？ ## 我们说的“审查”是什么意思 首先，我想在这里明确一点。文献和行业中有不同的实践被统称为“审查”。所以让我们明确一下。考虑到（不）信任和潜在错误的程度，我们不应该把那种在行业中最为普遍的“轻量级且高度分散的审查”作为专业开发人员监督LLM编码助手的标准。它们不是坏事，也不是没有效率，但文献中已表明它们主要用于分发变更知识和强制执行各种表面层次的规则。 对于AI编码助手，我们需要的是真正的“代码审查”。不是过去那种正式的、复杂的委员会式审查，花几个小时逐行仔细核对每一行。但仍然，我们希望它相当深入和完整。毕竟，这些是实习生，有时编写高度复杂的代码。如果我们做软件懂什么的话，那就是细节里藏着魔鬼。 ## 审查的局限性 在不深入探讨审查作为一种实践的哲学深度的前提下，这个想法中存在一个明显的问题。从我们已有的所有研究来看，我们通过实证学到了一些关于代码审查的东西。证据在合理范围内是相对可靠的。你会发现这些界限在这里是相关的。 1. 一次审查如果超过1小时就太长了。 2. 一次有效的审查，单次审查的代码量不能超过400行，且必须在1小时内完成。 实证研究表明，超过1小时的审查会迅速达到收益递减点*无论被审查的代码量有多大*。所以不仅仅是人们在1小时后找不到更多bug，因为他们已经彻底审查了大部分代码。不，这更与一个事实相关：在那种注意力水平下持续1小时后，人们开始感到疲劳、厌倦，只是需要休息一下。 值得注意的是，据我所知，完全没有关于1小时审查会话之间所需恢复时间的研究。所以我无法告诉你一个人多久能进行一次1小时的审查。但我们或许可以接受一个极端上限，比如每天几次。这可能远多于大多数人能做的，我大概会把平均值定为2次，但嗯。这个范围还算合理。 实证研究中发现的第二个限制是速度，即每小时代码行数（LOC/H）变化很大，主要取决于代码的上下文、被审查的代码类型、经验、知识以及其他你能想到的原因。但经常被指出的一点是，即使没有严格的截止值，400 LOC/H似乎是保证效率可接受的最大速度，因为实证数据中几乎没有在此速度之上的审查在发现和标记缺陷方面特别有效。 ## 这对LLM意味着什么 那么，如果我们将“解决LLM编码助手问题的办法是审查代码”这一主张，与科学研究中关于代码审查的实证证据结合起来，会得到什么？对于LLM编码助手每写的400行代码（在最好的情况下，对于难以审查的代码会更少），就需要一名专业的高级开发人员花费1小时来审查代码。而他每周只有10到40个这样的审查时段，中间恢复时间未知，但可能至少一两个小时。 而这还没有考虑到这些高度集中的时段可能需求量很大。会议、需要思考的代码、设计会议、事件等等。你最好希望你能占用所有这些时段。这意味着，在最佳情况下，使用LLM编码助手的开发人员每天最多能编写、审查并提交几千行代码到代码库。这是最佳情况，更现实的情况是每天少于1000行。 如果这听起来很高，请记住这包含所有内容：样板代码、测试、迁移、配置等。而且这是最佳情况，即大部分代码都是样板代码且易于审查。我有些基本的唯一测试文件就超过400行。所以这位开发人员的生产力不会真的很高。见鬼，如果真要说的话，这听起来像是LLM编码助手在帮助编写代码方面能达到的真正上限。 ## 但等等，情况更糟 这让“没关系，你只需照常审查所有东西”这个论点难以令人信服。毕竟，即使他们是对的，由于代码审查的局限性，它也不会真正提供加速或更高的生产力。除此之外，请记住，这些实证证据来自关于人类审查员如何发现人类编码员代码中缺陷的研究。我们没有证据表明人类审查LLM编码助手代码的效率与人类审查人类代码的效率相同。如果说有什么不同的话，我们有一些初步证据表明，审查LLM编码助手生成代码的人类*更有信心*他们找到了所有缺陷，而实际上发现的缺陷更少。 人类审查员与LLM编码助手配对产生的输出质量，低于人类审查员与人类编码员配对产生的输出质量。但前者中的审查员相信他们做得更好。因此，不仅“只是审查所有东西”的做法导致使用LLM编码助手的生产力收益受到很大限制，我们甚至没有确凿证据表明它*根本有效*，能解决LLM编码助手经常出错的问题。 请注意，我在这里从未谈论*修复缺陷*的成本。我只谈论专业开发人员在专业环境中能够审查代码以标记问题的能力。这甚至不涉及LLM编码助手引入的缺陷成本有多高。这关系到审查生成代码的成本。无论缺陷是什么，也无论有多少缺陷。即使LLM编码助手极其优秀，这些成本也会保持不变，生产力也会达到同样的限制。 ## 我是说，情况可能更糟 嗯。坏消息。情况确实更糟。LLM编码助手的支持者、全面将其作为专业工具一部分的开发者经常吹捧使用它们的一个好处是，他们可以输入并生成那些在职业生涯中最令人痛苦和棘手的代码。以下是一篇与本文同期写作的、著名的且引人注目的“反怀疑者”博客文章中的一段引文，谈到了LLM编码助手能产生什么。 > 另外：你将再也无需亲自编写的所有Bash代码，100%由它代劳。 我想在这里打断你一分钟，让你思考一下作者的意思。他的意思是，你不再需要自己编写shell脚本了。现在你可以让计算机，即LLM编码助手，来做这件折磨人的痛苦工作。不再需要失去理智，你可以让那些最容易出错、最难审查、最难理解你犯了一个致命错误而导致全局崩溃的代码，由机器来编写和处理。那种解析松散但语义过载的代码，一个标点符号的简单拼写错误可能完全无害，也可能literally让你删除整个电脑。那种代码。 好吧，你可以让那个随时随机出错的东西来写它。然后你只需审查它，再也不用亲自动手写了。我的意思是，这能出什么错呢？这可不是那种最难审查错误的代码，对吧？对吧？！我是说，也许他们根本没有解决“我们*能否*有效审查LLM编码助手的输出”这个问题。 但可以肯定的是，他们并没有把那些实际上最难有效审查的代码作为主要用途来吹捧。对吧？！是的，他们确实在这么做。这就是让我无法接受的地方。他们不仅不回应“你确定审查代码能解决问题吗？”或“但如果我们进行了所有这些审查，它真的更高效、更好吗？”这些论点。不，他们更进一步。他们把我们作为专业领域已知的、最难审查和最难以保证正确的代码，作为LLM编码助手的最佳应用场景。 ## 怎样才能让我冷静下来 好吧，我会冷静下来。当然，没有人回应我的论点，当然我一直在指出问题，当然我对那些用这些工具让生活更轻松的人大喊“狼来了”。很好，继续对着云喊叫吧，但有人怎样才能说服我呢？毕竟，我可能是错的，对吧？我的意思，如果我总是用科学来支持我的观点，我也应该有些想法知道什么能证明我错了，不是吗？ 是的。首先，我希望看到关于人类审查员发现LLM生成代码缺陷能力的实证研究。以及速度如何。我们每天能做多少。我们已经有了关于审查人类生成代码的实证研究，所以如果你想说服我我的论点错了，我们需要一套人类审查LLM的数据。我们已经有一些实验数据和实证数据，但数据集在规模和上下文上有限。更多的重复研究会有帮助。但请注意，到目前为止，科学数据表明人类在审查LLM方面*很差*（或者LLM很擅长避免被检测）。这与预期一致，LLM被训练来逃避检测。但也许这只是偶然。 其次，你可以尝试向我们展示审查LLM生成的内容与审查人类生成的内容有何不同。也许所有这些数据和实证证据在这里并不适用。也许LLM的差异性足够大，以至于这是一个性质不同的问题。这样的话，我反对LLM编码助手的论点就不攻自破了。再次注意，到目前为止，有初步且不断涌现的证据表明，审查LLM生成的内容确实不同。但这一点指出它比审查人类生成的内容更难，这会使我在这里提出的论点更加强有力。所以小心你寻求的知识。 ## 然而我依然愤怒 上面的论点并不是我成为AI怀疑论者的唯一原因，但它可能是我反对LLM编码助手最大的一个原因。主要是，了解了所有这些关于代码审查的信息后，我看不出我们作为专业开发人员，如何能通过这种界面和流程从LLM工具中获益。这违背了我们所知的关于生产高质量代码的一切。 但真正让我抓狂的并不是我们一直从供应商那里得到这些工具和流程，尽管有上述科学证据。不，让我抓狂和生气的是，被一些从未正视这个问题或我所提问题的人称为“疯子”。我还没见过一个AI支持者真正回应过这个问题，或者试图对此进行实证研究。 我习惯了这种行为。我在我们的领域里反复看到同样的事情发生在TDD、类型系统、分离测试和编码团队、CI/CD、DevOps等等上。在我们领域，轶事数据总是获胜，即使它违背了实证证据所展示的一切。但仍然。我希望我们的领域能停止放血疗法。让我们尝试就人体工程学和实证证据展开真正的讨论。如果你想说服我，请别再叫我疯子，或者带来“嘿，这次对我有用”的轶事信息。开始看看我们当初是如何获得所有这些关于代码审查的实证证据的，然后去做一些研究吧。拜托。让我们利用这个时刻，开始认真对待我们的专业工具。