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

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

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

问题已经存在

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

安全影响同样严峻。最近对80个精心策划的编码任务和100多个大型语言模型的分析发现，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是否会编写大部分代码。对于许多团队来说，它已经这样做了。问题是我们的基础设施是否能跟上。