现在用 Codex、Claude Code 这类编程 Agent，最容易产生一个错觉：代码来得太快，软件好像也跟着变便宜了。
David Breunig 最近写了一篇《10 Lessons for Agentic Coding》。有意思的地方不在于又夸模型会写代码，而是把问题往后推了一步：当前沿模型已经能大量生成可用代码，开发者到底还贵在哪里？
答案不浪漫。
贵在意图，贵在测试，贵在品味，贵在维护，贵在出事之后有人负责。
十条经验，指向同一个变化：代码便宜了，反馈更贵了
这篇文章面向的不是围观 AI 的人，而是已经在用 AI 编程工具的人：开发者、技术负责人，以及想靠 Agent 提升工程效率的团队。
Breunig 的十条经验可以压缩成一张表：
| 经验 | 含义 | 真正指向 |
|---|---|---|
| implement to learn | 先实现，再理解问题 | 探索成本下降，别把想象当设计 |
| rebuild often | 经常重建 | 代码不再神圣，行为才是资产 |
| end-to-end tests | 用端到端测试盯产品行为 | 给重写和重构上护栏 |
| document intent | 记录为什么这么做 | Agent 需要上下文，不只需要代码 |
| keep specs in sync | 让规格持续更新 | 旧文档会把模型带偏 |
| find hard stuff | 找出真正难的部分 | 别把时间耗在样板活上 |
| automate easy stuff | 自动化容易的部分 | 把人力留给边界、架构和判断 |
| develop taste | 培养品味 | 好坏判断会决定产出上限 |
| agents amplify experience | Agent 放大经验 | 资深开发者更会少走弯路 |
| maintenance/security aren’t cheap | 维护和安全不便宜 | 债务会生成得更快 |
关键转折很简单：代码本身变便宜，不等于软件开发整体变便宜。
以前写代码慢，很多问题会被“产能不足”挡在门外。现在 Agent 能把半成品、试验品、替代实现迅速铺出来，团队会更早碰到硬问题：哪个行为才是对的？测试能不能兜住？规格有没有过期？半年后谁维护？
代码像水一样涌出来时，堤坝就变得更重要。
受影响最大的，是两类人：写代码的人，管工程债的人
对正在用 AI 编程工具的开发者，这件事的动作很具体。
不要只练“怎么让 Agent 多写一点”。更该练的是怎么拆边界、写验收条件、补端到端测试、把意图写进文档。以后差距不一定体现在谁敲得快，而是体现在谁能让 Agent 少跑偏、少返工、少埋雷。
对技术负责人，判断更硬一点。
如果团队的测试很薄、规格常年失真、代码评审只看风格，那就别急着把 Agent 当效率药。它会让产出变快，也会让坏设计、重复实现和安全隐患变快。引入 Agent 之前，至少要把三件事钉住：
| 决策点 | 不该只看 | 更该先补 |
|---|---|---|
| 要不要大规模引入 Agent | 生成速度 | 测试覆盖和验收标准 |
| 要不要减少人工评审 | 代码能否运行 | 行为是否正确、边界是否清楚 |
| 要不要让 Agent 接复杂任务 | 模型回答是否顺 | 规格是否同步、责任人是否明确 |
我不太买账“程序员马上被取代”这类说法。它太省事，也太偷懒。
Breunig 这十条经验反而说明，Agent 放大的不是无经验者的魔法，而是有经验者的判断。资深开发者知道怎么描述问题，怎么切边界，怎么避免模型在无关路径上乱逛。提示词里那些看似普通的词，背后往往是多年踩坑换来的压缩知识。
端到端测试会变重要，也是这个原因。
Agent 让你更敢重写、更敢 fork、更敢做试验。但你必须有一套行为契约，告诉系统：只要结果没坏，里面怎么换都行。没有测试，快速重建就是快速赌博。
规格文档也一样。
过去很多团队把 spec 当开工前的仪式，写完就冻住。Agent 时代这样不够。实现会暴露新决策，测试会逼出新边界，规格必须跟着代码和测试一起长。否则 Agent 读到的是旧地图，走出来的自然是歪路。
“天下熙熙，皆为利来。”工具厂商会讲效率，团队也会想用更少人做更多事。这没什么稀奇，商业世界本来如此。
但效率叙事最容易藏起后半句：谁来验证，谁来维护，谁来承担安全后果？
接下来别只看写得快不快，要看债务是不是也在加速
Agentic coding 真正危险的地方，不是它写不出代码，而是它太能写代码。
样板代码、胶水逻辑、普通 CRUD、常见重构，都会变快。管理者很容易误判：既然产出速度上来了，项目复杂度也被消灭了。
没有。
复杂度只是换了地方。它从“怎么写出来”，迁移到“写出来之后怎么证明它对、怎么让它长期不坏、怎么让用户真的能用”。性能、韧性、安全、系统架构、直觉化设计，这些才是硬骨头。
任何人都可以让 Agent 做容易的部分。难的部分不会因为模型会补全代码就自动消失。
历史上基础设施扩张常常如此。铁路铺开之后，稀缺的不是铁轨本身，而是调度、维护、财务纪律和事故治理。这个类比不完全一样，但结构相近：生产工具变强，会让治理能力的短板更刺眼。
所以接下来真正该观察的，不是某个团队能不能用 Agent 多写 30 个文件。这类数字很容易好看。
更该看四个现实变量：
| 观察点 | 说明 |
|---|---|
| 端到端测试是否跟上 | 没有行为护栏，重写越快风险越大 |
| 规格是否持续同步 | Agent 依赖上下文，旧文档会制造新错误 |
| 评审标准是否改变 | 不能只审代码风格，要审意图、边界和风险 |
| 维护和安全责任是否明确 | 代码可以生成，事故不能外包给模型 |
这也是我更愿意把 Breunig 这篇文章看成一份提醒，而不是一份技巧清单的原因。
Agentic coding 不是让工程纪律过时。它是在逼工程纪律更早、更硬、更可验证。
未来更便宜的是代码行数，不是判断力；更快生成的是实现，不是责任。