释放高效开发者价值：AI 投资策略

我们很高兴你的到来。每周一至周五，你都将收到 TNS 的精选内容，及时掌握最新动态，始终保持最佳状态。

请查看收件箱中的确认邮件，你可以在其中调整偏好设置，甚至加入更多群组。

在你喜欢的社交媒体平台上关注 TNS。

在 LinkedIn 上关注 TNS。

等待第一期 TNS newsletter 期间，不妨先看看最新的精选文章和热门内容。

每当我与企业领导者坐下来交流，问他们为什么要投资 AI，得到的答案几乎总是：为了速度。这个答案听起来合情合理，但只有当你知道究竟是什么拖慢了进度时，“速度”才有实际意义。

大多数领导者被追问时，都无法准确回答这个问题。他们隐约觉得交付速度太慢，清楚地知道自己最优秀的工程师正在被竞争对手挖走，同时董事会还希望看到创新提速。于是，他们购买 coding assistance 工具，因为这类工具最直观；只要开发者感觉自己工作得更快了，他们就将其视为战略奏效的证明。

但制定 AI 战略的首要任务，是找出真正限制吞吐量的瓶颈。

编码更快 ≠ 交付更快

在一个典型项目中，开发者大约只有 21% 的时间用于编写代码。其余时间则花在会议、测试、调试、设计、安全审查上，还有大量时间是在等待环境、构建和评审。

现在想想，AI 投资都流向了哪里。几乎所有投资都瞄准了这 21%。每场演示都在展示代码生成，成功指标也聚焦于 AI 生成了多少行代码。

“在一个典型项目中，开发者大约只有 21% 的时间用于编写代码。即使 AI 能让编码环节提速十倍，你优化的仍然不到整个系统的四分之一。”

即使 AI 能让编码环节提速十倍，你优化的仍然不到整个系统的四分之一。剩下的 79% 会限制收益。当前研究发现，如果单独使用 AI coding 工具，其实际能够达到的吞吐量提升上限只有 5% 到 10%。

这算是小幅进步，但远远称不上董事会期待的那种变革。

吞吐量真正藏在哪里

如果编码只占工作的 21%，那么系统与团队之间的协调就占据了其余工作的绝大部分，而真正的吞吐量提升空间恰恰藏在这里。AI 更值得关注的价值，是减少软件开发生命周期各个环节中的摩擦。

将一页纸的业务需求转化为技术规格草案，其中包括验收标准、Epic 和任务拆分。

帮助开发者、测试人员和安全工程师理解并探索庞大而陌生的代码库。

生成单元测试、识别覆盖率缺口，并制作逼真的测试数据。

对 merge request 进行第一轮检查，标记显而易见的问题，让人工评审者可以直接从真正值得讨论的问题入手。

根据 commit 历史起草 release notes。在凌晨 4 点发生生产事故后，趁值班工程师还没喝完咖啡，就先整理出事故摘要。

团队已经依赖的确定性工作流，例如 CI/CD pipeline、golden path 和自动审批，恰恰是让 AI 能够参与其中而又不至于把事情搞砸的基础。

那些出人意料的赢家

在过去一年的交流中，我发现，从 AI 中获得最多可衡量价值的组织，反而是银行、电信公司和国防承包商这类规模庞大、行动缓慢的传统企业。

这个结果与人们对拥有遗留系统、沉重监管负担和风险规避文化的组织的预期恰恰相反。然而，一家同时受 FCA、PRA 和英格兰银行监管的英国综合性银行，已经向超过 18,000 名用户推出了支持 AI 的 DevSecOps platform，为超过 4,800 万客户提供服务，开发者满意度超过 80%。该银行的 CIO 曾公开表示，他们正利用这一平台重构遗留代码、生成测试并检测漏洞。

不只是银行如此。某家全球领先的电信与网络设备企业，其 OSS/BSS 团队曾深陷以年为单位计算的升级周期。在将 AI 引入成熟的 CI/CD pipeline 后，他们在六个月内节省了 130,000 个小时，将部署时间缩短了 50%，并把测试场景数量提升到了原来的十倍。

这类组织之所以能胜过其他公司，可以归结为两个特点：

他们早已掌握了如何进行严谨的工程实践。成熟的 CI/CD、自动化测试，以及根深蒂固的“信任但要验证”文化，意味着 AI 生成的代码会进入一套专门用于在错误演变成事故前将其捕获的 pipeline。没有工程师会把 AI 的输出当作绝对权威。

他们早已掌握了如何治理概率系统。过去近二十年里，银行一直在运行信用模型、欺诈模型和市场风险模型。对他们而言，“该如何治理一个会作出具有真实后果的概率性决策的系统？”并不是一个新问题。

这些配套体系没有一个是为 AI 而建设的。它们最初是为了满足监管合规和运营可靠性的要求。但事实证明，它们恰好也非常适合 AI。

DORA 最近关于 AI 在软件开发生命周期中应用的研究得出结论：AI 不会创造成熟度，只会放大你已经具备的成熟度。

“AI 不会创造成熟度，只会放大你已经具备的成熟度。”

这正是 Barclays 和 Ericsson 所展示的。他们并不是因为投资了 AI，才变得擅长运用 AI。他们之所以擅长运用 AI，是因为他们原本就在测试、评审、治理和变更控制这些基本功上做得很好。

反过来也一样。如果你的平台能力薄弱，依赖手动部署，测试不足，评审随意，又缺乏治理，那么 AI 只会帮你更快地产生技术债。

眼下，这种情况正在开源世界中上演：一些大型项目的维护者开始公开要求贡献者停止提交由 AI 生成的 merge request。人们很容易把问题归咎于“AI 垃圾内容”，但真正的问题在于，这些项目缺乏相应的文档、贡献者指南，也没有足够的志愿评审者来消化如此庞大的提交量。企业团队很快也会撞上同一堵墙。

所以，那些因为讲不出时髦 AI 故事而被你一再推迟的枯燥基础设施投资呢？如今，决定你的 AI 战略最终成功还是失败的，恰恰就是这些投资。

所谓的 10x developer 从来都只是一个神话。但 10x organization 确实已经触手可及：在这样的组织中，每位工程师都能从一个能够捕获错误、减少摩擦并让 AI 安全参与的平台中受益。