开发者依赖 Vim、Emacs 或集成开发环境等工具，并不只是因为习惯了它们，而是因为这些工具逐渐成为他们思考、编写和审查代码的方式的一部分。随着用户积累长期经验，命令和操作会转化为隐性知识和肌肉记忆，使工具看起来像是手的自然延伸。这种关系解释了人们对代理编程工具产生的一部分犹豫：这类工具能够快速生成完整应用，但在精确性、清晰度和可预测性方面较弱。
文章将工具与信任以及围绕工具的流程联系起来。可靠的工具不仅要能够执行任务，还要让开发者了解其边界和行为，并能够预期结果。而代理式人工智能工具的能力持续变化，依赖的自然语言指令也可能含糊不清。根据文章提到的最近一次开发者调查数据，人工智能的使用率从 76% 上升到 84%，但对人工智能的信任度从 40% 降至 29%。
工具是开发流程的一部分
学会在终端、文本编辑器或集成开发环境中工作，并不只是学会一个独立的软件；这意味着要建立一套完整的代码编写、理解和改进流程。因此，从终端转向集成开发环境可能需要重新设计工作方式，而从其中任何一种工具转向代理编程工具，则代表着更大的转变。
开发者生产力倡导者 Tricia Gee 解释说，开发者使用自己熟悉的开发环境时可能会更快，因为手指已经习惯了应该做什么。经验丰富的 Vim 和 Emacs 用户也是如此。随着时间推移，开发者会形成一种无意识的熟练度，这种熟练度帮助他们信任工具，并使用工具生成和改进代码。
传统工具，如集成开发环境、容器工具和静态分析器，会让用户清楚地了解它们的边界和作用。人工智能则渗透到软件开发生命周期工具链的多个环节，因此对人工智能信任度的下降会影响整个流程。代码编写可能变得更快，但验证代码并确保它不会在生产环境中造成代价高昂的故障，可能需要更长时间。
工具无法修复失灵的流程
代理编程工具改变了开发流程的性质，这可能使围绕原有流程形成的工具，例如静态检查、单元测试、集成和持续部署工具，以当前形式变得不再合适。但文章区分了工具与工具所体现的流程：优秀的持续集成和持续部署工具并不能保证更快交付，强大的集成开发环境并不能保证编写出更好的代码，问题跟踪系统也不能保证准确估算工作量。
流程的一部分形成于组织文化、成员行为和组织标准之中。因此，无论新工具的承诺看起来多么宏大，如果它们与现有文化和流程不一致，或者开发者不理解使用它们的原因，就可能失败。文章指出，代理编程工具之所以迅速普及，是因为它们帮助开发者快速解决问题；但与此同时，它们也暴露了需求确定、问题定义以及“解决问题”含义方面长期存在的缺陷。
与过去相比，代码的生成几乎变得免费，但代码审查并没有如此。开发者可能会面对代理在短时间内生成的大量合并请求变更，这会增加审查者的负担，或导致人们采用形式化的审查。人们正在开发将语言模型作为裁判使用的方法，以扩大审查范围，但要建立对人工智能审查人工智能所编写代码能力的信任，还需要额外工作。
运行代码也有成本。这些成本包括基础设施成本、云资源成本，包括计算、内存和流量，依赖服务和托管的应用程序接口，以及停机、安全漏洞和机会成本等故障成本。不考虑这些因素就生成代码的工具未必有用，还可能削弱原本能够产出可靠软件的流程。
通过责任和流程建立信任
在传统开发周期中，信任分布在相互关联的角色之间：产品经理确定需求，架构师设计解决方案，工程师构建软件并审查变更，质量保证团队测试崩溃点，然后 DevOps 和 SRE 专家在发布后监控性能和资源。这种分工有助于降低个人或工具越界操作并损害系统的可能性。
文章认为，人工智能支持的开发周期需要类似的原则：与人协作，明确责任和问责，共享并逐步改进流程，以及减少出错的机会。人类应继续作为负责任的一方，同时明确人工智能在哪些环节作出了贡献。
责任不会因为代理创建了变更就转移给代理。将变更推送到代码仓库的人对代码负责，批准合并请求的人对批准行为负责。按照文章提出的逻辑，如果变更导致生产环境崩溃，就不能把责任归咎于开发环境或工具；责任应由允许该变更通过的人员和流程承担。
这种转变还带来了另一个与协作有关的挑战。代理可能让一名开发者独自完成从产品需求到 DevOps 操作的一系列任务，从而增加其变成孤岛的可能性，使其不再与设计师或负责某个特定代码库的专业工程师沟通。文章警告说，即使工具能够快速执行工作，这条路径也可能导致出现巨大的合并请求。
核心结论并不是新工具没有用，而是仅仅改进工具不足以修复失灵的开发周期。组织需要开发者能够理解并接受的流程、明确的代理角色边界、真正承担责任的人类审查，以及能够防止开发变成封闭式个人活动的协作。这样，工具与文化才能共同作用，在依赖人工智能的开发环境中建立新的信任。