编程不再是软件开发最难的环节
过去，写代码大概是软件开发中最困难的事——不仅难，还贵。一项功能从需求理解、设计、编码、测试、调试、评审到上线，环环相扣，消耗大量人力。如今已是 2026 年，AI 编程代理承担了大部分编码、测试、重构和缺陷排查工作，而且每天都在进步。一年前我们能做到的事，和今天比起来，差距已是天壤之别。
如果这一趋势持续下去，编程很可能从软件开发中最昂贵的环节，变成最廉价的环节。软件工程师依然不可或缺，但纯编码工作的价值占比将让位于其他能力。
代码从来不是产品
从业过程中我发现，许多人把「编程」和「软件工程」混为一谈——这在不久之前还算成立，因为编码确实占据了工程师大部分时间。但二者其实不是一回事。客户购买的从来不是代码行数，而是问题被解决、系统稳定运行、数据安全、随业务演进的能力。 这并非新发现，企业雇用工程师的目的始终是增加收入、降低成本、规避风险，代码只是达成这些目标的工具。只不过在此之前这只是职业建议，如今已变成对工程师工作的真实描述。
当 AI 代理能快速完成实现时，困难的部分转移到软件生命周期的其他环节：我们需要解决的问题变成了 AI 无法替代的——做什么、需求意味着什么、接受哪些权衡、系统应该如何表现、如何验证实现是否符合需求，以及最终谁为结果负责。 这些问题大多无法靠 AI 解决，因为它们需要人类判断。
价值重心从编码转向判断力
过去一年，许多团队的代码产出量大幅增长，有人因此声称生产率提升了。但现实并非如此——大多数公司需要的不是更多代码，而是更好的结果。最好的证明就是：这两年我们并没有看到什么令人眼前一亮的新软件诞生（AI 工具除外）。
实际上，代码越多，意味着需要理解、评审、安全加固、部署、监控和维护的软件也越多。团队的极限在于能处理多复杂的系统。如果其他环节不随之提升，代码越多，组织反而越慢。
长期以来，我们的主要瓶颈是「人肉写代码能多快」，而现在瓶颈已经转移到「多快能决定真正需要做什么、验证它是否有效、获取用户反馈」。软件开发的核心矛盾正从代码生产转变为判断力问题。
规范说明的价值前所未有
编程本质上是一个翻译过程——把对需求的模糊描述，转化为计算机能精确执行的指令。AI 代理擅长执行，但在翻译这个环节上表现并不出色。
举个例子：「让我们的高级客户享受更快的提现速度。」 交给人类工程师，他会立刻追问一堆问题：谁是高级客户？规则是否适用于处理中的提现？如果账户失去高级资质会发生什么？
交给 AI 代理，它会自行填补大量空白，结果往往错误百出。一个可行的约束办法是通过 AGENTS.md 或 CLAUDE.md 强制要求代理不要猜测，而是主动提问。
根本问题在于，同一个需求在不同公司可能导出完全不同的答案。把同样的需求交给一家初创公司和一家拥有数百万账户、合规要求严苛的大银行，他们会构建出截然不同的系统。决策取决于组织的过往积累——事故处理经验、合同约束、预算、时间表等。AI 代理不可能了解这些背景。
在代理式开发环境中，代码实现成本在下降，但规格定义开始占据更多工程工作量。
最优秀的工程师，是那些能把模糊需求转化为明确规则、不变量、接口和验收标准的人——当然，也包括在必要时提出正确的问题。
由此可以得出：在代理式世界里，规格定义本质上是一种更高层次的编程抽象。
4. 验证将成为比代码生成更大的挑战
过去一年，AI 代码生成已经证明了代理可以在极短时间内产出大量代码。从 2025 年 11 月的 Opus 4.5 开始，生成代码的质量已经相当可观。然而，要证明代码的正确性，速度就远跟不上来了——这件事 AI 代理无法独立完成，常规的人工审核&查验 PR 也不再奏效，因为靠人工已经不可能逐行审阅所有代码。
我们真正需要的是一种可随代理规模扩展的更强验证手段。这套方法其实早已存在，只是现在比以往任何时候都更关键。它包括：编写测试、执行静态分析、添加架构约束与规则，以及更多手段。甚至可以看到形式化规格正走向主流。
以下是该团队 .NET 服务中，AI 生成代码通过合并前必须跨越的几道关卡：
- 构建与分析器：每个项目在 CI 中启用"警告即错误"、Roslyn 分析器以及 .editorconfig 规则，确保错误在人工介入前就被捕获。
- 测试：使用 Testcontainers 添加了单元测试和集成测试，代码覆盖率目标设定在 60%~80%。
- 架构测试：通过 ArchUnitNET 规则防止层级边界被破坏、禁止引入未授权项目引用，一旦违规测试立即失败。
- 安全与依赖扫描：SonarQube 在每个 PR 中检查质量门禁并执行依赖检查。
代码审核&查验的方式也在转变。现在不再逐行检查生成代码，而是将注意力集中在架构、意图、测试覆盖、风险以及自动化检查结果上。逐行审核&查验可以交给另一个模型处理——例如用 Opus 5 生成的代码，可以交由 GPT-5.6 Sol 或 CodeRabbit 这类专业工具来完成审核&查验。
核心转变在于：问题不再是"这段代码写得好不好"，而是"我们有没有证据证明系统行为符合预期"。由于代理产出的代码量巨大，这类证据必须来自机器，而非人工逐一检查。
不过也要注意关卡制度的局限：它只能证明代码通过了检查，却无法证明团队真正理解了这部分代码。一旦明天生产环境出现问题，仍然需要有人知道如何处理。这让每个团队面临一个根本问题——到底该不该审核&查验大规模 AI 生成的 PR？该团队的做法是：放慢节奏，小步迭代，先人工审核&查验，再逐步引入 AI 工具。
5. 架构的重要性前所未有
也许我们不再逐行审核&查验代码，但必须清晰定义和理解系统的架构与边界。为什么？因为 AI 代理既不了解我们的意图，也不应该替我们做这类决策。最终，我们为结果负责。
边界定义准确，代理在其范围内工作时造成破坏的概率就低。系统的大多数关键参数——接口、职责、依赖关系——都应该被明确定义。没有这些约束，代理只会堆出一个"大泥球"。
过去架构主要用于辅助人类理解和定义系统，现在它有了新的使命：成为代理的控制机制。好的架构现在能告诉我们变更应落在哪里、它依赖什么、哪些规则必须遵守。随着软件生产速度加快，这些约束的价值只会更高。
架构决策的典型例子包括：添加缓存以降低延迟，或者采用异步方案实现解耦并设定新的失败模式。这些都是涉及权衡的决策。没有任何方案能消除复杂性，只是将其转移到了别处。工程师决定复杂性放在哪里，代理在既定决策范围内执行。如果让代理来做这个决策，没有人能说清复杂性在哪里、放在当前项目上下文中是否合适。
6. 初级开发者困境：我们还需要初级工程师吗？
向代理式工程转型带来了许多担忧，其中初级工程师的命运是主要顾虑之一。眼下似乎没有人在招聘初级开发者了——但如果 AI 做了初级工程师的工作，一个人又怎么可能成长为资深工程师？资深能力是在长期实践中积累经验和判断力逐步形成的。写一段代码，从中学习错误调试和代码审核&查验。如果代理承担了所有实现工作，初级开发者就再也没有这条成长路径了。
问题在于，初级工程师不能仅靠观摩软件实现来建立判断力，必须亲历"失败—调试"的完整循环。我们最好的学习发生在事情不工作、必须调试解决的时候。
如何解决这个问题目前并不容易。一种方案是缩短初级工程师处于纯学习状态的时间，让他们更早承担真正的责任。可以是一个由他负责的小系统，或者一个需要对接的客户。这能让他们更快拥有所有权、学得更快。
同时也要承认初级工程师的一个优势：他们不需要像资深工程师那样先"忘掉"某些做法。他们从行业的当前状态起步。
7. 团队规模可能缩小，但职责范围将扩大
过去二十年，团队理想规模通常在 3~9 人，大型项目偶尔达到 15~16 人。现在情况已经改变——几位资深工程师就能协调多个代理，而完成同样的工作以前需要一个庞大团队。
大型团队从来就不是好主意。我很清楚地记得，团队人数增加时，交付速度反而下降。林格曼效应（Ringelmann Effect）解释了这一现象：成员越多，沟通协调成本越高，个人产出反而下降。如今，代理让小团队也能产出大规模成果。
软件更便宜，反而让系统更贵
这并不意味着我们需要比以前更少的工程师。当生产成本降低时，通常会创造新的需求——这就是著名的杰文斯悖论（Jevons Paradox）：某种资源的使用成本下降时，总消费量反而会上升。
在软件开发领域，这意味着当软件变得更容易生产时，企业会构建越来越多的产品。我们将拥有比以往更多的内部工具、定制工作流、个性化产品和实验性项目。软件总量可能会以前所未有的速度增长，这一点从 GitHub PR 数量的日常变化 中就能直观感受到。
由此产生的新问题是：一个团队能维护多少系统，而非一个应用需要多少工程师。
技术债务可能急剧膨胀
过去，开发新功能从来不是一件廉价的事：评估工时、团队讨论、权衡是否值得投入。比如某功能价值有限，却要占用半个团队三周时间，很可能就被放弃了。但如果借助 AI 代理，同样的功能三小时就能完成，会发生什么？
更多的想法会被实现，更多的实验性代码会留在生产系统中。这意味着更多服务的诞生、系统间更多依赖、以及更庞大的基础设施需要维护和监控。单个决策的成本虽然降低了，但当这样的决策越来越多时，整个系统的维护成本反而上升了——代码变便宜了，软件却变贵了。
认知债务：思考的外包代价
还有一种与之相关的债务叫做认知债务（Cognitive Debt）。当把思考工作交给 AI、让它生成输出，而我们无法真正理解这些输出时，认知债务就产生了（也有人称之为"认知投降"）。问题在于：即使系统是代理构建的，一旦发生崩溃，责任仍在我们身上。而没有代理的帮助，我们可能根本不知道如何解决。
应对认知债务的方法是：只部署那些你真正理解、能够回答相关问题的代码——至少在高层逻辑层面要能做到。这样才能保证未来有能力修改软件、让它在生产环境稳定运行。如果连这些问题都无法回答，就只是在给项目累积更多债务。
这里同样需要切换判断标准：应该问"这个软件是否应该存在"，而不仅仅是"它有多容易构建"。
最值钱的工程师，可能几乎不写代码
回到最初的命题：软件工程师 == 开发者吗？
试着想象五年后，优秀的软件工程师会做什么：首先要深入理解业务领域，与用户协作将模糊的需求转化为精确的系统行为规范，并选择合适的架构方案。然后由 AI 代理将设计转化为代码。工程师负责评估输出、审视方案并指明方向；代理继续推进、实现剩余功能、编写测试、检查安全并完成部署；生产环境的遥测数据则反馈给工程师，用于优化规范并指导下一轮迭代。
这样的工程师几乎不写代码，但其技术含量丝毫不减——因为他需要深度理解领域和系统，做出正确决策，并为最终结果负责。
职业能力的天平将从"编程"转向"理解问题、做出好决策、设计系统以及建立验证机制"。我一直建议开发者不要将自己的身份绑定于某一种编程语言或框架（例如"高级 Vue.js 开发者"），因为技术会变，但解决问题的能力不会。AI 代理让同样的道理延伸到了代码本身——代码变简单了，工程判断力没有。
评论