开发者依赖工具因工具承载信任工具不断推陈出新功能持续变化。若菜刀形状、重量和刀刃不断改变每次使用都需重新适应这样的工具难以让人产生信任这也反映出使用工具的方式、围绕工具的流程以及工具强化流程的方式可能存在问题。大约六年前曾发表一篇关于集成开发环境IDE的文章核心观点是 IDE 功能日益强大却还有人使用 Vim 或 Emacs。文章虽具挑衅性却引发众多开发者热议。评论来自不同阵营有人批评文章不了解开发者工作方式也有开发者宣扬 Emacs 的优点大家主要围绕工具为何实用展开讨论。对于新手Vim 和 Emacs 像是难以捉摸的终端程序需记住神秘按键组合才能使用甚至包括退出方法。但对有经验的用户来说使用它们就像思考一样自然。有评论提到《实用程序员》书中指出开发者作为技艺精湛的工匠需要“称手的工具”如同手的延伸。Vim 和 Emacs 可无限定制能根据使用习惯和工作流程调整。花时间掌握工具、建立信任并个性化设置会带来丰厚回报。如今智能工程时代新工具是能用自然语言交流的终端。编码智能体虽能短时间生成完整应用程序但输出结果能否值得信任仍是问题。上一次开发者调查发现开发者使用人工智能频率越高信任度越低使用比例从 76% 上升到 84%信任度从 40% 降至 29%。工具不断更新功能不断变化就像菜刀形状等改变难以让人建立信任也暴露出使用工具及相关流程可能存在的问题。信任喜欢的工具是因为与之建立了信任并形成可靠使用流程。本文将探讨工具如何构建可靠流程工具变化如何凸显但无法修复有问题的流程以及工具和文化如何共同建立新信任。工具是流程的一部分开发者工具与软件开发整体及单个开发者共同发展。若从终端环境开始工作学习对代码创建的理解就包含终端和终端文本编辑器。引入 IDE 不仅要学习新工具还需重构代码编写流程。从终端过渡到 IDE 艰难从两者之一转向智能编码工具更难。开发者生产力倡导者 Tricia Gee 表示不太愿意接受人工智能编程工具因对自己的 IDE 操作更熟练知道如何高效使用。和熟悉 Vim 和 Emacs 的人合作时也看到同样情况使用 IntelliJ IDEA 中的重构工具他们会觉得有学习成本。花长时间使用某个工具手指会形成肌肉记忆深入了解后会形成无意识能力。建立肌肉记忆和对软件代码层面的隐性知识能让开发者信任工具帮助生成和改进代码。然而人工智能智能体速度快但不够透明且难以预测使用模糊语言创建软件而非编写精确代码。C 之父 Bjarne Stoustrup 说代码是对解决方案的精确表述英语在表达必须明确的内容时是糟糕的语言。可靠工具应可预测、值得信赖使用 Emacs 或 Vim 无需反复尝试。对于大多数开发者工具如 IDE、容器化工具或静态分析器清楚它们的边界和作用范围各司其职不会越界。但人工智能正在渗透到软件开发生命周期SDLC的各个环节这意味着开发者对人工智能信任度的降低会影响整个开发流程。虽然代码生成速度加快但验证代码并确保其不会在生产环境中导致昂贵故障往往需要花费更多时间。工具体现流程但无法修复流程智能编码工具改变了软件开发流程的本质。围绕之前流程产生的工具如代码检查器、自动化单元测试、持续集成/持续交付CI/CD等在当前形式下可能无法适应新的流程。这些工具体现了流程但本身并非流程。出色的 CI/CD 工具不意味着能更快发布软件优秀的 IDE 不意味着能写出更好的代码带有故事点的问题跟踪系统不意味着能准确估算工作量。流程的一部分体现在文化层面即软件开发人员的行为和规范。新工具往往意味着改变组织文化。对于在大型工程组织工作的人来说若新工具与现有文化和流程不匹配就可能失败。成功的工具需要以开发者能够接受和理解的方式改变文化和流程。不能帮助更好完成工作的工具会被忽视。智能编码工具迅速得到应用是因为能让开发者更快解决问题。但当代码变得几乎随手可得时也暴露出了现有流程中的许多缺陷。需求不明确和不断变化一直是问题现在解决问题需要明确界定“问题”和“解决方案”的含义。代码或许可以免费生成但验证代码并非如此。新的瓶颈变成了代码审查。编码智能体瞬间就能修改数百行代码并将大量差异内容发送给人类进行审查或直接批准。以大语言模型LLM作为评审者正在成为一种可扩展的解决方案但要让人们相信人工智能能够审查人工智能编写的代码还需要付出努力。运行代码也并非免费需要承担基础设施成本、托管依赖项和 API 的成本还有故障成本这是最难预算的部分包括停机时间、安全漏洞和机会成本。不考虑这些成本的工具可能并不值得使用还会给之前用于生成可靠软件的流程带来压力。由于智能编码工具的出现SDLC 似乎开始出现问题。人们希望借助新工具修复这些问题如人工智能站点可靠性工程AI SRE、自动化代码审查、内存和上下文管理器、控制平面和管理工具的改进等。但仅靠工具无法解决问题特别是如果文化和流程保持不变。有问题的流程即使配备了更好的工具仍然是有问题的。用更好的流程建立信任在传统的 SDLC 中产品经理根据研究、与客户的沟通以及对竞争对手的了解提出功能和特性需求架构师根据多年经验和对现有技术栈的理解设计软件架构工程师根据对代码逻辑和现有代码库的了解构建软件并审查提交的代码质量保证QA人员根据对软件可能出现问题的经验审查并尝试破坏软件软件部署到生产环境后开发运维DevOps和站点可靠性工程SRE人员根据以往经验监控和管理软件的性能和资源使用情况。在这个系统中建立信任需要与他人合作了解他们的思维方式并限制任何个人或工具出现问题而对整个系统造成严重破坏的可能性。在人工智能驱动的 SDLC 中建立信任也需要同样的要素与他人合作确保他们负责并承担责任分享工作流程并不断迭代尽量减少出错的可能性。第一步是确保人类作为责任主体并明确标识人工智能的贡献之处。大家都在谈论“人在回路”但 Honeycomb 首席技术官 Charity Majors 指出“‘人在回路’听起来像是一种怜悯式的邀请。这个回路是我创建的我拥有它它存在的唯一原因就是我。这是我他妈的回路”提交代码的人要对代码负责批准 PR 的人要对批准行为负责。如果在引入人工智能之前在周五搞砸了生产环境不会责怪 IDE。现在如果出了问题问题也不在于智能体而在于使用它的人。在人工智能时代协作可能变得更加困难和陌生。智能体让开发者对全栈开发者的概念有了新认识一个人可以通过编码智能体完成从产品需求到 DevOps 的所有工作开发者很容易变成孤立的个体。Slack 首席产品官 Jaime DeLanghe 说“不必再和设计师沟通设计问题因为可以让智能体来完成设计。也不必和特定领域的其他工程师合作来理解他们的代码库因为可以直接问智能体。可能会沿着这条路走下去创建一个巨大的 PR。”有人建议在共享空间中与智能体交互这样每个人都可以发表评论并修改流程。还有人建议每个 PR 都包含与智能体交互的记录。通过查看与智能体的对话或许能更深入地了解代码的生成过程。Cloudflare 首席技术官 Dane Knecht 说“能够打开一个 PR 并看到开发者的思考过程和问题解决方式真是太棒了。”在旧的流程中使用访问控制、审计跟踪、差异比较和 CI/CD 检查来限制任何错误的影响范围。而新的流程需要在代码编写之前消除不确定性这意味着要在提示中明确说明希望代码实现的所有功能。可以使用 spec.md 文件来实现这一点但任何未明确指定的内容可能不会被实现。微软开发者社区副总裁 Scott Hanselman 说“如果留下任何不确定性它就会一直存在。要构建一个小的环形灯应用程序使用的是 x64 系统但希望它能在 ARM 架构上运行所以必须告诉智能体‘为我生成一个 ARM 版本’。如果不这么做就不会有 ARM 版本。”当然不可能在一个巧妙的提示中涵盖所有需求这样做会让人不断重复自己而且几乎肯定会遗漏一些公司内部的隐性知识。很多聪明人都在思考如何为智能体提供更好的上下文信息赋予它们长期和短期记忆。关键是要给智能体提供代码所需的正确上下文通常这是资深开发者随着时间积累的经验。但智能体需要将这些知识存储在某个地方进行验证并在需要时提供正确的信息作为上下文。假设拥有一个完美的提示为智能体提供了正确的上下文它生成了通过同行评审并部署到生产环境的软件。接下来要确保不再重复构建同样的功能。已经有了一个完美的软件组件不要丢弃它而是要复用它。Bit 首席科学家 Laly Bar - Ilan 说“‘不要重复自己’DRY原则是主要原则。如今的人工智能本质上是‘重复编写一切’WET。一个开发者让它‘生成一个按钮’它很高兴地生成了然后另一个团队的开发者又让它生成代码库中就会有另一个按钮。”与人工智能智能体建立信任的最大诀窍可能是知道何时不使用它们。即使在流程中设置了所有保障措施由于人工智能的本质特性仍然存在一定的不确定性。如果已经有一个运行良好的确定性解决方案为什么还要重新发明轮子呢Anil Dash 说“我们试图将非确定性系统应用于很多应该使用确定性代码的场景。大语言模型在这些方面表现不佳那么为什么我们还要试图用它们来解决那些不适合的问题呢一个运行了六年的简单 bash 脚本就挺好的。”过去通过与合作的人和使用的工具建立信任这种信任源于可预测性。人工智能的概率性本质以及其改进和变化的速度让这一切都变得不确定。改进流程有助于在开发过程中重新建立信任。结论过去围绕人构建流程因为信任一起工作的人所以也信任这些流程。打造信任的工具来管理流程这些工具就像自身和合作伙伴的延伸。有了人工智能很多流程得以自动化好处是工作完成得更快但问题是对完成的成果缺乏信任。工具是新的人们承担着更高级的角色仍需建立信任。通过精心设计、明确定义且保留人类判断力的工作流程可以开始在新系统中建立信任。成功的团队不是生成最多代码的团队而是能够建立反馈循环、拥有提供最佳上下文的黄金标准知识以及使流程与工作流相匹配的工具的团队。