AI 正在编写代码，但您的基础设施是否能够跟上？

我们正在经历软件工程史上最奇怪的逆转之一。几十年来，目标是确定性；构建系统以相同的方式行事。现在，我们正在在这个基础上添加概率性 AI 代理，生成代码的速度和规模令人惊讶。老实说，我们的大部分基础设施并不是为此而设计的。

我花了多年时间从事 DevOps 工具、共同撰写研究报告和帮助工程团队达到最高性能。现在，我看到 AI 驱动的开发不仅仅是一个演变；它暴露了我们现有工作流程中的每一个缺陷。

问题已经存在

一项 2025 年 GitClear 研究 发现，几乎 7% 的提交现在包含由 AI 生成的代码。他们的 早期分析 中的 153 万行更改的代码显示，成本是“代码抖动”——代码在两周内被重写或删除——到 2024 年比 AI 之前的基准增加了一倍。

安全影响同样严峻。最近对 80 个编码任务的 分析 发现，AI 生成的代码引入了安全漏洞，占比为 45%。现实世界中的影响是什么？五分之一的 CISO 现在报告由 AI 生成的代码直接引起的重大事件。

速度的提高是真实的，但稳定性的成本也是如此。

放大效应

我学到的一个事情是，AI 放大一切。如果您有良好的实践，AI 会使其变得更好、更快。如果您的流程混乱，AI 也会加剧这种混乱。这与每年在 DORA 的 DevOps 报告中出现的模式一致：变量越少，结果越好。成功的团队在更少的操作系统、更少的编程语言和更少的做事方式上标准化。他们故意减少复杂性。

AI 代理遵循相同的模式。给他们一个一致的环境，在这个环境中，Python 在每个开发人员的机器上意味着相同的版本，在这个环境中，依赖项被锁定和跟踪，他们就会表现出色。强迫他们在 17 个不同的配置中导航，每个配置都有微妙的差异，你就会在环境怪癖上浪费代币，而不是解决实际问题。

决定论悖论

这产生了一个令人着迷的紧张关系。多年来，计算机科学以决定论为最终目标。现在，我们正在在为可预测性而设计的系统上运行概率性工作负载、AI 模型，它们从本质上来说无法保证相同的输出两次。

我的答案是：尽可能多地保持堆栈的确定性。如果您可以保持 80% 的基础设施在确定性水平上，您的 AI 代理就有更少的变量来管理。他们不会将上下文窗口花费在“为什么这个依赖项没有安装？”或“让我再试一次这个构建命令”上。他们专注于您要求他们做的实际工作。

想想看：当一个代理尝试编译某些内容时，native 绑定由于 ImageMagick 未安装而失败，这是一个代币昂贵的绕道。如果您的环境已经包含所需的一切（编译器、库、完整的依赖树，直到 libc），则代理只需工作即可。无需调试，无需试错，只需进展。

规范和验证至关重要

现在很明显，AI 驱动的开发迫使我们更努力地思考两个历史上被低估的技能：规范和验证。您需要阐明您实际上正在构建什么，并且需要强大的方法来验证您是否获得了它。

我注意到了一件有趣的事情：具有产品管理或产品工程背景的人往往更成功地使用 AI 代理。他们已经接受过以需求、成功标准和权衡为中心的思考方式的训练。他们习惯于询问“您为什么做出这个选择？”并根据推理进行调整。

验证，即判断事物是否实际正确，始终是软件工程中最困难的问题。QA 已经被低估了几十年，但这是最具挑战性的部分：判断软件是否解决了实际的用户需求。AI 并没有解决这个问题。如果有的话，它使其更加关键，因为现在您需要将概率性输出与确定性需求进行验证。

信任，但要验证（和控制）

我开始接受的一种观点是：我们应该假设由 AI 生成的代码是恶意的，直到被证明不是这样。这并不是因为 AI 是恶意的，而是因为我们根本不知道。我们无法审核每一行代码，因为代理每天生成数千行代码。

这意味着控制点的转变。如果我们无法在开发时间控制一切，我们需要在运行时有更强的控制。运营商、SRE、平台团队、谁负责生产，需要更好的可见性来了解正在运行的内容、完整的依赖项跟踪和每个工件的明确来源。

这是可复制性变得至关重要的地方。当您可以数学证明本地测试的工件与生产中运行的工件相同——相同的输入、相同的输出、相同的依赖项闭包——您可以开始做出明智的决定。也许您不需要在 CI 中再次运行单元测试，如果您已经在本地运行了测试且没有更改。也许您可以将测试覆盖率映射到代码更改并跳过不相关的测试套件。

接下来是什么

我们处于一个转折点。已经拥有良好实践的团队正在使用 AI 获得巨大的生产力提升。那些苦苦挣扎的团队现在挣扎得更快了。

支持 AI 驱动开发的基础设施需要从一开始就为可复制性而构建。不是事后通过扫描工具和审计来添加，而是从开发人员第一天开始工作的方式就将其融入其中。当您的开发环境在 Mac 和 Linux 上是相同的，当每个依赖项都被跟踪和锁定，当您对每个工件都有完整的来源时，AI 代理就成为倍增器，而不是混乱的产生者。

以下是我对试图在 AI 时代成功的团队的最大建议：

• 无情地标准化。变量越少，性能越高。锁定您的技术栈，在所有平台上强制执行一致的环境，并在 AI 放大之前消除配置漂移。如果 Python 版本不匹配现在会引起问题，那么当 AI 以规模生成代码时，它将引起 10 倍的问题。

• 将验证构建到您的工作流程中，而不是在最后。由于 AI 以人类无法审查的速度生成代码，因此您不能仅仅依赖手动代码审查。实施自动化测试，以验证代码不仅运行，还解决了实际需求。将您的 CI/CD 管道作为安全网，在生产部署时具有强大的运行时门槛。

• 将可复制性作为基础设施进行投资。将环境一致性视为一流基础设施问题。当您可以数学证明本地环境、CI 环境和生产环境是相同的时，您就消除了整个“在我的机器上可以正常运行”的问题类别。这一确定性基础是允许您在其上安全地叠加概率性 AI 工作负载的基础。

问题不是 AI 是否会编写我们的大部分代码。对于许多团队来说，它已经在这样做了。问题是我们的基础设施是否能够跟上。