Why are good developers so wary of agentic development?

为什么优秀的开发者对代理式开发如此谨慎？

Rachel Laycock

我是Rachel Laycock，Thoughtworks的首席技术官。我始终对技术如何改变我们构建软件、领导团队和运营企业的方式充满好奇。这是我在想法尚未成熟时记录灵感、挑战自身思考并偶尔偏离主线探索的地方。

2026年10月29日

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

我惊讶于如此多优秀的开发者对全身心投入编码代理持犹豫态度。这些人通常会率先尝试新的工作方式，在许多情况下还会发明支持良好构建应用的新工具和实践。那么，为什么会出现如此多的抗拒？

简单（或者说懒惰？）的回答是他们热爱编写代码，或者担心自己的工作。我确信对某些人来说这在某些时候是成立的。我知道我接触的一些开发者确实如此，但我总觉得还有其他因素，一些显性恐惧背后隐藏着更深层的担忧。每六个月我们制作技术雷达时，我都会留出专门时间进行开放空间讨论。9月关于代理式开发的讨论将该概念推向极限，最终让我清晰地看到了那个恐惧的本质。

正确构建

Thoughtworkers非常重视做正确的事以及正确地做事。这几乎是我们的默认工作方式和思维方式，也是我们发明并倡导的许多实践和技术的发源地。我们希望软件不仅有用且能帮助用户，还能在明年被修改，且不会在生产环境中崩溃。我们的开发者早期就采用了、倡导甚至发明了持续集成、结对编程、自动化测试、持续交付、微服务等许多实践，因为它们帮助我们正确构建软件。

早期的编码代理使编写代码变得非常容易，包括我们根本不愿接近生产环境的代码，这些代码由尚未理解“构建”与“安全运行于生产环境”之间鸿沟的人编写。工具虽然有了巨大改进，但经验丰富的开发者仍然存在疑问：我们能确信这是正确的行为吗？它是否符合预期？这些边界是否恰当？我们能否持续改进它？它是否遵循了我们通过艰难教训学到的原则和实践，从而让我们确信它能满足客户需求并稳定运行？当出现问题时会发生什么？其他团队是否能接受它？等等。

所有这些问题背后有一个更大的疑问：当没有人有过这种构建方式的经验时，我们能信任这个系统吗？让我换一种方式表达：我们目前生产环境中几乎所有系统都是用旧方式由人工构建的，由我们信任的人（希望如此）完成。现在我们构建的一切都是新方式，但我们尚未真正经历这种方式。

在技术领域深耕25年后，我愈发看重人们通过经验积累形成的判断力。我经常向Thoughtworks的资深技术专家和模型提出类似的问题。对于复杂难题，人类依然能提供更有价值的答案，尤其是那些拥有特定经验的人，他们的见解往往能帮助我更深入地理解问题本质。他们可能质疑前提假设，从十年前的失败案例中识别出相似模式，或发现隐藏在技术问题背后的组织性难题。如今我能够获取海量信息，但依然需要能帮助我理清重点的人，依然需要智慧与洞察力。这种判断力正是那些谨慎的资深开发者试图保护的核心价值。

我需要明确强调：他们并非不愿使用代码助手，而是对完全依赖代理执行所有操作持谨慎态度。他们不愿完全放手，是因为对代理是否具备足够的安全机制来自主运行缺乏充分信心。

一周的白板实践

近期，我们的欧洲区域CTO Giles Alexander组织了一场为期一周的深度协作：召集资深工程师、基础设施顾问和产品经理，以完全依赖代理开发的方式进行工作。期间没有任何人亲自编写代码，所有内容均由代理构建。这次实验的目的并非证明航空应用能在一周内完成（有趣的是他们完成了80%，而我们都知道这意味着什么——你无法凭空捏造事实！）。实验真正目的是观察当代理完成全部编码工作时，团队的工作会发生什么变化。你可以在本文中了解他们的一些发现。

在交流中令我印象深刻的是，团队在白板上投入了大量时间。他们梳理领域边界，绘制架构图，规划下一步行动并制定代理可执行的方案。与此同时，代理在团队工作日结束后仍在持续生成代码。

人类团队同时设计了围绕这些工作的反馈机制：测试用例、接口契约、架构校验和交付流水线。他们探索如何在给予代理足够自由度推进工作的同时，保持对结果的信心。大部分键盘操作实际上是在指导代理将这些学习成果整合到框架中，确保构建和测试代理在下一次运行时能准确执行，从而提升对构建结果的信心。有趣的是，最终产品经理提交的特性代码量在团队中是最多的。

当被问及时间分配时，他们表示大约三分之一的时间用于白板讨论，三分之一用于框架调试，这或许能给我们一些未来开发工作模式的线索。但在你急于重新设计团队结构之前，请记住这并非故事的全部……

应用运行了，但构建状态是红色

应用确实运行了，但构建状态频繁显示为红色。它在开发者的机器上能正常运行——这简直荒谬到让人无法编造！持续的红色构建让我感到不适。红色构建应该意味着：停止、调查、修复。如果红色构建如此频繁以至于人们不再关注，我们如何发现下一个真正的故障？更糟糕的是，如果我们无法信任这些检查机制，绿色构建也无法提供任何保障。这正是持续集成本应消除的不确定性，而我们倡导持续集成已有25年多。

我们仍在探索如何解决这些问题。请记住，这是一次旨在推动智能代理开发极限的实验。是否太多代理同时运行并互相干扰了彼此的更改？系统是否尚未模块化到足以让代理独立处理不同部分？还是更改的频率超过了检查机制的处理速度？又或者这些因素共同作用导致了问题？无论如何，我们确实需要重新思考如何解决最后一公里的挑战。我看到持续交付/DevOps运动在智能代理时代将经历复兴和重新思考，就像整个开发生命周期正在被颠覆一样。这不仅仅是我们的实验。DORA 2025年研究发现，AI的采用现在与更高的交付吞吐量相关，但与更低的交付稳定性相关。这正是持续交付和DevOps试图解决的问题！

这些挑战引发了我们内部的一些深入讨论。当代理在没有阅读每一行代码的情况下创建测试时，测试驱动开发应扮演什么角色？验收测试、契约测试和系统边界检查如何在不过于脆弱的前提下为我们提供更多信心？考虑到我们能如此快速地修订方法，我们应在释放代理前投入多少设计工作？我们是否会有一个明确的临界点意识到自己已经走得太远？所有这些挑战中最大的谜题之一是批量的大小。我听到许多团队正在从用户故事转向史诗级任务。这对开发速度很有利，但你的CI流水线能以高速并行处理如此规模的工作单元吗？

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

离开已平整的雪道

在与一些资深开发者讨论后，我一直在思考学习滑雪的过程。孩子们常常会毫无畏惧地直接冲下山坡，这有点像一个从未将软件投入生产、也从未在凌晨3点修复过值班问题的新手开发者（这是我永远无法忘记的事情，与我亲自造成的所有生产问题及其带来的教训一样深刻）。当我第一次作为成年人尝试滑雪时，我一直在想自己可能会摔坏什么。我想滑雪，它看起来如此有趣和自由，但我也足够成熟，能看到后果，不想在伦敦拖着骨折的肢体蹒跚前行，更不用说更糟的情况了。我最大的问题是当时还没有学会如何有效转弯或停止，没有这些技能，我就像滑雪坡上的脱轨列车。

当我和马丁分享这篇帖子的初稿时，他也是一名较晚才开始学习滑雪的人。他指出了这个类比的局限性（就像我喜欢把所有类比都推向极限一样，双关语在此使用）。在滑雪场，你已经看到无数人安全抵达底部，没有骨折。教练们在同一条雪道上教过成千上万的人，他们清楚哪些技能重要，以及如何教授这些技能。而目前的代理式开发更像是在未知领域进行的越野探险。我们尚未知道哪些技能会变得最关键。几乎没有多少人，甚至没有人，能够安全地完成这次旅程，而关于如何导航的反馈则缓慢或根本不存在。正如马丁所说，我们只有在系统投入生产运行一段时间、经历几次变更周期、并且没有把所有飞机都送到阿伯里斯特威斯之后，才能知道一个高度依赖代理的系统是否真的有效。构建完成并不等同于在生产环境中正常运行。正如查理蒂·马乔斯所说：“预发布环境不过是一台升级版的笔记本电脑。只有生产环境才是真正的生产环境。”这就是为什么当有人说“在我的机器上能运行”时，这通常只是一个玩笑。至少我总是会笑。

这强化了我长期以来对领导者（无论是技术还是非技术背景）的一种不安感。他们声称开发者缺乏好奇心，或者在采用新技术时行动迟缓，并将这些归咎于一些容易指摘的恐惧，比如害怕写代码（我自己也有这种恐惧）或担心工作不保（谁现在不是这样？）。我们最优秀的开发者并不是在初级雪道上战战兢兢的新手，其他人早已掌握了这些技能。他们正面对着未标记的地形，提出合理的问题来探索路线。告诉他们要少些谨慎，就完全误解了重点。他们需要加入那个绘制地图的团队。

当然，经验也可能让我们过于依赖熟悉的实践方式。我们在已平整的雪道上学到的一些东西在那之外可能不再适用，我们需要愿意检验自己的假设。

双方都面临的挑战

因此，这里对领导者和开发者都提出了挑战。领导者需要仔细倾听，区分有用的担忧和对变革的抗拒，并为真正的实验创造空间。这意味着要给予时间、允许犯错的权限，以及不要用代理生成的代码量来衡量成功。开发者需要将他们的经验带入这些实验中，并准备好发现一些假设可能不再成立。

一些熟悉的实践方式会变得更加重要，而其他方式则需要不同的形态。没有人会先给我们一张地图。

如果你对构建正确的产品和以正确的方式构建产品有强烈的关注，那么你的判断正是这种新工作方式所需要的。带着谨慎，让我们一起出发，走进这片雪地。

最新文章（10月29日）：

为什么优秀的开发者对代理式开发如此谨慎？

上一篇文章：

也许我们不应该审查所有这些代码

所有文章