资深开发者为何对 Coding Agent 仍谨慎：做出来≠能上生产
会用 Coding Agent 的人越来越多，真正把「Agent 写的系统」当生产默认的人仍偏谨慎。Thoughtworks CTO Rachel Laycock 在 Martin Fowler 站点撰文指出：这股谨慎背后，常见的是他们清楚做出来 ≠ 能在生产里长期站住——不只是恋栈手写代码或单纯怕丢饭碗。本文按该文整理生产就绪视角，并收成可执行的审查与护栏清单；不点名任何社交平台讨论。
事实与引述以 Rachel Laycock · Why are good developers so wary of agentic development?（2026-10-29，Martin Fowler 站点）为准。文中 Thoughtworks 内部实验与 DORA 2025 表述均为该文转述，读时可回到原文与 DORA 报告核对。
谨慎护的是判断，不是键盘手感
Laycock 写：优秀开发者通常最先试新工具，却对「全面 agentic」仍犹豫。懒答案是「他们爱写代码」或「怕失业」；更深处的问题是一长串生产问题——行为对不对、边界对不对、明年还能不能改、故障时谁能接住、别的团队能不能与之共处。几乎所有现网系统仍是「旧方式」做出来的；用 Agent 大包大揽的系统，人们还没真正长期与之相处。
她区分得很清楚：他们犹豫的是「把手从方向盘上拿开，让 Agent 独自跑完全程」；「用不用编程助手」通常已经不是争论点。助手加速打字是一回事；缺少护栏的自主执行是另一回事。经验带来的判断——挑战前提、认出十年前的坑、看见技术问题里的组织问题——正是他们想保住的东西。
Built is not the same as working in production. 能跑起来，只说明今天的演示过关，不说明变更、故障与协作压力下还能站住。
实验里：三分之二白板，三分之一 harness
文中记述一次把执行端推到极限的实验：人不写业务代码，全部由 Agent 构建。团队大量时间花在白板上——领域、边界、下一步计划——同时设计反馈：测试、契约、架构检查与交付流水线，再把学到的写进 harness，让下一轮构建与测试 Agent 更靠谱。估算大约三分之二时间在白板，三分之一在 harness；有意思的是，产品同学最终提交的功能代码反而最多。
应用能跑，构建却经常红。持续红灯会腐蚀信号：大家开始无视失败，真故障也就淹没了；绿灯也不再让人安心。这正是持续集成当年要消除的不确定性。并行 Agent 互相踩改动、模块边界不够清晰、变更速度快过检查完成，都可能叠加。Laycock 转述 DORA 2025 的观察：AI 采用与更高交付吞吐相关，也与更低交付稳定性相关——吞吐与稳定再次被撕开，持续交付 / DevOps 在 agentic 时代可能要重估，而不是宣布过时。
做出来 ≠ 能上生产：把缺口写清楚
滑雪比喻在文里被推到极限后又被纠正：有教练的雪道上，你见过很多人安全滑到底；agentic 开发更像未知野地——哪些技能最重要尚未共识，安全走完全程的样本很少，反馈又慢。在系统真正跑过一段时间、扛过几轮变更之前，没人有资格说「Agent 重写的系统已经证明自己」。Staging 不是生产；「在我机器上能跑」从来只是段子。
因此，把「生成了一大坨能编译的代码」当成完成，会系统性地低估：
- 正确性与边界：验收标准是否可执行；跨服务契约是否被测试钉住。
- 演进能力：模块是否允许并行修改；批大小是否大到 CI 扛不住。
- 失败可观测：红灯是否仍有人停下来修；回滚路径是否演练过。
- 所有权：谁对生产行为负责；Agent 轨迹能否复盘。
让 Agent 产出可审查、可上线的实践
结合该文论点，以及站内已写过的客观审查与完成证据取向，收成一份生产向清单（本文不重复展开「客观 vs 主观审查」或「截图当完成证据」专文）：
- 先定行为与边界，再放 Agent。白板与规格不是仪式，是给 Agent 可执行的约束；没有约束的「史诗级工单」只会制造巨大 PR 与红灯。
- 把反馈写进 harness，而不是写进下一次口头叮嘱。测试、契约、架构检查、流水线门禁，应成为下一轮 Agent 默认碰到的墙。
- 分开「助手加速」与「自主执行」权限。读写仓库、改基础设施、碰密钥与生产数据，用分级审批；不可逆动作默认人工确认。
- 要求可复查产物。除代码外，保留决策摘要、失败轨迹、关键路径的验证记录；合并前能回答「怎么知道它做对了」。
- 盯稳定性指标，不只盯吞吐。变更失败率、恢复时间、红灯持续时间，应与「Agent 产出行数」一起看。
- 批大小与并行度要匹配 CI。文中提到有团队从 Story 扩到 Epic；速度上去时，先问流水线能否在并行下给出可信信号。
- 让有生产伤疤的人进实验组。领导者要分辨「有用的谨慎」与「拒变」；开发者则要把经验带进实验，并准备好部分旧假设会被推翻。
和站内相关文怎么分工
- 客观 vs 主观代码审查：人扫方向与品味，Agent 做可机器核对项。
- 完成证据：录屏 / 截图 / 可复现验证，避免「自称做完」。
- 本文：生产就绪层面的谨慎理由——做出来为何不够，以及白板、harness、CI 信号如何一起设计。
常见坑
- 用产出代码量衡量试点成功。文中明确反对只看 Agent 写了多少。
- 红灯常态化。信号失灵后，绿色也不再代表安全。
- Agent 自测自写却无人抽检。TDD、契约测试、边界检查的角色需要重估，不是自动作废。
- 把谨慎打成「落伍」。在未知地形上要的是制图队，不是只会催油门的口号。
完成标准
- 能用自己的话解释：为何「会跑」仍不足以宣布生产就绪。
- 能列出至少四条让 Agent 产出可审查 / 可上线的具体做法。
- 能说明白板时间与 harness 投资如何变成可复查的信任来源。
最后
若你带团队试点 Coding Agent，把成功标准从「这周生成了多少」改成「红灯是否仍可信、变更是否更稳、故障是否可复盘」。谨慎更像野地里该有的地图工作，不是刹车失灵；带上它，再出发。
