忘记人在循环内，把人放在循环之上

我们很高兴你在这里。你可以期待所有最好的 TNS 内容在周一到周五送达，让你了解最新新闻，保持专业水准。

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

在你最喜欢的社交媒体网络上关注 TNS。

在 LinkedIn 上成为 TNS 的关注者。

在等待你的第一份 TNS 新闻通讯期间，查看最新的推荐和热门故事。

问题的本质：从"在"循环中到"掌管"循环上

AI 让我们快速忘记了人类在软件交付循环中的角色。现在，忘记人工"在"循环中的概念。对于 Thoughtworks 的杰出工程师 Kief Morris 来说，我们需要更加关注"掌管"循环的人类，以继续定义什么是好代码以及什么是好系统。

"如果你使用 AI 构建软件，你需要确保你构建的是生产就绪的软件，而我认为人们现在采取的默认方法不包括"这些工程最佳实践，Morris 在上个月伦敦 PlatformCon 期间对 The New Stack 表示。

"即使你不给代理完全的自由行动权，你也必须将其构建到你的流程中[并]你必须思考如何以安全的方式使用代理来帮助你做到这一点，这不能等待；这不是什么未来的幻想，"Morris 说。"这是你现在必须做的事情。"

在 AI 的速度下，组织必须将注意力从部署速度转移出来，而更多地关注确保你部署的内容安全、可信和高质量的护栏。幸运的是，这个解决方案回到了已被接受超过十年的软件交付最佳实践。但前提是你的 CI/CD 管道是生产就绪的。

什么是"好"？

许多人现在心中的问题是如何从他们的 AI 代理中获得更多收益，但正如 Morris 在伦敦 PlatformCon 探索这个想法时所指出的，我们需要退一步，不要只关注代理在做什么，先问这些问题："这对我们意味着什么？我们如何保持控制？"

Morris 担心我们已经将太多的代码构建工作委托给了 AI 代理，以至于我们与他们正在构建的细节疏远了，这使我们失去了确保 AI 构建事物质量的追踪。

"这意味着我们需要更好地定义什么是'好'，而我认为我们在这方面做得还不够好。"

"这意味着我们需要更好地定义什么是'好'，而我认为我们在这方面做得还不够好，"Morris 在他的演讲中说。当他思考如何定义这一点时——它对每个团队和每个公司的要求都会有所不同——他一直在"最大化"或将代理推向极限，进入一个端到端的、无需人工干预的 AI 代理工作流程。

为了实现这一点，他认为在 AI 代理工作流程中使用持续交付管道有助于构建更好的软件。我们也应该对代理采取 CI/CD 的方法。

"使用 DevOps 进行持续交付的理念是，当你在生产中发现错误时，你不仅仅是在生产中修复代码；你在源代码中修复它，[并]你弄清楚它们是如何通过我的管道的，我需要改变什么——我的测试？——以及无论需要什么来避免这类错误再次溜过，"Morris 继续说。

"当我与代理一起工作时，这是非常相似的。如果一个代理没有产生我想要的东西，我不是只是纠正它，因为下一次我使用代理修改我的代码时，它可能会撤销它。"

然后下一步是弄清楚你可以采取什么措施，这样你甚至不需要查看代码。由于代码审查迅速成为新的瓶颈，Morris 提出了开发人员需要回答的这个问题：

"我需要什么才能确信正在构建的代码足够好？"

对于许多组织来说，他们在押注对大型语言模型 (LLM) 来说足够好的东西在总体上也足够好。对他来说，"好"的定义必须始终回到你的用户关心的东西。

"我认为通过尝试将这些方法发挥到最大，我们可以学到很多，即使这可能比我们在某些业务环境中能够安全地做的更进一步，"他继续说。

"LLM 不关心构建能够持久的软件，它们只想构建下一个功能，所以我们需要弄清楚如何无论如何都要做到这一点。"

"LLM 不关心构建能够持久的软件，它们只想构建下一个功能，所以我们需要弄清楚如何无论如何都要做到这一点，"否则它会留下错误的最后影响。

阻碍我们的认知债务

关键问题是我们经常不知道自己不知道什么。

在 AI 生成甚至 AI 部署的代码中，正如 Morris 所描述的那样，"即使我没有查看代码，我如何理解正在发生的事情、它构建了什么，以及它是如何组合在一起的，这样它不会超越我，然后你失去对它的追踪，而且它变得更难进行更改和修复事情，因为你不再有控制权了。"

开发者生产力 SPACE 框架的共同作者 Margaret-Anne Storey 最近发布了她的三重债务模型，探索了 AI 加速软件开发的隐藏人类成本，分为三个方面：

技术债务，存在于代码中。

认知债务，存在于团队中的人员中。

意图债务，存在于外部化的知识中，由文档记录不足的基本原理、目标和设计约束组成。

那么我们如何避免这种认知债务，以免达到 Morris 所称的认知投降，同时仍然不需要查看代码呢？这需要找到强制执行质量约定的方法，包括在公民开发者中。

至少这个答案已经存在了 16 年——在 CI/CD 管道中。他说，那是你把人类放在循环上，管理代理如何构建能够持久的软件的地方，以一种缩小认知差距的方式。

为了实现这一点，它归结为持续交付的下一个层次，称为驾驭工程。

通过驾驭工程来驾驭代码质量

在驾驭工程中，软件构建者——技术和非技术开发者——围绕代码工作在约束机制上。

根据 Morris 的定义，约束机制允许你提出一个想法，然后 AI 构建，然后你围绕这个过程进行迭代。团队工作以创建指南，告诉代理如何构建，包括随时间提供上下文的架构决策记录。

为了实现这一点，他说，我们必须感知可操作性——软件、基础设施和流程的组合——通过经典的跨功能和非功能指标：

滞后指标——可交付性指标，包括 DORA 指标、用户满意度、业务运营指标（交易、成本）、商业指标

领先指标——可部署性指标，包括失败率、性能和可扩展性测试、失败场景测试、渗透测试和合规性审计

这些都有助于确保代码库始终是生产就绪的。

他承认这不是令人兴奋的 AI 代理工作，但有多少团队至少在做这些基本的领先指标？当你意识到你的滞后指标下降时，可能为时已晚。这些领先指标可能很乏味，但这也是 AI 代理通常在实现方面表现出色的地方——只要代理清楚什么是"好"的样子。

然后，一旦这些软件工程最佳实践最终到位，Morris 建议你现有的持续交付管道充当可操作性约束机制，内置所有领先指标传感器。

现在是我们尽可能多地了解 AI 驱动的软件开发的时候，他辩称这来自于全力投入。但你只有在有正确的约束机制到位时才能全力投入，这只有在你构建构建系统的系统时才能发生。

"当你进入具体细节时会出现阻力，比如当我在 [PlatformCon] 演讲中说也许你甚至不应该查看代码时，"Morris 说。