AI 编程

代码能跑 ≠ 系统能用：好开发者为什么对 Agent 开发更谨慎

一个团队两周的实验：没人写代码，全交给 agent。结果是 ⅔ 时间耗在白板、构建长期飘红，而最谨慎的那批人其实说对了。

Thoughtworks 的 CTO Rachel Laycock 观察到一个反直觉的现象：最愿意试新工具的那批开发者，恰恰最不愿意把方向盘完全交出去。

这些人通常是"别人还在观望时就已经在新方式里试水"的人，很多实践和工具就是他们先做出来、先推起来的。所以当她说"很多极其优秀的开发者对 coding agent 很犹豫"，她的解释不是"他们不会用"——她明确写了一句话澄清：他们不排斥用编码助手，他们排斥的是全押上去、让 agent 完成全部执行。

那这层犹豫到底是什么？2026 年 9 月，Thoughtworks 技术雷达（Technology Radar）那一轮的开空间（open space）讨论把这个话题推到了极限，她才看清背后那个东西。

2026 年 10 月 29 日，她把这套想法写成了这篇文章。

一、"建好了"和"能在生产里跑"之间隔着什么

Thoughtworks 的人在意两件事：做对的东西，并且把它做对。这不是口号，是他们大部分实践和技术的来处——他们要的软件是有用的、明年还能改、而且不会在生产里翻车。

所以这个团队在很早的时候就采纳、推广甚至自己发明了持续集成、结对编程、自动化测试、持续交付、微服务这些东西：不是因为时髦，是因为它们能帮人把软件做对。

早期的 coding agent 把"产出代码"变得极其容易，包括那些你根本不想让它靠近生产的代码——而且写这些代码的人，还没学过"做出一个东西"和"让它安全地跑在生产里"之间的那道鸿沟。

工具这几年进步巨大，但资深开发者的问题并没有消失，只是变得更具体了：

我们确信这是对的行为吗？
它按预期工作吗？
这些是对的边界吗？
我们还能演进它吗？
它遵守我们吃过亏才学到的那些原则和实践吗？
出错的时候会发生什么？
另一个团队能接手吗？

这些问题串起来，底下压着一个更大的问题：当一个系统从来没有人用这种方式建过，我们能信任它到什么程度？

换个说法更清楚：现在跑在生产里的几乎每一个系统，都是"旧方式"建的——手工、由一群（但愿）可信的人建起来的。而我们现在建的一切都是新方式，我们还没和它一起生活过。

二、判断力是那些人在保护的东西

在技术行业二十五年，Rachel 说她越来越看重人从经验里长出来的判断力。她经常把同一批问题同时抛给模型和 Thoughtworks 的资深技术专家。

结果是：难的问题上，人给出的答案仍然更有用。 有些答案甚至谈不上更"完整"，但它更有洞见——因为它带着非常具体的经验：

质疑前提本身；
从十年前一次事故里认出同一个模式；
在技术问题的壳子里看见那个组织问题。

她说得挺克制：我现在能拿到巨量的信息，但我仍然需要有人帮我想清楚"什么才是重要的"，我仍然需要智慧和洞见。

那种判断力，正是犹豫的资深开发者想保护的东西。

她额外强调了一次边界：这些人不是不肯用编码助手，他们是不肯把执行全交出去；他们不肯把手从方向盘上拿开，是因为没有完全确信 agent 身上的护栏已经到位，能让它自己跑出去。

三、一周白板：没有人写一行代码

欧洲区 CTO Giles Alexander 最近组织了一次实验：把资深工程师、基础设施顾问和产品人员凑在一起，用整整一周、完全按这种方式干活——没有任何人写代码，全部由 agent 建。

实验的目的不是证明"航空应用能在一周内建出来"。顺带说一句，他们做到了 80%——"我们都知道 80% 意味着什么，这真不是编的"。真正的目的是：当 agent 把编码全包了，团队的工作会发生什么变化。

让 Rachel 印象最深的是他们在白板前花了多少时间：把领域想清楚、画出边界、决定下一步该发生什么、把计划做成 agent 能执行的东西。与此同时，agent 一直在产出代码，越过了团队的上班时间还在继续。

人还在设计那套围绕产出的反馈：测试、契约、架构检查、交付流水线。他们在解一道很具体的题：怎么给 agent 足够的自由度让它推进，同时又对结果保持信心。

键盘前的大部分工作，是让 agent 把"这一轮学到的东西"写进 harness（运行框架），这样下一轮构建和测试 agent 就能做对，人也才能对产出的东西更有信心。

最后有个细节特别值得记：产品经理提交的功能代码比团队里任何人都多。

他们估算的时间分配是：约三分之二在白板上，三分之一在 harness 上。 这或许暗示了未来的开发方式会是什么样——但作者马上踩了刹车：在你去重画团队结构之前，故事还没讲完。

四、应用跑起来了，构建是红的

应用能跑。但构建经常是红的。

而且它"在他们的机器上是好的"——这句话你编都编不出来。

Rachel 对这个状态的形容很直接：一个长期飘红的构建让人浑身不舒服。红色应该意味着什么：停下来、查清楚、修掉。 如果它红得太频繁，以至于大家都不再注意它，那下一个真正的失败靠什么被发现？而如果你不再信任这些检查，绿色的构建也不再让人安心。

那正是持续集成本来要消除的那种不确定性，而他们为这件事倡导了超过二十五年。

问题还没解决完，他们给了几种可能：

并行的 agent 太多，各自的改动互相踩？
系统还不够模块化，agent 无法在独立的部分上工作？
还是改动到达的速度本来就快过检查跑完的速度？
又或者以上所有因素叠加，还有别的？

无论哪种，有一件事是确定的：最后一公里的问题需要重新设计。 她判断持续交付 / DevOps 这个运动会在 agent 时代迎来一次复兴和重做，就像研发的其他环节正在被掀翻一样。

而且这不是他们一家的实验。DORA 2025 年的研究发现：AI 的采纳已经和更高的交付吞吐、同时更低的交付稳定性关联在一起。——恰好是持续交付和 DevOps 当年要解决的那件事。

五、连 TDD 和批量大小都要重新问

这些挑战在团队内部也吵出了一些好问题：

当你不再逐行阅读，而且测试是 agent 跟着代码一起写的，测试驱动开发该扮演什么角色？
验收测试、契约测试、系统边界上的检查，放在哪里能带来更多信心而不过于脆弱？
在放 agent 出去干活之前，该做多少设计？既然改一个方案已经这么快。
有没有一个"我们知道过头了"的时点？
最大的谜题之一是批量的大小。她听说很多团队正在从 Story 迁移到 Epic——对开发速度是好事，但你的 CI 流水线能扛住这个工作单元的规模，还能并行、还能快吗？

这个实验团队没能在这一周解决这些问题，也没有在两轮里解决（他们用了两个不同的团队跑了两遍）。她说得很干脆：谁声称解决了，我不会信他。

但这恰恰是她希望资深开发者参与的工作：做实验、质疑，帮我们找出哪些实践还站得住，哪里需要新的实践。

六、离开压好的雪道

跟几位资深开发者聊完之后，她一直在想学滑雪这件事。

小孩常常无所畏惧地直接冲下坡——就像那些从没把软件送上过生产、从没在凌晨三点处理过告警的新手。（她说这件事她永远不会忘，和"我自己造成过的每一次生产事故以及从中得到的教训"排在一起，烙在脑子里。）

而她成年后第一次滑雪时，脑子里想的是"我会摔坏什么"。她想滑，看着又好玩又自由，但她已经大到能看见后果，也不想着断条腿在伦敦一瘸一拐，或者更糟。最大的问题是：她还没学会怎么转弯和刹车——没有这两样，她在雪道上就是一辆失控的列车。

她把草稿给也学滑雪学得晚的 Martin（Martin Fowler）看，Martin 指出这个类比在哪里断掉了（她说自己就爱把类比推到边缘，这个双关是故意的）：

在雪道上，你亲眼见过无数人安全滑到底。 教练在你之前已经在这条道上教过几千人，他们知道哪些技能重要、该怎么教。
而现在的 agentic 开发更像一次穿越未知地带的后山行程。 我们还不知道哪些技能最重要；几乎没人（如果有的话）安全走完过这条路；关于怎么走的反馈，要么很慢，要么根本不存在。

按 Martin 的说法：一个重度由 agent 建起来的系统能不能用，要等它在生产里跑了一段时间、扛过几轮变更、而且没有把我们的飞机全送到阿伯里斯特威斯（威尔士海边小镇）去，才知道。

"建好了"和"在生产里工作"不是一回事。 或者用 Charity Majors 的话说："staging 只是一台体面的笔记本，只有 prod 才是 prod。"——正因为如此，"在我机器上是好的"这句通常是个笑话。至少她每次都笑。

这段对话让她心里那点长期的不舒服落了地：当技术或非技术的领导说"开发者不够好奇""开发者是落后者"，并且把这个归到好指认的恐惧上（怕失去亲手写代码的乐趣——她说她自己也怕；怕丢工作——现在谁不怕），他们看错了对象。

他们最好的开发者不是幼教雪道上紧张的初学者——他们看的是没有标记过的地形，问的是关于路线是否合理的问题。 叫他们"别那么谨慎"，是没听懂这件事。他们应该在画地图的那支队伍里。

当然，经验也会让人过度依恋熟悉的实践：有些在压好的雪道上学到的东西，出了雪道就不成立，所以必须愿意检验自己的假设。

七、两边都有事要做

所以这件事对领导和开发者同时提出了要求。

领导需要听得足够仔细，能分辨"有用的顾虑"和"不愿变化"，并且真的留出实验的空间——那意味着时间、允许出错的许可，以及不要用"agent 产出了多少代码"来判断成功。

开发者则需要把自己的经验带进这些实验，并且准备好发现"自己的一些假设不再成立"。

有些熟悉的实践会变得更重要，另一些需要换个形状。没有人会先递给我们一张地图。

她最后的收尾没有停在祝愿上：如果你真的在意"做对的东西、把它做对"，那你的判断力恰好是这种新工作方式需要的。带着你的谨慎来，然后我们一起进雪地。

八、我们的整理：把"谨慎"换算成可操作的东西

原文最实用的地方，是它把"资深开发者的犹豫"从情绪问题翻译成了工程问题。我们按它的材料整理成三样可以直接用的东西。

一、把这场实验的账摆出来

观察项	原文数字	值得注意的地方
团队时间分配	白板约 ⅔、harness 约 ⅓	编码不再是瓶颈，定义与约束才是
应用完成度	约 80%（两周、两个团队各跑一遍）	作者自嘲"80% 意味着什么大家都懂"
构建状态	应用能跑，构建经常红	红得太频繁 = 检查失去意义
提交最多的人	产品经理	功能代码的作者身份已经和工作职能脱钩
实验规模	1 周 × 2 轮	样本小到只能当方向，不能当基线
外部印证	DORA 2025：吞吐↑、稳定性↓	与持续交付当年要解决的问题同构

（上表按原文数字整理，非原文提供的表格。）

二、把原文那七个问题变成 PR 前的一张单子

那七个问题是给"要不要接受这个系统"用的，落到日常就是下面这张单子。原文的措辞我们保留，判据部分是我们补的：

原文的问题	在 PR 里怎么问	什么答案算过
这是对的行为吗	这段逻辑对应哪条业务规则？谁确认的？	能指到具体需求或规则编号，不是"agent 觉得这样合理"
按预期工作吗	有没有一个能复现的验证？失败时会怎样？	有命令、有输出、有覆盖到的边界输入
边界对吗	它改动了哪些范围外的东西？	diff 里没有范围蔓延、没有顺手重构
还能演进吗	下一个人改这里要读多少上下文？	改动集中、命名可读、没有为通过测试而特化的分支
遵守我们吃过亏学到的原则吗	和我们既有实践冲突的地方为什么可以破例？	破例有记录、有理由、有时限
出错会发生什么	它失败时是静默、重试还是爆炸？	能说清失败模式与回滚路径
别的团队能接手吗	交接需要口述多少东西？	文档/测试能自证，不依赖"当时那个 agent 的上下文"

三、怎么分辨"有用的顾虑"和"抵触变化"

原文把这件事交给领导"听得足够仔细"，这太软了。可以给三条硬一点的判据：

某种程度上可被验证。 有用的顾虑会说"如果 X 成立，我就在这个实验里认输"，它接受被证伪；抵触只会重复立场。
指向具体机制。 "构建长期红会导致真失败被忽略"是可查的；"我觉得不行"不是。
带时限。 有用的顾虑允许"再跑两轮再看"；抵触要求现在就下结论（往往是"现在就别做"）。

反过来，作者也留了一条给谨慎派的自省：经验会让你过度依恋熟悉的实践。 这条判据同样适用于"我们以前都这么做"。

站内几条接得上的线

Claude Code 团队的代码评审：7 层防线怎么搭——这篇讲的是"红线怎么自动化"，与原文"构建长期红"正好互补。
Agent 交付验收：三棵树把"绿"分成七类——当检查本身不可信时，怎么让"通过"重新有含义。
多 Agent 写代码：代码是最简单的部分，协议才是系统——原文里"并行 agent 互相踩"的猜测，这篇给了控制平面与隔离的答案。
AI 编程的未来已经到来，只是分布得极不均匀——同一个现象的宏观版：代码产出涨了，上线的功能没跟着涨。

五条边界，别把这读成"agent 编程不行"

样本极小。 一个组织、两个团队、各一周。作者自己说"谁声称一周解决了这些问题，我不会信他"。它给的是问题清单，不是结论。
80% 是个玩笑级数字。 原文明确拿它开涮（"80% 意味着什么我们都知道"）。别把它当完成度基准引用。
DORA 2025 是转述。 原文只给了一句结论（吞吐↑、稳定性↓），没有给指标口径。要引用就引 DORA 报告本身。
作者立场要说清。 这是一位咨询公司 CTO 在自家博客上的观点文章，实验也发生在同一家公司；"白板 ⅔ / harness ⅓"是团队估的，不是计时测出来的。
"谨慎"不等于"不用"。 原文反复强调这一点：他们天天用编码助手，只是不肯把执行全交出去。把这篇读成"资深开发者抵制 AI"，正好读反了。

来源：Rachel Laycock（Thoughtworks CTO）,《Why are good developers so wary of agentic development?》, martinfowler.com/rachels-ramblings, 2026-10-29。原文链接：https://martinfowler.com/rachels-ramblings/good-devs-wary.html。文中的 DORA 2025 结论、Charity Majors 与 Martin Fowler 的引语均为原文引用；表 1、七问清单的判据列、三类判据与"五条边界"为我们整理，非原文内容。

本文由汇智网编译整理，转载请注明出处。