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