过去两年，关于 AI 写代码的讨论已经足够多。大家看过了演示，尝试过各种 agent，体验过“一句话生成一段功能”的速度，也逐渐感受到这件事带来的混乱。最初的震撼来自效率，后来真正让人不安的，是很多原本被视为稳固的行业前提开始松动。代码的生产成本下降得太快，以至于软件行业不得不重新回答一个很基础的问题：当代码本身不再稀缺，企业真正拥有的到底是什么。
这是 Steve Blank 那类判断真正刺中的地方。两年前成立的公司，如果今天还沿着当时的基本假设继续经营，很可能已经站在一块开始松动的地基上。问题不在于原来的团队不够优秀，产品不够认真，或者代码不够扎实，而在于 AI 改变的并不是某个局部环节，它改变的是软件生产函数本身。过去很多被归类为核心资产的东西，现在正在快速贬值；过去很多只被当成辅助能力的东西，反而开始显露出真正的战略重量。
首先受到冲击的，就是人们对“代码资产”的理解。传统软件公司之所以愿意长期投入工程团队、框架演进和代码治理，是因为代码天然稀缺，重写成本极高，维护它本身就是一种能力壁垒。这个逻辑在 AI 之前是成立的。问题在于，今天的代码已经越来越像一种可以被快速重构、快速替换、快速生成的中间产物。AI 对技术栈没有忠诚，也没有历史包袱，它不在乎这段功能是用 Java、Rust 还是 TypeScript 写出来，只要规约明确，它就能快速给出新的实现。
这会带来一个不太舒服的结论。很多公司过去引以为傲的私有代码库，正在从护城河的一部分，慢慢变成组织负担的一部分。它依然有价值，但这个价值更多来自业务规则的沉淀、边缘情况的覆盖和运行环境中的真实约束，而不是来自“代码写出来了”这件事本身。换句话说，代码不再自动等于资产，它开始更像一种承载业务逻辑的容器。容器仍然重要，但真正值得保护的，是里面那套被长期打磨过的判断体系。
于是，软件行业的重心开始悄悄移动。过去工程管理的核心问题是如何让更多人高效协作、写出更可维护的系统；现在更关键的问题变成了，谁能把需求表达得足够清楚，谁能把验证规则定义得足够严格，谁能在 AI 生成速度极快的情况下维持系统边界的稳定。写代码这件事没有消失，但它正在失去过去那种“一切都从这里开始”的中心地位。
这也是为什么未来的软件架构，越来越像“薄代码，厚规约”。如果 AI 可以持续生成和重构实现层，那么企业最需要守住的就不再是实现细节，而是业务规则、权限边界、测试体系、合规要求和异常处理的定义权。过去很多技术团队习惯把测试当作辅助环节，把规约当作文档，把架构图当作沟通材料。现在这些东西正在逐渐取代代码，变成真正的长期资产。因为 AI 可以快速写出系统，但只有规约和验证体系才能决定它写出来的究竟是一个能跑的样品，还是一个能承担真实业务责任的系统。
这进一步改变了产品价值的表达方式。传统 SaaS 时代，一个产品的价值很大程度上可以通过界面复杂度、功能丰富度和用户停留时长来证明。今天这套方法正在过时。Agent 化产品追求的是缩短交互路径，甚至主动消灭交互本身。最理想的状态，常常是用户几乎感觉不到产品存在，但任务已经被完成。问题在于，当使用过程变得不可见，价值也会一起隐身。产品如果还是沿用老办法证明自己，很容易陷入“明明很好用，但用户感知不到价值”的困境。
因此，软件产品正在从“提供工具”走向“交付结果”。这不只是商业包装的变化，而是计费逻辑和产品设计逻辑的同步重写。过去按席位收费，是因为软件主要卖的是使用权；未来更容易成立的，是围绕结果收费、围绕节省下来的决策成本收费、围绕完成的业务闭环收费。用户不再关心你提供了多少页面、多少按钮、多少工作流节点，他们更关心一件事，系统到底有没有把问题真正解决掉。
在这个新语境下，护城河的位置也在变化。功能复制会越来越快，界面模仿会越来越廉价，通用模型能力的扩散会让很多产品形态迅速趋同。如果一个团队仍然把护城河理解为“我们先做出来了这个功能”，那基本等于默认自己迟早会被追平。真正更难复制的部分，开始集中在几个更沉的层面：对特定行业工作流的深度嵌入，对私有数据和组织流程的长期理解，对异常处理责任的承担，以及建立起来的信任链。
这件事尤其重要，因为 AI 的强大恰恰伴随着不稳定。它可以快速提出方案，却并不天然保证方案正确；它可以帮助处理模糊问题，却不适合直接承担所有高风险决策。商业系统最怕的，从来不是“不够聪明”，而是“看上去很聪明但在关键时刻不可靠”。因此，AI 真正进入生产系统之后，最核心的挑战不是生成能力本身，而是如何把这种概率性能力嵌入一个确定性世界。
我越来越觉得，成熟系统最终都会走向一种分层架构。上层允许模型保留灵活性，去处理模糊输入、异常文本、复杂解释和开放式建议；下层则必须由严格的规约、类型系统、校验逻辑、回滚机制和沙箱环境组成。真正有经验的团队不会要求 AI 永远不犯错，他们会假设它一定会犯错，然后把系统设计成即使模型判断失误，错误也无法轻易穿透到最敏感的业务层。这种架构思想，和过去对软件可靠性的理解是一脉相承的，只不过今天审计对象从人写的代码，扩展成了模型驱动的整个执行链。
这也让技术债务出现了新的形态。AI 最大的诱惑，是把“做出来”这件事变得太容易。功能一旦可以被秒级生成，组织就会天然倾向于堆更多流程、接更多需求、上线更多半成品。系统复杂度并不会因为生成速度提高而自动下降，很多时候恰恰相反，它会以更快速度膨胀。过去技术债务主要来自时间不足、经验不足或项目压力，未来很大一部分技术债务会来自生成过剩，来自系统在短时间里长出太多未经压缩、未经提炼、未经真正抽象的逻辑。
因此，未来优秀的技术团队，未必是写代码最快的团队，而更可能是最早建立“持续压缩能力”的团队。AI 可以帮助生成系统，也必须被用来审视和压缩系统。否则，组织会在看似高产的节奏里迅速积累难以理解的复杂度。真正的竞争力，越来越像一种对系统熵值的管理能力。谁能在高速生成的同时持续收紧结构，谁才能真正把 AI 带来的生产力变成可持续优势。
再往前走一步，这种变化最终会落到人的角色转型上。过去开发者常被视为需求和机器之间的翻译者，把业务语言转换成程序逻辑，把模糊想法压缩成确定实现。这个角色不会立刻消失，但它的重要性正在下降。因为翻译本身越来越容易自动化，真正稀缺的部分转移到了别处。人开始更像裁判、编辑、策展者和责任承担者。人要定义什么是成功，什么是失败，哪些结果可以接受，哪些边界绝对不能碰，哪些方案虽然能跑却会在半年后拖垮系统。
这对很多技术人来说是一个并不轻松的转换。写代码是一种明确反馈、即时回报很强的工作，而判断、取舍、验证和设计标准则更模糊，也更难量化。但现实正在逼着行业接受这一点。未来真正稀缺的，不是把想法变成代码的人，而是能在模糊问题里建立结构、在快速生成中守住边界、在看似合理的多种方案中做出长期更优判断的人。
所以，如果今天还要问 AI 时代的软件行业究竟在发生什么，我会倾向于给出一个更简单的回答：我们正在从“代码稀缺”的世界进入“判断稀缺”的世界。代码仍然重要，但它越来越像水电和钢筋，是构建系统的必要材料，却不再天然决定价值。真正更难被复制的，是结构、验证、责任和审美。
这也是为什么我觉得，眼下最该被重估的能力不是写得更快，而是想得更清楚。因为当任何人都能让机器快速造出一套系统时，真正拉开差距的，就只剩下一个问题：你究竟知不知道自己在造什么。