FDE与企业家必看:AI开发加速数倍之后,会带来什么新的问题?

如果 AI 能让工程师编写代码的速度提高 5 到 10 倍，那么当代码正式发布后，所有依赖该代码运行的系统又会面临怎样的情况呢？

全文从这个问题展开

代码交付之后的所有工作，会发生什么变化？

内容概览

大多数企业对工程领域的 AI 提出了错误的问题：“我们能以多快的速度编写、测试和合并代码？”这种思路已经带来了令人瞩目的结果。在贝恩最近针对近 300 位技术与工程领导者开展的调查中，迄今 AI 带来的最大可衡量收益体现在速度和吞吐量上；高管们预计，未来一至两年内，提升幅度将接近 150%。

然而，更快发布的软件，仍然需要部署、监控、诊断和修复。而组织中负责运维的另一半——CIO 的运维团队，以及 CTO 的站点可靠性工程（SRE）和平台团队——则是为一个由人类按人类速度编写代码的世界而建立的。

调查揭示了这一缺口。高管们预计，AI 将在发布速度和工程成本效率上带来最显著的改善；而运维韧性的预期提升，在我们衡量的所有指标中最低（见图 1）。

图1：AI 带来的运维韧性改善，落后于其他所有受测软件工程指标

注：数值经四舍五入处理。｜来源：Bain Tech and Engineering Survey，2026 年 4 月（n=293）

我们将其称为“可靠性悖论”：AI 压低了构建软件的成本，却可能抬高运行软件的成本，除非运维也同步进行重新设计。当十倍的变更涌向一套为人工响应而设计的运行模式时，你得到的是一家速度更快、却更容易跌跟头的企业。如果只追求速度，就只是把组织的瓶颈从工程师的键盘转移到了值班呼叫器。

不过，正在脱颖而出的领先企业发现，速度与韧性并不矛盾；它们是同一套经过重新设计的系统所产生的两项成果。

产品与软件开发之间的传统界限正在消失。AI 让团队能够在同一个流程中完成定义、构建、测试和改进，而不再依靠依次交接。（参见贝恩简报“The Rise of the AI Development Life Cycle”：

https://www.bain.com/insights/the-rise-of-the-ai-development-life-cycle/。）

这一逻辑不会在部署环节止步。运行时的表现——哪里发生故障、哪里性能下降、用户经历了什么——是软件质量最清晰的信号。过去，这一信号的传递很慢：一份 PDF 复盘报告、一张工单、三个迭代周期后才补上的改造。现在，它必须跟产生这些信号的代码一样快地流动。

因此，AI 运维，也就是 AIOps——将 AI 应用于实时遥测数据，以检测、诊断和解决软件故障——并不是交给另一个团队、另拨一笔预算的独立项目。我们在开发中所说的“闭环”，放到运维中，就是能否从每次故障中学习，而不是为同一个问题救两次火。

企业把注意力放在哪里，已经让这一悖论显现出来。在被要求对最有可能提升工程生产率的举措排序时，领导者将可观测性和故障处理自动化——也就是 AIOps——排在了接近末尾的位置，只有约五分之一的人提及它（见图 2）。将 AI 应用于开发，即编程、测试和评审，则被近三分之二的高管列为最重要的举措。

图2：高管将 AI 运维列为对工程团队生产率贡献最小的因素之一

来源：Bain Tech and Engineering Survey，2026 年 4 月（n=293）

AIOps 应该从哪里起步？自主执行依赖上下文，而大多数企业还没有把这些上下文建立起来。智能体只能依据自己看得见的信息行动，因此有四件事必须先做好：

在典型的 IT 投资组合中，运维组织用于维持日常运转的基础设施、服务台、故障管理和安全运维支出，远高于新开发工作的预算。也正因为这些工作不够光鲜，运维组织至今也是受 AI 冲击最小的领域之一。这种情况即将改变。

采用 AIOps 的组织报告称，平均故障解决时间缩短了；通过更早发现问题和更好地分析告警趋势，重大故障减少了；通过自动调整资源配置规模和整合工具，基础设施成本也降低了。同样的能力还可以延伸到安全运维、成本优化、合规自动化和基础设施生命周期管理，每一项都对应运维预算中的一笔支出。不过，这些早期收益还不足以体现真正的价值：一个不再随着复杂度增加而同步扩张的运维组织。过去，系统更多、告警更多，就得有更多人来分诊；未来，系统将越来越多地自行诊断和自我修复。

Netflix 的数据平台团队将基于规则的错误分类器与机器学习相结合，预测失败的大数据作业在重试后能否成功，找出应采用的正确配置，并自动修复问题。Netflix 报告称，新系统无需人工介入，就能在线解决约 56% 的内存配置错误，同时将相关成本降低约 50%。这说明，运维组织可以不呼叫工程师，就自行消化掉一整类常见故障。

最终目标是零接触运维：在呼叫人工之前，智能体先在整个故障生命周期中完成观察、决策、行动和学习。我们调查中约半数组织预计，两年内，许多关键工程任务将由 AI 主导（见图 3）。

图3：约半数软件工程组织预计，未来一至两年内，大多数任务将由 AI 主导

来源：Bain Tech and Engineering Survey，2026 年 4 月（n=293）

如今，很少有企业接近这一状态。只有约 2% 将自己的工程组织称为“自主化优先”；大多数仍在试点或整合早期工作流（见图 4）。CIO 的职责，不是购买一个承诺能让企业登上曲线顶端的平台，而是建立能够逐步攀升的组织能力。

图4：如今，很少有组织的软件工程职能实现了完全自主运行

来源：Bain Tech and Engineering Survey，2026 年 4 月（n=293）

SRE 是过去二十年间运行模式最重要的创新之一。它将软件工程的规范方法引入可靠性管理：错误预算、服务级别目标，以及将严谨的工程方法应用于系统可用性。然而，智能体式 AI 改变了 SRE 的核心前提：具备专业技能的人类注意力是稀缺资源，需要尽可能高效地分配到不断扩张的系统中。当智能体能够摄取各个层面的遥测数据，根据依赖关系图推断根本原因，并且比人类值班人员更快、更一致地执行修复手册时，稀缺资源就变成了可信赖的自主执行能力。

这让工程师可以将精力从人工故障分诊，转向能够创造更大价值的工作。我们的调查显示，工程管理者已经将这一变化纳入考量。过去，可靠性工程师整夜在六种监控工具之间关联分析告警，这从来不是他们最有价值的工作。与开发端一样，他们现在正从操作执行者转向自主运维的架构师。他们的职责是：

围绕价值重新调整的，不只是 SRE。最成功的企业将采取从零开始的思路：如果今晚没有任何人值班，会有什么出问题？又在哪些地方，人类判断不可替代？这个问题会揭示出多数组织目前尚未配备的岗位：

自然语言界面让非专业人员也能排查系统，从而让规模更小的资深团队腾出精力，专注于治理和架构。

能够做好这些工作的 CTO，衡量 SRE 职能的标准，将不再是故障解决得有多快，而是能把需要人工介入的故障数量降到多低。

AI 主导开发的原则同样适用于 AI 主导运维，只是在运维中，要求更为严苛。

CIO 和 CTO 很容易将 AIOps 视为一项采购工作：选择平台，按现有运行模式部署，再将效率收益计入成果。这条路能带来大多数企业目前看到的渐进式改进，却无法化解这一悖论：开发的加速幅度，依然超过运维所能承受的范围。

将组织现有的 AI 工具串联起来，并不能解决问题；但解决问题也不需要彻底颠覆组织，或投入巨额预算。真正需要的是构建一套相互衔接的新流程与新能力：

一旦建成，这些能力就会成为自主工作的控制平面，应用范围远不止工程领域。

智变观察