> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 代码能跑 ≠ 系统能用：好开发者为什么对 Agent 开发更谨慎 - URL: https://www.hubwiz.com/blog/good-developers-wary-agentic-development/ - Published: 2026-10-30T14:33:11.000Z - Updated: 2026-10-30T14:34:02.000Z - Description: 一个团队两周的实验：没人写代码，全交给 agent。结果是 ⅔ 时间耗在白板、构建长期飘红，而最谨慎的那批人其实说对了。 - Author: admin - Tags: AI 编程, Agent, 软件工程, 持续集成, Vibe Coding 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 的上下文" | **三、怎么分辨"有用的顾虑"和"抵触变化"** 原文把这件事交给领导"听得足够仔细"，这太软了。可以给三条硬一点的判据： 1. **某种程度上可被验证。** 有用的顾虑会说"如果 X 成立，我就在这个实验里认输"，它接受被证伪；抵触只会重复立场。 2. **指向具体机制。** "构建长期红会导致真失败被忽略"是可查的；"我觉得不行"不是。 3. **带时限。** 有用的顾虑允许"再跑两轮再看"；抵触要求现在就下结论（往往是"现在就别做"）。 反过来，作者也留了一条给谨慎派的自省：**经验会让你过度依恋熟悉的实践。** 这条判据同样适用于"我们以前都这么做"。 **站内几条接得上的线** - [Claude Code 团队的代码评审：7 层防线怎么搭](https://www.hubwiz.com/blog/claude-code-team-code-review/)——这篇讲的是"红线怎么自动化"，与原文"构建长期红"正好互补。 - [Agent 交付验收：三棵树把"绿"分成七类](https://www.hubwiz.com/blog/agent-delivery-verification-gates/)——当检查本身不可信时，怎么让"通过"重新有含义。 - [多 Agent 写代码：代码是最简单的部分，协议才是系统](https://www.hubwiz.com/blog/multi-agent-coding-workflow-identity-isolation-review/)——原文里"并行 agent 互相踩"的猜测，这篇给了控制平面与隔离的答案。 - [AI 编程的未来已经到来，只是分布得极不均匀](https://www.hubwiz.com/blog/ai-coding-velocity-feature-gap-essential-complexity/)——同一个现象的宏观版：代码产出涨了，上线的功能没跟着涨。 **五条边界，别把这读成"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](https://martinfowler.com/rachels-ramblings/good-devs-wary.html?ref=hubwiz.com)。文中的 DORA 2025 结论、Charity Majors 与 Martin Fowler 的引语均为原文引用；表 1、七问清单的判据列、三类判据与"五条边界"为我们整理，非原文内容。 本文由汇智网编译整理，转载请注明出处。 > **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)