代码审查假设存在作者

代码审查的传统依赖于一个基本假设：有一个对代码有足够理解的人类作者，能够解释并操作它。然而，随着AI生成代码的普及，这一假设正在迅速瓦解。

在传统的工作流程中，当你询问某段代码为何以某种方式实现时，总能从作者那里得到答案，无论是编码时遇到的约束，还是与队友的非正式讨论。审查者发现作者遗漏的问题，但这一切始于作者脑中有一个关于变更的模型。现在，AI代理开发改变了失败模式：系统可以在任何人类理解其变更内容之前，迭代自己的输出并生成一个拉取请求形态的工件。

大量交付的代码表面流畅，逐行看似合理，但背后没有能解释其选择的人类。作者只是一个代理人。差异是真实的，测试通过了，拉取请求上有一个人类的名字，但这并不意味着背后的推理存在于那个人的脑海中。当你问为什么时，答案有时只是：“那是我接受的输出。”这是一种不同的作者身份。更糟糕的是，他们直接把问题输入另一个模型，确保过程中没有任何思考。

瓶颈

通常的抱怨是，一旦代码生成变得廉价，审查就成了瓶颈。这是事实，但这是目前发生的最无趣的部分。更重要的问题是，这个瓶颈现在被要求做什么。审查原本设计用来挑战某人已经（某种程度上）理解的工作。现在我们却将其用作理解应当首次出现的地方，这是一个更重的任务。

用另一个模型来辅助审查有所帮助，但仅限于一定程度。它可以捕捉风格问题、缺失的空检查、显而易见的安全隐患。这很有用，值得尽可能自动化。但在一个大型系统中，审查者的真正价值在于知道差异没有说明的内容。例如，三个仓库之外的服务依赖于这个重试行为；一个一年没人打开的夜间作业读取那个字段；这次迁移对新客户安全，但对老客户危险；代码看起来冗余是因为有人在一次事故后移除了明显的抽象，而那个测试通过是因为测试夹具错误。

部分上下文可以被检索，未来会更多。模型将读取更多文件，并更深入地遍历仓库和日志。这会使审查变得更好，但不会消除根本问题。最难的上下文通常根本不在代码库中，它存在于事故历史、团队边界，以及从没写下来过的记忆中——为什么明显的解决方案在三年前被拒绝。模型可以检索工件，但它不能对将它们联系起来的判断负责。

代码审查注定失败吗？

第一个适应方案可能简单得令人尴尬。一个AI辅助的拉取请求，在提交它的人类能够解释意图、它所触及的不变量以及安全的证据之前，不算是准备好审查。生成那个解释正是将所有权推回流程的方式；它产生的文档几乎不重要。如果作者无法解释变更，拉取请求就没有准备好，它仍然只是生成的输出。

这并没有解决整个问题。它没有告诉你如何审查一个大型的代理生成的变更，或者如何分配所有权。我会怀疑任何这么早就兜售完整替代品的人。但我相当确定一件事：我们今天实践的拉取请求是一个前LLM时代的产物。它编码了关于作者身份、所有权和理解的假设，这些假设在人类键入代码时基本成立，但在模型生成时则不那么可靠。我们保留了仪式，却改变了它赖以存在的基础，且没有承认。

每个人都在致力于更快地用更多AI来审查AI生成的代码。更难的问题是，当请求批准的人可能根本不理解底层代码时，审查到底意味着什么。