- 发布日期
为什么优秀开发者对 Agentic Development 保持谨慎？
- 作者
- 姓名
- Shoukai Huang
- 身份
- Software Architect · Indie Developer
很多团队正在尝试让编码 Agent（coding agent）承担更多软件开发工作：理解需求、修改代码、运行测试，甚至连续工作到人类团队下班之后。代码产出速度因此显著提升，但一个问题也随之变得更尖锐：代码被构建出来，不等于系统已经能够在生产环境中可靠工作。
Rachel Laycock 在《Why are good developers so wary of agentic development?》中讨论了一个容易被误读的现象：一些最有经验、最愿意尝试新工具的开发者，反而没有准备“all in”，把全部执行权交给 Agent。
这并不只是因为他们喜欢亲自写代码，也不能简单归结为担心工作被替代。更深一层的原因是，他们知道生产软件的难点从来不止是把功能写出来。
从“生成代码”到“交付软件”
经验丰富的开发者通常同时关心两件事：是不是在构建正确的东西，以及是不是以正确的方式构建它。后一个问题包含许多不容易在演示中看出来的要求：系统是否符合真实需求，边界是否清楚，行为是否可验证，代码能否在明年继续演化，故障发生时是否能够恢复，另一个团队接手后是否还能维护。
早期编码 Agent 很容易生成大量代码，其中也包括不应进入生产环境的代码。工具本身已经快速进步，但这并没有自动消除经验开发者的疑问：
- 这是正确的行为吗？
- 它真的按预期工作吗？
- 模块边界是否合理？
- 测试和检查能否给出足够可信的信号？
- 系统出了问题，谁能理解并修复它？
这些问题共同指向一个更大的未知：当团队还没有长期运行过这种方式构建出来的系统时，究竟能对它有多大信任？
因此，需要区分“使用编码助手”和“让 Agent 负责全部执行”。前者可以是能力增强；后者则意味着团队要把更多判断、反馈和责任边界放进一套尚未经过充分生产验证的工作方式中。
人类的工作没有消失，而是转移了位置
Laycock 描述了一次把 Agentic Development 推到极限的实验：团队成员不直接写代码，应用的代码全部由 Agent 生成。实验的目的不是证明一周能否完成一个航空应用，而是观察当 Agent 负责全部编码时，团队的工作究竟变成什么样。
一个很有代表性的结果是，人类花了大量时间在白板前：
- 理解领域问题；
- 划分系统边界；
- 决定下一步应该做什么；
- 为 Agent 制定可以执行的计划；
- 设计测试、契约、架构检查和交付流水线。
与此同时，Agent 可以在团队工作时间之外继续生成代码。人的键盘操作减少了，但人的判断并没有消失。相反，很多判断被转移到了 Agent 周围的 harness（执行与反馈护栏）里：把团队已经学到的约束写进测试、契约和检查，让后续构建和测试 Agent 在下一轮执行时更容易得到可信结果。
这带来一个值得注意的变化：Agentic Development 的生产力，不应只用“Agent 写了多少代码”衡量。更重要的问题可能是，团队是否建立了足够快、足够清晰、足够可信的反馈机制，让 Agent 的自由度不会变成系统的不确定性。
“应用能运行，但构建常红”
实验中出现了一个刺眼的现象：应用能够运行，但构建经常是红色的。也就是说，它在某些环境中看起来能工作，却无法让持续集成流程持续给出可靠的通过信号。
这不是一个可以轻易忽略的小瑕疵。自动检查的价值在于：红色意味着应该停下来调查和修复；绿色意味着在既定检查范围内可以继续前进。如果构建长期频繁变红，团队可能逐渐不再关注红色；而当红色失去信号价值时，绿色也就不再令人安心。
原文提出了几种可能原因，但没有把其中任何一种定为最终结论：是不是太多 Agent 并行工作、互相覆盖了修改？系统是否还不够模块化，无法让 Agent 在相互隔离的部分工作？变化是否已经快到超过检查的处理速度？也可能是这些因素叠加在一起。
重要的不是替某个实验寻找一个简单归因，而是看到反馈系统在 Agentic Development 中的地位发生了变化。人类手工写代码时，许多上下文会停留在开发者的经验和判断里；当代码由 Agent 大量生成时，团队必须把更多上下文显式化，并让检查系统能够及时验证这些约束。
这也解释了为什么持续交付和 DevOps 可能需要在 Agent 时代重新思考。并行度更高、批次更大、变化更快，并不自动带来更稳定的交付。相反，交付流水线、模块边界、测试类型和故障恢复都可能成为新的瓶颈。
经验开发者面对的不是一条已经铺好的雪道
Laycock 用滑雪作了一个很形象的类比。第一次滑雪的成年人往往会先想：如果不会转弯和停止，自己可能会变成失控的列车。孩子则可能更愿意直接冲下坡。
但她也指出，这个类比有明显边界。成熟的滑雪场有教练、已有路线，也有大量人安全抵达终点的经验。Agentic Development 更像穿越一片未知地形：团队还不知道最重要的技能是什么，也没有足够多的长期生产反馈来证明一套做法已经安全可靠。
所以，“它在我的机器上能运行”并不能回答系统是否真的可靠。一个由 Agent 大量构建的系统，至少需要经过一段生产运行，经历多轮变化，并在真实压力和故障中证明自己没有持续制造新的问题。构建完成是一个阶段，不是最终证据。
这并不意味着经验永远正确。过去在成熟工程实践中形成的部分习惯，可能不适合新的工作方式；团队需要愿意检验自己的假设。但“需要重新学习”与“可以忽略经验”是两回事。经验开发者所看到的风险，恰恰可以帮助团队设计更有价值的实验。
谨慎与实验并不矛盾
这篇文章对管理者和开发者都提出了要求。
对管理者来说，首先要区分两类情况：一种是缺乏证据的拒绝变化，另一种是基于生产经验提出的具体担忧。后者不能靠“再大胆一点”解决。团队需要真实的实验空间，包括时间、允许失败的条件，以及不以 Agent 产出代码量作为唯一成功标准的评价方式。
对开发者来说，经验也不应成为拒绝新方法的永久理由。更有价值的做法是把经验带进实验：明确哪些边界必须保留，哪些检查能够提供信号，哪些旧实践可能只是历史条件下的产物，然后接受实验结果对这些假设的修正。
换句话说，谨慎不是 Agentic Development 的反面。无条件交出方向盘当然可能过于乐观，但只站在路边批评未知地形也无法帮助团队找到路线。真正有建设性的谨慎，应该转化为可验证的约束、可观察的反馈和可以逐步扩大范围的实验。
结语
优秀开发者对 Agentic Development 的谨慎，核心并不是“他们不想使用新工具”，而是他们知道软件交付中最难的部分通常发生在代码生成之后：确认行为是否正确，边界是否清楚，检查是否可信，故障是否可恢复，以及系统能否在持续变化中保持可维护。
这也是为什么“构建出来”和“在生产中可靠工作”必须被分开讨论。Agent 能够改变开发工作的速度和分布，但它不会自动替团队承担领域判断、系统责任和生产反馈。
因此，团队真正需要探索的，不只是如何让 Agent 写更多代码，而是如何让它在足够清晰的边界、足够及时的检查和足够真实的生产反馈下工作。经验开发者的谨慎，应该成为这张新地图的起点，而不是被消除的障碍。
来源：Rachel Laycock，《Why are good developers so wary of agentic development?》
延伸阅读：