用盖房子解释为什么软件开发很难
Explaining to business people why building software is still hard
在黑客松的最后一天，我和团队原本想用 Lovable 快速构建 HoneyCrew 智能推荐系统，结果从第一天的飞速进展陷入第二天的全面崩溃。面对非技术背景同事的困惑，我意识到用‘盖房子’来类比软件开发最有效：屋顶漏水不能只放桶接水，而要找到根源；建新房时预留二层结构比日后加建便宜得多。软件就像一座永远无法完工的房子，需要在有人居住时不断维护升级。基础设施和重构并非浪费，而是避免未来更大代价的必要投入。
软件就像一座房子，你永远无法真正完成它的建设，因为人们已经住进去了，你必须不断更新设施。
HN 评论区
57- dasil003
所有软件都具有路径依赖性，所有代码都是负债，所有技术决策都是权衡。这些是软件领域不可改变的真理，无论是 AI 的出现还是此前摩尔定律的进步，都丝毫未能改变它们。
有太多产品经理和决策者无法或不愿下功夫真正理清他们想要什么，也无法在获得新反馈和新认知后重新评估自己的先验假设。同样，也有太多工程师远离客户和当下问题，最终追逐自己心中那个脱离现实的“完美软件”理念，忽视了当下真正需求与未来预期需求之间艰难的权衡。我们写的代码越少，越能解决当下问题，同时尽量减少“单行道”式的决策，并将尽可能多的“扩展性”挑战推迟到未来，以便在掌握更完整信息时再做决定，这才是更好的做法。
这就是为什么 AGI 无法神奇地解决软件开发问题——因为人们往往在尝试之前根本不知道自己想要什么，而且一旦尝试后，他们又想要别的东西了。原始的智能无法解决目标或人类需求的问题。它变得越强大，就越像一个邪恶的精灵或猴爪，永远无法完全满足那些头脑简单的人类提示者的愿望。
- tripleee
这一切的根源在于没人真正理解软件中“质量”的意义。
低质量 = 级联的 Bug、问题频发、迭代缓慢，添加或修改功能也变得困难。
这对人类编写的代码和 AI 生成的代码同样适用。
然而，我们却看到所有人都在放弃代码质量，仿佛质量就只是“漂亮的代码”——完美缩进，只供人赞叹“哇哦”和“啧啧”而已。
- miranaproarrow
我的经理用 Claude 的 Design 功能“凭感觉”写完了我们整个 Web 应用，却很难理解为什么它至今仍无法投入生产。
我的工作是将其与后端数据对接，而这些对接工作很多时候需要我深入其中，真正思考功能逻辑。这些工作耗时很长，而我目前还没找到用 Claude 加速这一过程的方法。
- digitallogic
“你的预算只够建第一层，但你家里人口多，你知道几年后肯定会需要第二层。”
“现在就要搭建支持第二层的基础设施，成本远低于等你真正需要第二层时再建。”
这种思路的问题在于它需要对未来有确定性。只有在你最终确实需要那个东西时，现在搭建才更便宜。如果你并不需要，那你就是白白浪费了时间和金钱。
我认为这个类比薄弱的地方在于：你对于自己是否想要一个大家庭的确定性，远大于你是否能预测某条新产品线是否会获得重大采用的确定性。
- mehagar
即使你使用 AI 工具来辅助写代码，在某种程度上，你仍然必须为程序的每一个可能输入指定其应有的输出。
如果在提示词中只是模糊地描述需求，AI 工具就没有足够的上下文来判断在所有可能输入下应该产生什么“正确”的输出。而且，“正确”本身往往也是主观的（“这个按钮应该是红色还是蓝色？”）。