为什么优秀开发者对智能体开发如此警惕？

TL;DR
优秀开发者对智能体开发的谨慎，源于他们深知“构建出来”并不等同于“在生产环境中正常运行”。

我很惊讶有这么多优秀的开发者一直不愿全力投入编码智能体。这些人通常是比任何人都更早尝试新工作方式的人，很多时候还会发明新的工具和实践来支撑良好的应用构建。那么，为什么会有这么多抵触情绪呢？

简单（偷懒？）的答案是：他们热爱写代码，或者担心自己的工作不保。我确信对某些人来说、在某些时候确实如此。我也知道对我交谈过的一些开发者来说这是真的，但我总觉得还有别的东西，另一种恐惧藏在那些显而易见的恐惧背后。每六个月我们整理技术雷达时，我都会尽量留出一段时间来做开放空间讨论。九月份，我们进行了一场关于智能体开发的讨论，把它推到了极限，终于帮助我看清了那种恐惧究竟是什么。

正确地构建

Thoughtworkers 深切关注构建正确的东西，并以正确的方式构建它。这几乎是我们默认的工作和思考方式，也是我们发明和倡导的许多实践与技术的来源。我们想要有用的、有益的软件，明年还能改，而且不会在生产环境中崩溃。我们的开发者早早地采纳、倡导或发明了持续集成、结对编程、自动化测试、持续交付、微服务等许多实践的最初版本，因为它们帮助我们正确地构建软件。

早期的编码智能体让生成代码变得非常容易，包括那些我们根本不想让它们靠近生产环境的代码，而且写这些代码的人还没有了解“构建出某个东西”与“让它在生产环境中安全运行”之间的巨大鸿沟。工具已经有了巨大的改进，但经验丰富的开发者仍然有疑问。我们确信这是正确的行为吗？它是否按预期工作？这些是正确的边界吗？我们能够演进它吗？它是否遵循我们历经艰辛才学到的原则和实践，让我们有信心它能满足客户需求并在生产环境中稳定运行？出问题时会发生什么？另一个团队能接手它吗？等等。

在所有这些之下，还有一个更大的问题。当没有人有过以这种方式构建系统的经验时，我们能对一个系统抱有多大信任？让我换一种说法。我们现在生产环境中的几乎每一个系统，都是按旧方式构建的，手工构建，由我们（但愿）可以信任的人构建。我们现在构建的一切都是新方式，而我们还没有与之共处过。

在技术行业工作超过 25 年后，我逐渐看重人们通过经验培养出的判断力。我经常向模型和 Thoughtworks 的资深技术专家提出类似的问题。对于困难的问题，我仍然能从人类那里得到更有用的答案，或者说是更有洞察力的答案，带着非常具体的经验，帮助我更好地理解问题所在。他们会质疑前提，从十年前出过问题的某件事中识别出模式，或者发现隐藏在技术问题背后的组织问题。我现在可以获取海量的信息。但我仍然需要能帮我思考什么才是重要的人，我仍然需要智慧和洞察力。这种判断力，正是那些犹豫不决的资深开发者试图保护的东西。

我想明确一点：他们并非不愿使用编码助手，而是不愿全力投入、让智能体执行所有工作。他们不愿放手，因为他们并不完全相信智能体已经具备正确的防护机制，能够自主运行。

在白板前的一周

最近，我们欧洲区域CTO Giles Alexander召集了资深工程师、基础设施顾问和产品人员，用整整一周时间完全以这种方式工作。没有人写任何代码，一切由智能体构建。目的并不是证明一个航空应用能在一周内建成。（有趣的是，他们完成了80%，而我们都明白这意味着什么……这可不是编的！）这次实验的目的是了解当智能体完成所有编码工作时，团队的工作会发生什么变化。你可以在这里读到他们的一些收获。

在交谈中最让我触动的是，他们在白板前花了多少时间。梳理领域。划定边界。决定下一步该做什么，并制定智能体可以执行的计划。与此同时，智能体在团队工作时间之外仍在持续产出代码。

人类还在围绕这些工作设计反馈机制：测试、契约、架构检查和交付流水线。他们在摸索如何给智能体足够的自由以取得进展，同时保持对结果的信心。键盘前的大部分工作是指挥智能体把这些学习成果固化到测试框架中，好让构建和测试智能体在下一次运行时做对，从而对他们构建的东西更有信心。有趣的是，最终团队中提交功能代码最多的人反而是产品人员。

当我让他们估算时，他们说大约⅔的时间花在白板前，⅓花在测试框架上，这或许能让我们窥见未来开发者将如何工作，但先别急着重新设计你的团队，故事还没结束……

应用能跑。构建却是红的。

应用能跑，但构建经常是红的。在他们机器上能跑——这你要是想编都编不出来！持续红色的构建让我很不舒服。红色构建应该意味着什么：停下来，调查，修复。如果它红得太频繁，以至于人们不再关注，我们又如何发现下一个真正的失败？而如果我们不能信任这些检查，绿色构建也不再让人安心。这正是持续集成本应消除的不确定性，而我们已经倡导它超过25年了。

我们仍在研究如何解决这个问题。记住，这是一次将智能体开发推向最前沿的实验。是太多智能体并行工作、互相踩踏彼此的改动？还是系统还不够模块化，无法让智能体在各自独立的部分工作？或者只是改动到达的速度快于检查完成的速度？还是所有这些甚至更多因素的组合？无论如何，我们确实需要重新思考如何解决最后一英里的挑战。我可以预见，持续交付/DevOps作为一场运动，将在智能体时代迎来复兴和重新思考，就像开发生命周期的其他部分正在被颠覆一样。而且这不仅仅是我们的实验。DORA 2025的研究发现，AI的采用如今与更高的交付吞吐量相关，但也与更低的交付稳定性相关。这正是持续交付和DevOps一直试图解决的问题！

所有这些挑战都在内部引发了一些很好的讨论。当你并不逐行阅读代码、而且测试是由智能体与代码一同生成时，测试驱动开发应该扮演什么角色？验收测试、契约测试以及系统边界处的检查，怎样才能在不至于过于脆弱的前提下给我们更多信心？考虑到我们修改方案的速度如此之快，在放手让智能体去做之前，我们应该做多少设计？是否存在一个合适的节点，让我们知道自己已经走得太远？这一切中最大的谜题之一是批次的大小。我听说许多团队正在从 Story 转向 Epic。这对开发速度是好事，但你的 CI 流水线能否以高速并行处理这种规模的工作单元？

实验团队并没有在一周甚至两周内解决所有这些问题（他们用不同的团队跑了两轮）。我不会相信任何声称已经解决的人。但这正是我希望有经验的开发者参与的那类工作：实验、质疑，并帮助我们发现在哪些实践上站得住脚、在哪些地方我们需要一些新的实践。

离开平整的雪道

与参与这次对话的一些资深开发者交流之后，我一直在想学滑雪这件事。孩子们常常毫无畏惧地径直冲下山坡，有点像从未把软件投入生产、从未在凌晨 3 点处理过线上故障的新手开发者（这是我永远不会忘记的经历，与我个人造成的每一次生产事故以及由此得到的教训一样，深深烙印在我的脑海里）。当我成年后第一次尝试滑雪时，我满脑子想的都是自己可能会摔坏什么。我想滑雪，它看起来那么有趣、那么自由，但我已经足够大，能看到后果，我可不想断着胳膊腿——或者更糟——在伦敦一瘸一拐地走动。我最大的问题是我还没学会如何有效地转弯或刹车，没有这些，我在雪道上就是一列失控的火车。

当我把这篇文章的草稿分享给 Martin 时——他也是较晚才学会滑雪的——他指出这个类比在哪里站不住脚（就像所有类比一样，我喜欢把它们推到极限，双关语意在其中）。在雪道上，你见过无数人安然无恙地到达坡底。教练在你之前已经在同一条雪道上教过成千上万的人。他们知道哪些技能重要，以及如何教授这些技能。而如今的智能体开发更像是穿越未知地带的野外旅行。我们还不知道哪些技能最重要。没有多少人（如果有的话）安全完成了这趟旅程，而关于如何前行的反馈要么缓慢，要么根本不存在。正如 Martin 所说，除非一个大量由智能体构建的系统在生产环境中运行了一段时间、经历了几轮变更，并且没有把我们所有的飞机都送到阿伯里斯特威斯，否则我们不会知道它是否可行。构建完成并不等同于在生产中正常工作。或者正如 Charity Majors 所说，“预发环境不过是一台被美化的笔记本电脑。只有生产环境才是真正的生产环境”。这就是为什么当有人说“在我机器上能跑”时，通常是在开玩笑。至少我总是会笑。

这印证了我一直以来的一个挥之不去的不适感：无论是技术还是非技术背景的领导者，都声称开发者缺乏好奇心，或是迟迟不愿采纳新事物的落后者，并把这一点归咎于那些容易指认的恐惧，比如担心写不好代码（我也一样），以及害怕丢掉工作（眼下谁不是呢？）。我们最优秀的开发者并不是在人人皆已掌握的缓坡上战战兢兢的初学者。他们正注视着没有标记的地形，对路线提出合理的问题。告诉他们少一些谨慎，恰恰没有抓住重点。他们需要加入那个绘制地图的团队。

当然，经验也可能让我们过于依恋熟悉的做法。我们在平整雪道上学会的一些东西，到了那里未必管用，我们需要愿意检验自己的假设。

对双方都是挑战

所以，领导者和开发者都面临挑战。领导者需要足够仔细地倾听，以区分有益的担忧和不愿改变，并创造真正用于实验的空间。这意味着时间、允许犯错的许可，以及不以智能体生成了多少代码来评判成功。开发者需要把经验带入这些实验，并准备好发现自己的某些假设不再成立。

一些熟悉的做法会变得更加重要。另一些则需要改换形态。没有人会先递给我们一张地图。

如果你深切关心构建正确的东西并把它构建好，你的判断力正是这种新工作方式所需要的。带上这份谨慎。然后，让我们出发走进雪中。