编程一度是软件开发里最难、也最贵的部分：接到一个需求，先要有人理解它，然后设计、编码、测试、调试、审查，最后部署。到了 2026 年，编码 agent 写出了大部分代码——测试、重构、排查 bug——而且每天都在进步。一年前做不到的事，现在成了常规操作。
这意味着一个反转正在发生：代码正在从软件工程里最贵的部分，变成最便宜的部分。 软件工程师仍然会被需要，但价值会流向代码之外的环节。
在 What is the future of Software Engineering when nobody needs to write code 里，Dr Milan Milanović 给出了九个具体判断，指向同一个方向：当生成代码不再稀缺，稀缺的是判断。 下面的解读保留了他的论证与证据，把九个点重组为一条主线，并补上可以直接执行的检查清单。
代码从来不是产品
作者在职业观察里发现：做软件的人经常把编程和软件工程当作同一件事，过去也基本成立，因为编程占据了我们绝大部分工程时间。但顾客并不关心系统里有多少行代码，他们关心的是：系统是否解决了问题、是否正常工作、数据是否安全、能否随业务演进。
企业雇工程师从来不是为了代码本身，而是为了增加收入、降低成本、降低风险——代码只是达成目标的工具。当 agent 把实现变得又快又便宜，难题就转移到产品开发流程的另一侧：做什么、需求到底指什么、接受哪些取舍、系统该如何表现、如何判断实现符合需求、谁对结果负责。 这些问题大部分无法交给 AI，因为它们需要人的判断。这个区分也体现在《Software Engineering at Google》书中的「编程 vs 软件工程」配图上——原文引用了它来支撑这个边界。
硬的部分：从写代码转向判断
过去一年很多团队的行数暴涨，有人会说这是生产力提升。作者反而不这么看：大多数公司需要的是更好的结果，而不是更多的代码。最好的反证是——过去两年我们没见到什么重大软件问世（除了 AI 工具本身）。代码变多意味着需要被理解、审查、保护、部署、监控和维护的东西变多，而理解复杂度是有限度的。如果系统其他部分不改善，更多代码只会让组织变慢。
所以约束变了：以前是「我们能多快手工造出软件」，现在变成「我们能多快决定真正要造什么、证明它有效、拿到用户反馈」。软件工程从产出问题变成判断问题，反馈循环越短，产品越好。
规格成为真正的编程
可以把编程理解为翻译：把一份对某事物的不完整描述，翻译成计算机能执行的精确指令。AI agent 擅长执行那一半，不擅长翻译那一半。
举个例子，原文用了一个需求：让高级客户更快提现。
交给人类，会引出大量未回答的问题：什么算高级客户？规则是否适用于已经在处理中的提现？客户失去高级状态后，原本排队的提现怎么办？交给 AI agent，它多半会自行假设——并且在这个过程中犯错。作者的建议是：在 AGENTS.md 或 CLAUDE.md 里明确要求 agent 不要猜，先问。
更深一层的问题在于：同一个需求，在不同的公司会得到不同的系统。初创公司和一家有数百万账户、需要合规审查的银行，会把「更快提现」实现成完全不同的东西。而决定差异的是这个公司过去发生过什么——事故记录、合同、预算、时间线。这些语境 agent 不可能知道。
于是结论是：实现变便宜了，规格却占了更多工程工作量。最好的工程师，将是那些能把模糊请求变成显式规则、不变量、接口、验收标准，并在该提问时提出关键问题的人。在 agent 时代，规格编写就是更高抽象层次上的编程。
验证比生成更难
从 2025 年 11 月的 Opus 4.5 开始，agent 生成的代码质量已经相当好（原文的说法）。但验证它的正确性做不到这么快，人工逐行审查所有生成的代码也不再现实——我们需要能随 agent 规模扩展的验证形式：测试、静态分析、架构约束，甚至让形式化规格走向主流。
作者列举了他们 .NET 服务里的做法，agent 写出的代码要合并，必须通过四道门禁：
- 构建与分析器。 每个项目在 CI 中打开 warnings-as-errors、Roslyn 分析器和
.editorconfig规则，让人看到错误之前在机器那里就拦住。 - 测试。 单元测试与集成测试（依赖用 Testcontainers），覆盖率设到 60–80%。
- 架构测试。 用 ArchUnitNET 写规则：层边界变化、不该出现的项目引用，直接失败。
- 安全与依赖扫描。 SonarQube 质量门禁检查每个 PR 的依赖。
代码审查的对象也随之改变：不再检查每一行生成的代码，而是聚焦架构、意图、测试、风险与自动化检查的结果。逐行审查完全可以交给另一个模型——用 Opus 5 写的代码，可以请 GPT-5.6 Sol 或 CodeRabbit 这类工具来审。判断标准从「代码写得好不好」变成「我们是否有证据证明系统按预期行为」，而因为代码量巨大，证据必须来自机器。
但要记住门禁的边界：它们只能证明代码通过了检查，不能证明团队真的理解它。 明天生产环境出事，总得有人知道怎么处理。作者团队的做法是放慢一点：小步迭代，先人工审查 PR，再用 AI 工具过一遍。
架构成为约束 agent 的控制机制
也许以后我们真的不逐个审代码了，但系统架构和边界必须自己掌握。agent 不知道我们的意图，也不该替我们决定——最终为结果负责的是人。
把边界定义清楚之后，在边界内工作的 agent 不容易造成伤害：接口、职责、依赖这些关键参数都已被规定。反过来，如果边界缺失，agent 很容易产出「大泥球」。过去架构主要服务于理解和描述系统，现在多了一个用途：它是约束 agent 的控制机制。 好的架构能告诉代码该改在哪里、依赖什么、遵守哪些规则。当我们造软件的速度越来越快，这些约束就越有价值。
同样重要的是，架构决策都是取舍。加缓存降低延迟，还是走异步解耦引入新的失败模式？复杂度并不会消失，只是被挪到别处。设计师要决定复杂度该放哪里——如果让 agent 代替这个决定，就没人知道复杂度在哪，也不知道放在项目语境里是否合适。
组织会怎么变：junior、团队规模、技术债
三个关于人的变化值得单独看。
Junior 培养是当前最大的担忧之一。 过去的工作流是：实现一块代码、在调试与代码审查中学习，经验与判断就是这样积累的。如果 agent 包揽了实现，junior 就失去了这条路径——只看别人如何实现，无法建立判断力，因为最好的学习发生在「出问题了、需要调试」的时候。原作者的解法是缩短纯学习期：更早给 juniors 真实责任，比如一个小系统、一个可以直接对话的客户，让他们更快获得所有权并学会负责。juniors 还有一个优势：他们不需要卸载旧习惯，一开始就站在当前技术状态上。
团队可能变小，但范围变大。 过去理想团队 3–9 人，现在两位资深工程师协调多个 agent 就能顶替过去更大的团队。大团队本来就不是好主意——Ringelmann 效应解释了为什么成员越多、协调成本越高、每个人的产出越少。但这不是说我们会需要更少的工程师：当生产成本降低，通常会创造新的需求，这就是 Jevons 悖论——资源变便宜，总消耗反而增长。软件变便宜之后，公司会建更多内部工具、定制工作流、个性化产品与实验，GitHub 上合并 PR、提交与新仓库的月度数据都在增长（原图出处）。问题会从「一个应用需要几个工程师」变成「一个团队能拥有几个系统」。
技术债可能爆炸。 过去一个功能要估工时、讨论值不值得做——如果价值不高却要半个团队三周，我们可能就不做了。现在同样的东西三小时就出来了，于是更多想法落地、更多实验留在线上，更多服务、依赖与基础设施需要维护。每个单独决定都很便宜，但积累起来系统就越来越贵——更便宜的代码，会造出更昂贵的软件。
与之相关的还有认知债。当我们把思考交给 AI、拿到输出却理解不了它（有人认为这是认知投降），系统一旦崩溃我们仍然要负责，而且脱离 agent 的帮助甚至无法修复。ACM Queue 的 From Technical Debt to Cognitive and Intent Debt 把这类问题归入认知债的范畴。解法并不复杂：只部署你能理解的代码——至少在高层次上能回答关于它的问题。 如果不能，就是在继续给项目加债。这里又回到判断：该问的不只是「这个软件好不好造」，而是「这个软件该不该存在」。
最有价值的工程师，可能一行代码都不写
回到开头的问题：软件工程师等于程序员吗？想象五年后一位优秀工程师的一天：理解业务领域、与用户一起把模糊需求变成精确的系统行为、选择合适的架构；然后 AI agent 实现代码，工程师评估输出、审查、选择方向；agent 继续写完剩下部分、写测试、检查安全、完成部署；生产遥测再反馈回来，精炼规格，进入下一轮。
这位工程师几乎不写代码，但技术上并没有变弱——他需要深入理解领域与系统、做出正确决策、为结果负责。技能集从「编程」移动到「理解问题、做好决策、设计系统、构建验证正确性的方式」。作者一直提醒开发者不要把身份绑定在某个语言或框架上，因为技术会变、解决问题的思路不会——agent 让同一条真理延伸到「代码」本身。
一句话总结：代码变容易了，但工程判断没有。
现在就能做的四件事
以上判断如果成立，下面四项可以直接开始：
- 挑一条真实需求，写成显式规格。 把「让高级客户更快提现」这种描述，拆成「谁算、涉及哪些状态、降级怎么办」的可答问题，写进任务说明；再在
AGENTS.md/CLAUDE.md里加一条：不确定就提问，不要假设。 - 为 agent 画出边界。 明确接口、职责、依赖清单与禁止的项目引用，并把这些写成 ArchUnitNET 规则——agent 越界时让构建失败，而不是事后再发现。
- 组装验证门禁。 CI 中 warnings-as-errors + 分析器，测试加覆盖率（60–80%），安全与依赖扫描进质量门禁。审查时只读意图、测试与自动化证据，不再逐行读生成代码。
- 做一次认知债盘点。 对最近由 agent 完成的功能，把「我能不能在高层次上解释它」当作合并条件；同时给团队里的 junior 一个真实负责的小系统。
最后记住边界：agent 无法替代的，是两类判断——对「过去」的判断（公司里事故、合同、预算、时间线构成的选择语境），和对「结果」的责任。这两者恰恰是软件工程师在 agent 时代最值钱的部分。
Aide Hub 会继续分享 AI 助手、开发工具与软件工程实践中的具体做法。