《软件工程经济学》①

软件工程里，最昂贵的成本到底是什么？

过去两年，软件行业几乎形成了一个没有争议的共识：AI 正在让软件开发越来越便宜。

这句话听起来没有问题，但我越来越怀疑，我们可能把两个不同的概念混在了一起。

变便宜的，也许只是写代码，而不是软件开发。

过去很长一段时间，这两个概念几乎可以画上等号。软件工程的大部分投入，都集中在"把系统实现出来"这件事情上。更高级的编程语言、更完善的框架、更成熟的开源生态、更自动化的 CI/CD 、更智能的开发工具，本质上都在解决同一个问题：如何更快、更稳定地完成实现。

AI Coding 是这条技术路线迄今为止最显著的一次跃迁。如果只讨论"实现"这一环，它带来的效率提升，几乎超过了过去十年的总和。

但真正让我感兴趣的，并不是代码生成速度。

而是另一个现象。

越来越多团队告诉我，他们花在写代码上的时间减少了，却没有觉得开发变得更轻松。

讨论需求的时间变多了。

解释业务背景的时间变多了。

反复补充上下文的时间变多了。

验证 AI 输出是否符合预期的时间也变多了。

如果软件开发真的变便宜了，这些时间为什么没有一起消失？

如果把软件开发抽象来看，它其实始终围绕三个问题展开。

• 
  

  第一，搞清楚要干什么。

  
  


• 
  

  第二，把它做出来。

  
  


• 
  

  第三，确认做对了。

  
  

过去二十多年，整个行业几乎都在优化第二个问题。

今天，这个问题正在以前所未有的速度被解决。

于是，另外两个问题开始变得越来越显眼。

最近，一位朋友分享了他们团队的经历。

Agent 很快完成了一次大规模重构：修改了十几个文件，补齐了测试，也顺利通过了构建。

真正的问题出现在两小时以后。

团队才发现，它理解错的不是代码，而是一条业务规则。

整个实现都建立在一个错误的理解之上。

最终不得不推倒重来。

类似的事情，我相信很多团队都经历过。

过去，一个理解不完整的需求，往往只会产生几十行有偏差的代码，很快就能发现问题。

今天，同样的理解偏差，可能在几分钟内演化成几千行代码、几十个文件、完整的测试，以及一套看起来完全合理的实现。

返工因此变得更加昂贵。

这让我越来越觉得：

AI 没有创造新的问题，它只是第一次让很多旧问题，再也藏不住了。

AI 把写错代码的成本降到了零，却把理解错问题的成本放大到了前所未有的规模。

于是，一个以前很少认真讨论的问题重新出现了。

软件工程里，真正昂贵的成本，到底是什么？

如果回头看过去四十年的软件工程发展，会发现不同阶段给出的答案并不一样。

上世纪九十年代，大型企业系统的需求相对稳定，发布周期长，修改代价高。在这样的环境里，尽可能把需求分析清楚，再进入实现阶段，是一种合理的经济选择。RUP 、用例驱动开发等方法论，都诞生于这样的背景。

后来，互联网改变了另一件事情。

很多产品的需求，并不是分析出来的，而是上线以后才逐渐发现的。没人能够在项目开始之前，就完整定义一个社交网络应该是什么样子，也没人能够提前设计出今天短视频产品的全部交互。

于是，快速试错比完整分析更重要。

敏捷因此成为那个时代更符合成本结构的选择。

很多人后来总结说：

RUP 输给了敏捷。

但我越来越怀疑，这样的总结是不是过于简单。

敏捷真正证明的，也许并不是 RUP 的方向错了。

它证明的更可能是，在另一种成本结构下，存在一种更经济的组织方式。

方法论发生了变化。

真正变化的，也许不是理念，而是成本。

RUP 不是输给了敏捷。是'提前分析清楚'这件事，在快速试错的环境里，变得比'快速上线再迭代'更贵了。

今天，当 AI 大幅降低了实现成本，我们或许又站在了另一个新的起点。

那些过去因为维护代价太高而被放弃的实践，会不会值得重新评价？

那些过去隐藏在实现成本之后的问题，会不会重新成为软件工程真正的瓶颈？

我不知道答案。

但我越来越觉得，这些问题，比"AI 会不会取代程序员"更值得讨论。

因为真正改变软件工程的，往往不是一种新的工具。

而是工具改变了软件开发中，什么事情最昂贵。

下一篇，我们把时间尺度再拉长一点。

如果把软件工程四十多年的发展放在一起看，它也许并不像一条不断进步的直线。

也许，它更像一个不断摆动的钟摆。

而每一次摆动，都发生在人们重新计算"什么最贵"的时候。

最后留一个问题。

过去一年，你所在团队最大的返工成本，来自哪里？

是代码写错了？

还是从一开始，就理解错了要解决的问题？