AI改变了代码审查，从语法检查转向行为验证，预览成为关键。这导致并发基础设施挑战，需环境虚拟化来应对。
译自：Traditional Code Review Is Dead. What Comes Next?
作者：Arjun Iyer
我最近注意到我们工程团队中发生了一个悄然的变化，这让我对软件开发的未来有了更广泛的认识：代码审查已经发生了根本性的改变。
这始于一个拉取请求（PR）。一位工程师使用代理生成了整个更改，并与代理迭代以定义业务逻辑，但最终依赖代理来编写代码。这是一项大量的工作。代码语法完美。它遵循了我们的 linting 规则。它甚至包含了通过的单元测试。
人工评审员是一位高级工程师，他通常对架构模式和命名规范一丝不苟，却几乎立即批准了它。从 PR 打开到批准的时间不到两分钟。
当我询问批准的速度时，他们说他们检查了输出是否正确就继续了。他们不觉得有必要解析每一行语法，因为代码是由代理编写的。他们启动了部署预览，点击按钮，验证了状态变化，然后合并了它。
这说得通，但仍然让我感到惊讶。我意识到我正在目睹传统代码审查的悄然消逝。
代码审查的悄然消逝
几十年来，同行评审流程一直是软件工程中主要的质量关卡。人类阅读其他人编写的代码有两个关键目的：
- 它捕获了自动化测试遗漏的逻辑错误。
- 它在团队中维护了代码库的共享心智模型。
这个流程背后的假设是，代码是一种稀缺资源，生产缓慢。一个人类开发者一天可能编写 50 到 100 行有意义的代码。另一个人可以在保持高度认知专注的同时，合理地审查这个数量的代码。
但我们正在进入一个代码变得丰富且廉价的时代。事实上，实施编码代理的精确目标是以一种速度和数量生成代码，这种设计使得人类不可能跟上。
当工程师看到一大块由 AI 生成的代码时，本能是将语法检查卸载给机器。如果 linter 满意且测试通过，人类就会认为代码是有效的。严格的逐行检查便消失了。
问题：AI 信任与橡皮图章效应
这种转变导致了我所说的橡皮图章效应。我们看到代码获得了“lgtm”（在我看来不错）的批准，但实际上没有人阅读过。
这显著改变了风险状况。人为错误通常表现为语法错误或明显的逻辑漏洞。AI 错误则不同。大型语言模型（LLMs）经常“幻觉”出看似合理但功能不正确的代码。
传统的基于差异的审查工具对此力不从心。差异显示的是文本文件中发生了什么变化。它没有显示该变化的涌现行为。当人类编写代码时，差异是其意图的表示。当 AI 编写代码时，差异只是一大堆令牌，可能与提示对齐，也可能不。
我们正在从语法优先的文化转向结果优先的文化。问题不再是“你写得对不对？”，而是“它是否按照我们对代理的要求执行了？”
预览作为新的真相来源
在这个新世界里，工程师是逻辑架构师，他们将代码编写工作交给代理，最重要的产物不再是代码。它是预览。
如果我们不能依靠人类来阅读代码，我们就必须依靠人类来验证行为。但要验证行为，我们需要的不只是差异。我们需要一个目的地。代码必须部署到一个实时环境中，在那里可以进行操作。
尽管前端预览已成为标准，但关键的空白——也是更难解决的问题——是后端。
考虑一个由代理生成的支付处理微服务的更改。代码看起来可能语法正确。逻辑流似乎也正确。但当两个请求同时到达 API 时，它是否处理了竞态条件？新的数据库迁移是否会锁定关键表过长时间？
你无法在文本差异中看到这些问题。你甚至无法在单元测试模拟中看到它们。你只有当代码在一个实时、集成的环境中运行时才能看到它们。
后端预览环境允许真正的端到端验证。它允许评审员对真实的数据库实例执行真实的 API 调用。它将评审流程从被动的阅读练习转变为主动的验证会话。我们不仅仅是检查代码是否编译。我们是检查系统是否按预期运行。
随着 AI 代理编写更多代码，软件开发生命周期中的“审查”阶段必须演变为“验证”阶段。我们不是在审查食谱。我们是在品尝菜肴。
基础设施挑战：并发爆炸
然而，这种转向基于结果的验证带来了巨大的基础设施挑战，大多数平台工程团队尚未为此做好准备。
人类开发者通常是线性工作的。他们打开一个分支，编写代码，打开一个拉取请求，等待审查然后合并。他们可能会在两个任务之间切换上下文，但很少会更多。
AI 代理并行工作。一个负责修复 bug 的代理可能会启动 10 种不同的策略来解决它。它可以同时打开 10 个并行的拉取请求，每个都有不同的实现，并要求人类选择最佳的一个。
这造成了并发的爆炸式增长。
传统的 CI/CD 流水线是为线性人工工作流而构建的。它们假定并发构建的数量有限。如果你的 AI 代理打开 20 个并行会话来测试不同的假设，你将面临两个令人望而却步的问题：成本和争用。
首先，你不可能有 20 个全规模的预生产环境在昂贵的云实例上运行。想象一下为同一个 bug 修复的 20 种变体启动一个专用的 Kubernetes 集群和数据库。云成本将是天文数字。
其次，也许更糟糕的是共享资源的瓶颈。许多流水线依赖于一个单一的预生产环境或有限的测试槽位。为了避免数据冲突，这些系统将 PR 强制排队。
对于现有的人工工程团队来说，这些队列已经是令人沮丧的瓶颈。如果多个代理同时将 20 个 PR 倒入管道中，队列就会变成死锁。而将它们全部在共享基础设施上同时运行的替代方案会导致竞态条件和不稳定的测试。
通过环境虚拟化扩展开发
为了扩展代理驱动的开发，我们不能依赖为线性人类节奏而构建的基础设施。我们谈论的是潜在的数百个并发代理并行生成 PR，所有这些都需要通过预览进行验证。为每一个代理克隆整个技术栈不是一个可行的选择。
解决方案是在共享基础设施上复用这些环境。就像一台物理计算机可以托管多个虚拟机（VM）一样，一个 Kubernetes 集群可以复用数千个轻量级的、短暂的环境。
通过在应用层应用智能隔离技术，我们可以为每个代理的工作提供严格的分离，而无需复制底层基础设施。这使我们能够为每次更改启动一个专用的沙箱，确保代理可以并行工作并端到端地验证代码，而不会相互干扰或导致云成本暴增。
结论
我们审查变更的方式正在发生明显的转变。随着代理接管代码的编写，审查过程自然地从检查语法演变为验证行为。预览不再仅仅是一种便利。它是验证代理所产生工作的唯一可扩展方式。
在 Signadot，我们正在为这个未来而构建。我们提供编排层，使代理集群能够并行工作，在闭环中通过即时、经济高效的预览来端到端地生成和验证代码。
下一个时代的赢家不会是拥有最佳风格指南的团队，而是那些能够在不耗尽云预算或使 CI/CD 流水线停滞的情况下处理 AI 代理并行工作的团队。
在一个 AI 优先的世界里，阅读代码是一种我们再也负担不起的奢侈。验证是新标准。如果你无法预览它，你就无法发布它。
