这篇文章讲了一个 50 年都没变过的剧本：每隔十年，就有人拿着新工具跑出来说"这次真的不需要那么多程序员了"。然后大家发现，还是需要。
故事从 1969 年阿波罗登月开始。那时候 Margaret Hamilton 带着团队手写飞船的导航软件，证明了软件能做成关键任务。但这也让商业领袖们开始头疼：写软件怎么这么贵、这么慢、还非得找这群难搞的专家？
于是 COBOL 来了——"让语法像英语一样，业务人员自己就能写程序"。结果呢？业务人员发现，语法像英语没用，逻辑、数据结构、系统设计还是得学。COBOL 只是造出了一批新的 COBOL 程序员。
80 年代换了个思路：CASE 工具，画流程图就能生成代码。投资巨大，产出惨淡。生成的代码性能差、难维护，而且画准确的图本身就需要编程思维。
90 年代 Visual Basic 和 Delphi 来了，拖拽组件、设置属性，做个 Windows 程序看起来简单多了。这波确实让更多人能写小应用，但复杂系统？还是得找专业开发者。
2000 年代到现在，Ruby on Rails、低代码、无代码、AI 编程助手，一波接一波。每波都有真实价值，但每波都没实现那个梦想。
为什么？
作者给了一个很精准的诊断：软件开发的难点不是打字，是思考。
你说"用户下单时，检查库存、算运费、扣款、发邮件"——听起来很简单。但复杂性藏在细节里：库存被另一个订单锁住了怎么办？部分付款怎么处理？邮件服务挂了要不要重试？重试几次？用户 session 超时了怎么办？怎么防止重复订单？
每个答案都引出更多问题。这些问题的累积，就是真正的复杂性。任何工具都无法替你思考这些。
所以 AI 也不会例外。它确实能生成大量代码，但谁来判断这代码是否正确解决了业务问题？谁来考虑安全隐患？谁来确保它和现有系统兼容？谁来在需求变化时维护它？
AI 放大了开发者的能力，但没有替代开发者的判断。
作者最后说了一句很有意思的话：这个梦想也许不是错误，而是一种"必要的乐观"。正是因为人们一直想让软件开发变简单，才推动了工具的进步。每次尝试都留下了真实的价值——只是从来没有实现最初的承诺。
底线是什么？
下次有人跟你推销"这个工具能替代开发者"，你可以礼貌地说：历史上每十年都有人这么说。然后问他四个问题：
- 这能帮开发者更高效吗？
- 能加速特定场景吗？
- 能减少重复劳动吗？
- 我的人需要学什么新技能？
问对问题，比相信承诺靠谱得多。