好开发者为何对 Coding Agent 仍保持警惕？
做出来 ≠ 能上生产！来自 @rachellaycock 的分享：
https://www.martinfowler.com/rachels-ramblings/good-devs-wary.html
Rachel 发现很多一向爱尝新、甚至自己发明工具与实践的资深开发者，对 agentic development 反而谨慎。简单归因（爱写代码、怕失业）对一部分人成立，但她觉得背后还有别的东西。九月 Technology Radar 开放讨论把 agent 推到极限后，她把那层担心看清了。
Thoughtworks 一向强调「做对的事、把事做对」：能用、明年还能改、生产里不倒。持续集成、结对、自动化测试、持续交付、微服务等，正是因此被他们早早采纳或推动。早期 coding agent 很容易产出「根本不该靠近生产」的代码，开发者未必懂「做出来」和「安全跑起来」之间的鸿沟。工具进步很大，但资深开发者仍在问：行为对不对？边界对不对？能不能演进？失败时怎么办？别的团队能不能接手？更大一层是，用这种方式建系统，我们还几乎没有长期生产经验。今天线上绝大多数系统仍是旧方式、由人亲手做出来的；新方式还没被真正「住」过。
她强调：这些人不是拒绝助手，是拒绝把手完全从方向盘上拿开；还没看到足够护栏，不敢让 agent 独自狂奔。
一次白板实验
欧洲区域 CTO Giles Alexander 带资深工程师、基础设施顾问和产品同学做了一周实验：人不写代码，全部交给 agent。目的不是证明一周能做出航空类应用（他们做到约八成，作者自嘲「你懂那意味着什么」），而是观察「编码全交给 agent 后，团队工作变成什么样」。
她印象最深的是：人大部分时间在白板，理清领域、画边界、定下一步、给 agent 可执行的计划；agent 则在下班后仍继续吐代码。人还在设计反馈回路：测试、契约、架构检查、交付流水线，并把学到的东西写进 harness，让下一轮构建与测试更稳。有趣的是，最后提交功能代码最多的反而是产品同学。他们粗估：约 2/3 时间在白板，1/3 在 harness，这或许暗示未来分工，但她立刻泼冷水：故事还没讲完。
应用能跑，构建却常红
应用能跑，但构建经常红，「在我机器上能跑」又回来了。常红的构建会麻木告警：红不再等于「停下、查、修」；检查不可信时，绿也不再让人安心。这正是持续集成本想消除的不确定性。原因可能是并行 agent 互相踩改动、系统还不够模块化、变更比检查跑得更快，或几者叠加。她认为持续交付 / DevOps 会在 agent 时代迎来一轮重审；DORA 2025 也写到：AI 采用与更高吞吐相关，却与更低交付稳定性相关。
内部还在吵：人不逐行读代码、测试又和代码一起由 agent 生成时，TDD 扮演什么角色？验收、契约、边界检查怎样给信心又不脆？开跑前要做多少设计？批次该多大，很多团队从 Story 扩到 Epic，CI 跟不跟得上？实验跑了两轮也没给完答案；她更希望资深开发者参与这种实验，弄清哪些旧实践仍站得住、哪里需要新实践。
滑雪比喻（以及它哪里不够）
她把新手比作小孩毫无顾忌冲下山；资深开发者像成年才学滑雪的人——知道摔断腿的代价，还没学会转弯和刹车。Martin Fowler 指出比喻的破绽：雪道上有无数人平安到底、教练教过上千人；Agent 开发更像未知野地：还不知道哪些技能最关键、几乎没人安全走完全程、反馈又慢又少。系统是否真行，要等它在生产里跑一阵、扛过几轮变更、别把飞机全派到 Aberystwyth，做出来 ≠ 生产里能工作。Charity Majors 那句也被点到：staging 只是「高级笔记本电脑」，只有生产才是生产。所以领导把谨慎说成「不好奇、落后」，往往看错了对象：这些人不是在人人都会的初级雪道上发抖，而是在看未标地图，问路线合不合理。
对两边的挑战
领导要分清「有用的担忧」和「单纯抵触变化」，给真实实验空间：时间、允许犯错、别用「agent 产出了多少代码」当成功标准。开发者要把经验带进实验，也准备好承认有些旧假设不再成立。有的实践会更重要，有的要换形状；没人会先递一张现成地图。若你在意做对、做稳，这种谨慎正是新工作方式需要的，带着警惕出发。