《软件工程经济学》①
软件工程里，最昂贵的成本到底是什么？
过去两年，软件行业几乎形成了一个没有争议的共识：AI 正在让软件开发越来越便宜。
这句话听起来没有问题，但我越来越怀疑，我们可能把两个不同的概念混在了一起。
变便宜的，也许只是写代码，而不是软件开发。
过去很长一段时间，这两个概念几乎可以画上等号。软件工程的大部分投入，都集中在"把系统实现出来"这件事情上。更高级的编程语言、更完善的框架、更成熟的开源生态、更自动化的 CI/CD 、更智能的开发工具，本质上都在解决同一个问题：如何更快、更稳定地完成实现。
AI Coding 是这条技术路线迄今为止最显著的一次跃迁。如果只讨论"实现"这一环，它带来的效率提升，几乎超过了过去十年的总和。
但真正让我感兴趣的，并不是代码生成速度。
而是另一个现象。
越来越多团队告诉我，他们花在写代码上的时间减少了，却没有觉得开发变得更轻松。
讨论需求的时间变多了。
解释业务背景的时间变多了。
反复补充上下文的时间变多了。
验证 AI 输出是否符合预期的时间也变多了。
如果软件开发真的变便宜了，这些时间为什么没有一起消失？
如果把软件开发抽象来看，它其实始终围绕三个问题展开。
-
第一，搞清楚要干什么。
-
第二，把它做出来。
-
第三，确认做对了。
过去二十多年，整个行业几乎都在优化第二个问题。
今天，这个问题正在以前所未有的速度被解决。
于是，另外两个问题开始变得越来越显眼。
最近，一位朋友分享了他们团队的经历。
Agent 很快完成了一次大规模重构：修改了十几个文件，补齐了测试，也顺利通过了构建。
真正的问题出现在两小时以后。
团队才发现，它理解错的不是代码，而是一条业务规则。
整个实现都建立在一个错误的理解之上。
最终不得不推倒重来。
类似的事情，我相信很多团队都经历过。
过去，一个理解不完整的需求，往往只会产生几十行有偏差的代码，很快就能发现问题。
今天，同样的理解偏差，可能在几分钟内演化成几千行代码、几十个文件、完整的测试，以及一套看起来完全合理的实现。
返工因此变得更加昂贵。
这让我越来越觉得：
AI 没有创造新的问题，它只是第一次让很多旧问题，再也藏不住了。
AI 把写错代码的成本降到了零，却把理解错问题的成本放大到了前所未有的规模。
于是，一个以前很少认真讨论的问题重新出现了。
软件工程里，真正昂贵的成本，到底是什么？
如果回头看过去四十年的软件工程发展，会发现不同阶段给出的答案并不一样。
上世纪九十年代，大型企业系统的需求相对稳定，发布周期长，修改代价高。在这样的环境里，尽可能把需求分析清楚，再进入实现阶段，是一种合理的经济选择。RUP 、用例驱动开发等方法论，都诞生于这样的背景。
后来，互联网改变了另一件事情。
很多产品的需求，并不是分析出来的，而是上线以后才逐渐发现的。没人能够在项目开始之前，就完整定义一个社交网络应该是什么样子，也没人能够提前设计出今天短视频产品的全部交互。
于是，快速试错比完整分析更重要。
敏捷因此成为那个时代更符合成本结构的选择。
很多人后来总结说：
RUP 输给了敏捷。
但我越来越怀疑，这样的总结是不是过于简单。
敏捷真正证明的，也许并不是 RUP 的方向错了。
它证明的更可能是，在另一种成本结构下，存在一种更经济的组织方式。
方法论发生了变化。
真正变化的，也许不是理念，而是成本。
RUP 不是输给了敏捷。是'提前分析清楚'这件事，在快速试错的环境里，变得比'快速上线再迭代'更贵了。
今天，当 AI 大幅降低了实现成本，我们或许又站在了另一个新的起点。
那些过去因为维护代价太高而被放弃的实践，会不会值得重新评价？
那些过去隐藏在实现成本之后的问题，会不会重新成为软件工程真正的瓶颈？
我不知道答案。
但我越来越觉得，这些问题，比"AI 会不会取代程序员"更值得讨论。
因为真正改变软件工程的，往往不是一种新的工具。
而是工具改变了软件开发中，什么事情最昂贵。
下一篇，我们把时间尺度再拉长一点。
如果把软件工程四十多年的发展放在一起看，它也许并不像一条不断进步的直线。
也许，它更像一个不断摆动的钟摆。
而每一次摆动，都发生在人们重新计算"什么最贵"的时候。
最后留一个问题。
过去一年，你所在团队最大的返工成本，来自哪里？
是代码写错了？
还是从一开始，就理解错了要解决的问题？
1
Select Language