在对人工智能的兴奋之余，我们又回到了老习惯，这应该促使我们重新调整方法。
译自 AI Won’t Fix Your Software Delivery Problems，作者 Steve Fenton。
事情很复杂。虽然业界面临着关于知识产权和AI环境影响的关键性辩论，但还有一个更根本的问题：我们如何利用这些工具交付高质量的工作，从而使我们的组织及其服务的社区受益？
本文不涉及伦理或道德问题，而是关注领导者们日益增长的压力，他们希望引入AI工具来提高生产力。
我们可以参考2024年《DevOps现状加速报告》来指导我们。在报告中，研究团队深入研究了AI的使用，以获得其采用率和影响的基线数据。我们将利用这些见解来解释我们是如何重蹈覆辙的，这应该促使我们重新调整方法，找到更有影响力的前进道路。
大多数组织都在增加AI的采用率。超过80%的组织热衷于以某种形式添加AI，其中代码辅助、信息摘要和文档是最受欢迎的机会。
代码辅助非常适合编写代码、理解现有代码和优化代码等任务。代码编辑器长期以来一直利用算法重构、机器学习和AI辅助，因此出于编码目的而采用AI是现有用例的自然演变。
各种形式的代码辅助最受关注。
使用AI分析信息和数据还不够成熟，尽管它在无处不在的TL;DR（太长，没读）摘要中已有先例，这些摘要由热心的人们添加到他们长篇写作的开头。
大多数受访者（超过70%）报告说，使用AI后生产力有所提高。人们觉得在AI的帮助下，他们可以更快地完成工作。我对开发人员生产力的长期问题是，它通常不是一个有用的衡量指标。
您可以评估个人生产力，因为它是一种感觉，而不是一个数字。处理繁琐的工作或不断被打扰时，您不会感到有生产力。当您获得充足的时间来完成一项任务时，您会感觉很棒。如果一个组织对这种生产力感兴趣，它应该检查员工满意度，因为人们在能够完成工作时往往更满意。
《DevOps现状》报告证实了这个问题，因为对AI驱动生产力的高评价并没有减少繁琐的工作或改善软件交付性能，而我们长期以来一直认为这是开发团队为实现组织目标做出贡献的可靠方式。
AI采用率提高25%会适度提高流程、满意度和生产力。它还会减少倦怠。但是，它还没有显著减少繁琐的工作，也没有让更多的时间花在有价值的工作上。
AI采用率提高25%的同时，也损害了软件交付性能。
AI使吞吐量降低了1.5%，稳定性降低了7.2%。如果对代码质量的感知随着AI辅助而提高，但稳定性却下降，这表明我们认为它完成任务的程度与它实际完成的程度之间存在不匹配。
鉴于人们非常关注提高编码速度，我们很可能看到大规模的次优优化。编写代码很少是功能开发的瓶颈。如果您没有通过自动化测试来捕获它引入的错误，那么加快代码本身的速度就不那么有价值了。它也没有解决更广泛的软件交付系统问题，也无法保证您的功能对用户有用。
如果您没有在约束处工作，您的优化就不会提高吞吐量。在许多情况下，偏离约束的优化会损害端到端系统。除非您已经平滑了后续所有工作的流程，否则加快编码任务不会带来任何好的结果。
那么，我们如何才能很好地利用所有这些新工具呢？
对AI的急切采用让我们回到了一个令人困扰的旧模式：在理解它将解决什么问题之前就购买解决方案。这意味着事后寻找问题，往往徒劳无功。
更成功的AI采用方法是从你的问题入手，确定哪个问题阻碍你最大，然后寻找解决方法。这样会让你所有可能的解决方案都处于开放状态。
从待解决的问题入手意味着你可以选择最有效的解决方案。你可以消除不必要的工作，或者找到一种方法使用你工具链中已有的部分来自动化它。如果你需要引入新的工具，你可以从所有可用的选项中进行选择，无论它们是否使用AI。
如果解决方案最终是基于AI的，我敢打赌，如果问题引导你找到AI解决方案，而不是反过来，它会更成功。