Agentic编码的未来是多人协作文章探讨了企业采用AI编码工具的挑战，如缺乏上下文、学习曲线和部落知识。提出了规范驱动

文章探讨了企业采用AI编码工具的挑战，如缺乏上下文、学习曲线和部落知识。提出了规范驱动开发和多人远程代理环境Runbook的概念，强调协作、共享和版本控制在AI编码中的重要性。

译自：The Future of Agentic Coding Is Multiplayer

作者：Ankit Jain

无论你喜欢还是讨厌，现在大多数软件开发人员都尝试过某种版本的 AI 编码工具。然而，一旦我们超越每日或每周 AI 工具使用率的虚荣指标，企业中的采用情况就参差不齐。

有些开发人员对此深信不疑，并报告了 10 倍的生产力（除非他们的 token 用完了），还有一些人怀疑这是否真的增加了价值，或者只是增加了技术债务。

事实是，这两种行为都可能在同一家公司中体验到。

企业 AI 采用的问题

企业当前采用 AI 的方法存在一些问题：

缺乏上下文： 在企业庞大而混乱的代码库中工作，远非“氛围编程”。无论模型变得多么好，或者我们如何出色地设计下一个编码代理，如果没有为大型语言模型 (LLM) 代理提供正确和完整的上下文，我们就无法取得进展。
学习曲线： 有效地使用编码代理至少需要一定的培训，而大多数组织目前并未提供。这导致这些工具的使用和成功率各不相同。一些已经尝试和测试过各种方法的开发人员现在已经有了他们方便的指南，说明如何充分利用这些工具，而另一些人仍在浅尝辄止，成功有限。
部落知识： 企业不是一夜之间建立起来的。人员来来往往，经常将大量的部落知识带走。当我们考虑上下文时，我们总是想到关于“什么”和“如何”的文档和规范。许多部落知识围绕着“为什么”。一个组织的演变涉及每天做出的数千个微观决策，形成反映在代码中的决策树。理解产品为何以这种方式构建与如何构建同样重要。这些信息有时甚至可能不会被记录在产品规范中。

最近，我谈到了AI 编码环境的兴起，它们可以自主编码。这些编码代理可以从开发人员那里获取指令，并在很少人工干预的情况下执行它们。这意味着，与绑定到你的 IDE 的编码代理不同，这些代理可以呈指数级扩展，执行数百个并行操作，唯一的限制是可以分配给它们的工作量，当然还有你组织的 LLM 预算。

然而，这只是等式的 infrastructure 方面。缺乏上下文、部落知识丢失以及工程师对 AI 的熟悉程度不同的问题仍然存在。

最终，那些知道如何与基于 IDE 的代理良好协作的工程师将从中获得价值，但远程代理本身并不能解决真正的企业问题：缺乏开发人员与 AI 之间的协作。

规范驱动开发代表了从传统的“氛围编程”到结构化的、规范优先的 AI 开发的最重要的范式转变。这种方法将规范视为“超级提示”：版本控制的、人类可读的文档，作为 AI 代理的综合上下文。将这些文档视为详细的产品规范，充当人类和 AI 代理之间的契约，涵盖业务上下文、边缘情况以及如何浏览代码的明确指导。

考虑到这一点，规范变得比代码更关键和更具约束力。如果情况如此，那么现在是我们像对待一等公民一样对待这些规范的时候了。

我还写了关于代码审查的价值。除了发现错误之外，代码审查还有助于知识共享。这就是部落知识从一个人传递到另一个人的方式。我也是偶尔进行结对编程的忠实粉丝，这有助于快速统一思想。然而，如果我们看看我们的 AI 编码模式，我们所做的一切都恰恰相反：

我们在 IDE 中处理提示，来回向编码代理提供反馈，生成代码，提交代码以供审查，然后丢弃提示。

这些提示是上下文，这些提示是部落知识。现在是我们开始保存这些提示的时候了。

这就是 Runbook 概念的由来。用于代理 AI 的 Runbook是一种保存上下文、协作处理提示、共享执行工作流程以及维护审计跟踪和预配置的远程代理环境的方式。

当涉及多个工程师时，Runbook 的真正力量就会显现出来。使用 AI 代理构建软件不是一项单人运动，特别是当项目涉及多个存储库、服务和提示工程知识时。

Runbook 让团队可以从单人模式切换到多人模式，以：

这些 Runbook 弥合了产品规范和代码之间的差距：

可重用的 Runbook 捕获团队的 AI 提示知识和不断演变的执行模式。如果这些是鲜活的文件，那么维护版本控制非常重要。

有几个好处：

规范是新的代码。一旦我们学会像过去几十年那样在代码上进行协作的方式在规范上进行协作，我们将能够充分利用 AI 代理工具的力量。尝试 Runbook，将 AI 编码从个人实验转变为团队范围内的工程项目。