优秀开发者为何对智能体开发保持谨慎

简而言之
优秀的开发人员对智能体开发持谨慎态度，是因为他们知道：构建完成并不等同于在生产环境中正常运行。

让我感到意外的是，有这么多优秀的开发人员不愿全面投入编程智能体的使用。这些人通常会比其他人更早尝试新的工作方式，而且往往会发明新的工具和实践，以支持高质量地构建应用。那么，我们为什么会有如此大的抗拒？

简单（懒惰？）的答案是，他们喜欢写代码，或者担心自己的工作。我敢肯定，对于有些人来说，在某些时候，这确实是真的。我也知道，与我交流的一些开发人员确实如此，但我始终觉得还有别的因素——在这些显而易见的原因背后，还藏着另一种恐惧。每当我们每六个月编制一次 Technology Radar 时，我都会尽量安排一段时间让我们举行一次开放空间会议。9月，我们围绕智能体开发进行了一场充分深入的讨论，最终让我清楚看到了那种恐惧究竟是什么。

正确地构建

Thoughtworks 非常重视打造正确的产品，并以正确的方式构建。这几乎是我们默认的工作与思考方式，我们发明并倡导的许多实践和技术都源于此。我们希望软件既实用又有帮助，到了明年还能更改，而且在生产环境中不会崩溃。我们的开发人员很早就采用、倡导或发明了持续集成、结对编程、自动化测试、持续交付、微服务等许多技术和实践的早期版本，因为它们帮助我们正确地构建软件。

早期编程智能体让生成代码变得非常容易，其中甚至包括一些我们根本不希望出现在生产环境附近的代码；这些代码由尚未认识到构建某样东西与让它在生产环境中安全运行之间鸿沟的人编写。工具已经得到了极大的改进，但经验丰富的开发人员仍有问题：我们确信这种行为是正确的吗？它会按预期运行吗？这些边界设定正确吗？我们能让它继续演进吗？它是否遵循了我们通过惨痛教训总结出来的原则与实践，从而让我们有信心它能满足客户需求并在生产环境中保持正常运行？某个环节出故障时会发生什么？另一个团队能否接手并正常使用它？诸如此类。

在所有这些问题之下，还有一个更大的问题。当所有人都没有以这种方式构建系统的经验时，我们能在多大程度上信任这个系统？让我换一种说法。如今我们在生产环境中的几乎每一个系统，都是以旧方式、由值得信任的人手工构建的（希望如此）。我们现在构建的一切都采用新方式，而我们却还没有真正适应这种方式。

进入科技行业25年多以来，我逐渐开始重视人们通过经验积累形成的判断力。我经常把类似的问题同时抛给模型和 Thoughtworks 的资深技术专家。面对棘手的问题，从人那里我仍能得到更有用的答案；有时，那些拥有非常具体且相关经验的人给出的答案更有洞察力，能帮助我更好地理解问题的关键。他们会质疑前提、从十年前出过问题的事情中识别出某种模式，或发现隐藏在技术问题之中的组织问题。如今，我能接触到多得惊人的信息。我仍然需要有人帮助我梳理什么才是真正重要的，我仍然需要智慧与洞察力。而经验丰富的开发人员之所以谨慎，恰恰是在试图保护这种判断力。

我想把这一点说清楚：他们并不排斥使用编程助手，他们犹豫的是是否要全盘放手，让智能体完成所有执行工作。他们不愿交出方向盘，因为没有十足信心确保智能体已经设置好适当的防护措施，能够自行运行而不跑偏。

在白板前度过的一周

最近，我们的欧洲区域 CTO Giles Alexander 召集高级工程师、基础设施顾问和产品人员，用整整一周正是以这种方式工作。没有人编写代码。所有东西都是智能体构建的。重点并不是证明一个航空公司应用可以在一周内完成。（有意思的是，他们居然完成了 80%，而我们都知道这意味着什么……这种事谁也编不出来！）这次实验的目的，是了解当智能体包办所有编码工作时，团队的工作会发生什么。你可以在这里阅读他们的一些心得。

在交谈中，最让我印象深刻的是他们在白板前花了多少时间。梳理业务领域。划定边界。决定下一步该做什么，并制定智能体可以据此行动的计划。与此同时，智能体持续产出代码，甚至超出了团队正常的工作日时长。

人类员工还在围绕这些工作设计反馈机制：测试、契约、架构检查和交付流水线。他们在摸索如何既给予智能体足够的自由以取得进展，又对结果保持信心。键盘前的大部分工作，是指挥智能体把这些经验写入运行框架，使构建和测试智能体在下一次运行时就做对，从而对它们构建出的成果更有信心。有意思的是，最后提交功能代码最多的反而是团队中的产品人员。

当我问他们估算时，他们说自己大约有 ⅔ 的时间花在白板前，⅓ 花在运行框架上。这或许能让我们对开发者未来的工作方式有了一些线索，但先别急着重新设计你的团队，因为故事还没到结尾……

应用跑起来了。构建却是红的。

应用确实能运行，但构建经常报红。在他们的机器上能正常运行——这种事你就算想编也编不出来！持续报红的构建让我很不安。构建报红本应意味着一件事：停下来，调查，修复。如果它红得太频繁，以至于人们不再留意，我们又该如何发现下一次真正的故障？如果我们无法信任这些检查，那么绿色构建也就不再能让人安心。而这恰恰是持续集成本应消除的不确定性；我们已经倡导持续集成超过 25 年了。

我们仍在探索如何解决这一问题。请记住，这只是一场旨在把智能体开发推向极限的实验。是太多智能体并行工作、彼此踩到对方的改动了吗？是系统的模块化程度还不够，无法让智能体分别处理不同部分吗？还是改动送达的速度超过了检查完成的速度？又或者这些因素，甚至更多因素，组合在一起造成了这一结果？无论如何，我们肯定需要重新思考如何解决最后一公里的挑战。我可以看到，在智能体时代，持续交付/DevOps 这场运动正经历复兴和重新思考，就像开发生命周期的其他环节一样被彻底颠覆。而且这不只是我们的实验。DORA 的 2025 年研究发现，采用 AI 如今与更高的交付吞吐量相关联，但交付稳定性更低。这恰恰是持续交付和 DevOps 一直试图解决的问题！

所有这些挑战促使团队内部展开了一些有益的讨论。当你没有逐行阅读代码，而智能体又与代码一同编写测试时，测试驱动开发应该发挥什么作用？验收测试、契约测试以及系统边界处的检查，要在哪里才能让我们更有信心，同时又不过于脆弱？鉴于我们可以如此迅速地调整方案，在放手让智能体自行工作之前，应该做多少设计？是否存在一个恰当地点，让我们知道自己已经走得太远？这一切中最大的谜团之一是批量大小。我听说许多团队正从 Stories 转向 Epics。这对提升开发速度很棒，但你的 CI 流水线能否以同样的速度并并行处理这种规模的工作单元？

实验团队并没有在一周甚至两周内解决所有这些问题（他们用不同团队进行了两次实验）。我不信任任何声称已经解决这些问题的人。但这正是我希望有经验的开发者参与的工作：进行实验、提出质疑，并帮助我们发现哪些实践经得起考验，以及我们在哪些地方需要引入新的做法。

离开维护过的雪道

与一些参与的资深开发者交流后，我一直在想学滑雪的事。孩子们常常会毫不畏惧地直接冲下山坡，这有点像刚入行的开发者：他们从未把软件部署到生产环境，也从未处理过凌晨 3 点的值班故障（这件事我永远不会忘记，它丝毫不逊于我亲手造成的每一次生产问题，以及由此获得并永远烙印在脑海中的经验教训）。我成年后第一次尝试滑雪时，满脑子想的是自己可能会弄伤什么。我想滑雪，它看起来既有趣又让人自由，但我已经老到能够预见后果了。我可不想拖着一条断腿在伦敦一瘸一拐地四处晃悠，情况甚至可能更糟。我最大的问题是还不知道如何有效转弯或刹车，而在不会这些之前，我在雪坡上就像一列失控的火车。

当我把这篇文章的草稿给 Martin 看时——他也是成年后才学滑雪——他指出这个类比在哪些地方就不成立了（和我喜欢的所有类比一样，我总喜欢把它们推到极限，这个双关是故意的）。在滑雪坡上，你见过无数人毫发无损地滑到底部。教练已经在这条雪道上教过数千人。他们知道哪些技能重要，以及该如何教授。如今的智能体开发更像是一趟穿越未知地域的野外之旅。我们还不知道哪些技能最终会最为重要。能够安全完成这趟行程的人寥寥无几，甚至可能根本没有，而关于如何应对的反馈要么缓慢，要么根本不存在。正如 Martin 所说，在一个主要由智能体构建的系统投入生产环境运行一段时间、经受几轮变更，并且没有把我们的所有飞机都送到阿伯里斯特威斯之前，我们不会知道它是否真的可用。构建完成并不等同于在生产环境中正常运行。或者用 Charity Majors 的话说，“staging 只不过是一台美化过的笔记本电脑。只有 prod 才是 prod”。所以，当有人说“它在我的机器上能运行”时，这通常是个玩笑。或者至少，我总是会笑。

这让我更加确信，自己对领导者一直怀有一种挥之不去的不适感：无论技术型还是非技术型的领导者，都声称开发者缺乏好奇心，或者只是因为采用得太慢而显得落伍，并把原因归结为一些容易明确指出的担忧，比如怀念写代码（我也一样），以及担心我们的工作（现在谁不担心呢？）。我们最优秀的开发者并不是站在人人早已熟练驾驭的初学者雪坡上、紧张不安的新手。他们正面对未经标记的地形，就路线提出合理的问题。告诉他们不要那么谨慎，完全没抓住重点。他们需要成为绘制这张地图的团队一员。

当然，经验也可能让我们对熟悉的做法产生依赖。我们在经过修整的雪坡上学到的一些东西，未必到了那里仍然管用，因此我们必须愿意检验自己的假设。

双方面临的挑战

因此，领导者和开发者双方都面临一项挑战。领导者需要认真倾听，足以分辨哪些是有价值的顾虑、哪些只是抗拒改变，并为实验创造真正的空间。这意味着要给予时间，允许犯错，而且不能把智能体产出了多少代码作为评判成功的标准。开发者需要把自身经验带入这些实验，并准备好发现其中一些假设已不再成立。

一些熟悉的做法会变得更重要。另一些则需要换一种形态。没人会先把地图交给我们。

如果你深切关心做对事情，也关心把事情做对，那么你的判断力正是这种新工作方式所需要的。带上你的谨慎。然后，让我们一起走进雪地。