程序员每十年就“要被取代”一次：这件事从 1969 年开始

作者｜ Stephan Schwab

译者｜冬梅

策划｜Tina

编者按：

过去半个多世纪，软件开发领域反复上演着一种熟悉的叙事：每当一种新技术出现，总会伴随着一个激动人心的承诺——编程将变得更简单，软件将不再是少数专业人士的专利，业务人员也可以亲自“把需求变成系统”。从 COBOL 到 CASE 工具，从可视化开发环境到低代码、无代码平台，再到今天被寄予厚望的 AI，这个梦想一次次被点燃，又一次次被现实修正。

这篇文章试图回到历史本身，梳理这条看似循环、却不断演进的技术轨迹。它从阿波罗登月这一人类工程史上的高光时刻讲起，揭示软件如何从幕后走到台前，成为支撑复杂系统的关键力量；也回顾了企业世界中一次次“降低门槛”的努力，为什么总能解决部分问题，却始终无法绕开真正的复杂性。

文章作者 Stephan Schwab 自 1981 年起就开始从事编程工作，曾使用过各种不同的平台和大约 20 种不同的编程语言。目前，他主要专注于了解用户和企业真正希望如何使用软件，以及如何开发能够激发客户兴趣的软件。他成长于德国，并在多个国家生活和工作过。他能说一口流利的德语、英语和西班牙语。

Stephan 在文章并不否认技术进步带来的价值。相反，他清晰地指出：每一代工具都确实让开发更快、更高效，让更多人得以参与软件创造。但与此同时，一个始终未变的事实也逐渐浮现——软件开发真正受限的，从来不是语法、界面或工具形态，而是对复杂现实的理解、判断与取舍。

在 AI 编程工具引发新一轮想象的当下，这种回望显得尤为重要。AI 究竟是在“终结开发者”，还是在重塑开发者的工作方式？历史或许已经给出了线索。读完这篇文章，你可能不会对未来抱有不切实际的幻想，但会更清楚地理解：为什么这个行业一次次期待“更简单”，又为什么真正的价值，始终来自那些愿意思考复杂问题的人。

1 梦想，诞生于人类最伟大的成就时刻

1969 年，尼尔·阿姆斯特朗踏上月球表面的那一刻，全世界亲眼见证了“有组织的人类智慧”究竟能够走多远。而支撑这次壮举的背后，是玛格丽特·汉密尔顿和她的团队——他们一行一行地手写阿波罗号的导航软件，通过极其严谨的人工审查捕捉关键错误，第一次向世人证明：软件并非可有可无的工具，而是关乎任务成败、甚至生死存亡的核心系统。

阿波罗计划让人类意识到，正是软件开发，才让“不可能”成为现实。但与此同时，它也暴露出一个此后几十年持续困扰企业管理者的现实问题：软件的编写需要高度专业的知识、长期的专注投入，以及难以压缩的时间成本。如何让软件开发变得更简单——如何减少对这些昂贵而稀缺的专业人员的依赖——几乎在那一刻就成为了一种挥之不去的梦想。

2 COBOL：让业务人员自己写程序

20 世纪 60 年代末到 70 年代，COBOL 语言登上历史舞台，它的雄心甚至直接写进了名字里——“通用业务导向语言”。设计者的愿景异常清晰而大胆：让编程语言看起来就像英文句子一样自然，这样一来，业务分析师就可以亲自编写程序，而不再需要依赖受过高度专业训练的程序员。软件开发，似乎第一次被描绘成一件“人人可参与”的事情。

这一愿景确实极具吸引力。

随着软件逐渐成为企业运转的命脉，程序员却始终是稀缺而昂贵的资源。COBOL 承诺要“让软件开发民主化”，让更多人参与进来，这听上去几乎是企业管理者的福音。

但现实给出了另一种答案。COBOL 最终只是变成了另一门需要系统训练的编程语言。那些尝试亲自编写 COBOL 程序的业务分析师很快发现：语法是否“像英语”，并不能消除逻辑本身的复杂性，也无法绕开数据结构、系统设计这些硬核问题。结果是，一群新的“COBOL 程序员”诞生了，而“不再需要专业开发者”的梦想，再一次落空。

不过，这个梦想并没有消失。

它只是耐心地，等待着下一次技术浪潮的到来。

3 20 世纪 80 年代：CASE 工具将自动生成一切

进入 80 年代，计算机辅助软件工程（CASE）工具横空出世，带着近乎颠覆性的承诺而来：只要画流程图、画实体关系图，工具就能自动生成可运行的代码。市场宣传精准击中了人们的直觉——视觉化设计，显然比敲打晦涩难懂的命令要“更符合人性”。业务专家只需把流程“画出来”，软件就会自然生成。

企业为此投入了大量资金。厂商信誓旦旦地宣称，生产力可以提升 10 倍，甚至更多。

但现实再次泼了冷水。

生成的代码往往需要大量人工修改；性能问题接连出现；当生成代码与可视化模型逐渐“走散”后，维护几乎变成了一场噩梦。更致命的是，要画出真正准确的图，本身就需要对业务逻辑和系统复杂性有深入理解——这与写代码所要求的认知能力并无本质差异。工具改变了操作界面，却没有触及问题的核心。

再一次，人们发现：问题远比解决方案顽固得多。

4 Visual Basic 与 Delphi：拖一拖，放一放，就完成了

90 年代带来了另一条路径。微软的 Visual Basic 和 Borland 的 Delphi，让构建用户界面变得前所未有地简单：把组件拖到窗口上，设置属性，编写事件处理代码。突然之间，开发一个 Windows 应用，看起来不再是少数高手的专利。

这一次，它们的成功方式，与 COBOL 和 CASE 工具有所不同。

这些工具并没有否认“编程知识仍然必要”，而是显著降低了入门门槛。更多具备中等经验的人，也能做出真正有用的软件。

然而，“消灭开发者”的梦想依然顽强存在。“高级用户”“公民开发者”将自行构建部门级应用；IT 部门只需专注基础设施，业务部门自己解决软件需求——这一蓝图再次令人心动。

但现实依旧更加复杂。

简单应用确实更容易上手了，可一旦需求开始变复杂——系统集成、安全合规、高并发性能、长期维护——经验丰富的开发者就不可避免地走回舞台中央。这些工具扩展了“谁可以写软件”的边界，却从未消除构建大型系统所需的专业能力。

于是，这个循环，被带入了新的千年。

5 2000 年代及以后：Web 框架、低代码、无代码

每一个新的十年，都会带来新的变体。

Ruby on Rails 提出“约定优于配置”；低代码平台用可视化开发减少手写代码；无代码平台甚至宣称，常见业务应用可以完全不写程序。

每一波浪潮，都带来了真实的价值。在特定场景下，开发速度确实大幅提升；更多人开始参与软件创造。但与此同时，专业软件工程师不仅没有被取代，对他们的需求反而持续增长。

这就引出了一个关键问题：为什么这个模式会一再重演？

为什么这个梦想始终存在？

这种反复出现的模式，揭示了我们对“复杂性”的一种根本误判。软件开发之所以看起来应该很简单，是因为我们能用自然语言描述目标：“当客户下单时，检查库存、计算运费、处理支付、发送确认邮件。”这段话听起来毫不费力。

真正的复杂性，藏在细节里。

• 库存被另一个订单临时占用怎么办？

• 部分支付如何处理？

• 邮件服务暂时不可用，是重试还是放弃？重试几次？

• 结账过程中用户会话过期怎么办？

• 如何防止重复下单？

每一个答案，都会引出新的问题。无数边界情况、决策分支和相互作用层层叠加，形成了任何工具都无法抹平的真实复杂性。无论使用 COBOL、CASE 图、Visual Basic，还是 AI 提示词，这种“思考本身”，就是软件开发。

这，也正是今天这股热潮的背景。

6 AI：一段漫长历史中的最新章节

今天的 AI 编程助手，是迄今为止最强大的尝试。它们可以根据自然语言生成大量可运行代码，解释现有代码，提出优化建议，甚至协助调试问题。

这是实实在在的进步。经验丰富的开发者，正在用 AI 明显提升效率；初学者，也能从互动式指导中受益。

但熟悉的模式已经开始浮现。最初关于“AI 将取代开发者”的狂热，正在逐渐让位于更冷静的认知：AI 改变了开发者的工作方式，却并没有替代他们的判断力。复杂性依然存在。必须有人理解业务问题，评估生成代码是否真正解决了问题，审视安全风险，确保系统集成顺畅，并在需求变化中持续维护。

AI 放大了开发者的能力，但并没有取代“理解问题与技术全局”的人。

这里存在一个格外耐人寻味的悖论。

我们的软件能力取得了惊人的进步。阿波罗制导计算机只有 4KB 内存，而你的手机拥有数百万倍的算力。开发工具和框架，确实让许多事情变得更容易。

但软件需求，依然远远超过我们的交付能力。几乎每一家组织，都想要比自己能构建的更多软件。需求清单增长的速度，始终快于开发团队的消化能力。

正是这种张力——工具愈发强大，产能却依然不足——让梦想持续存在。管理者面对积压的需求，自然会想：“一定有办法更快，让更多人参与进来。”这并非不理性，而是极其现实的期待。

问题在于，软件开发的瓶颈，从来不在打字速度，也不在语法复杂度，而在于处理复杂性的思考能力。打字再快，也无法替代对并发数据库更新的推演；语法再简单，也无法绕开对安全影响的深度判断。

7 这对管理者意味着什么

理解这一历史循环，会彻底改变你评估新工具的方式。

当有人承诺“业务人员无需开发者也能构建应用”时，你可以理解这种愿景，但也能保持清醒的预期。

真正该问的，不是“这能否消灭开发者”，而是：

• 它是否能帮助开发者更高效地解决复杂问题？

• 是否能让某些类型的解决方案更快落地？

• 是否能减少重复性劳动，让人专注于真正独特的挑战？

• 团队是否需要为此学习新的能力？

这些问题，既承认复杂性的不可消除，也为真正有价值的工具留出了空间。

8 五十年的重复，揭示了问题的本质

这五十年的历史告诉我们一个根本事实：如果软件开发的难点主要是机械性的——打字太多、语法太复杂、步骤太繁琐——我们早就解决了。COBOL 让语法可读，CASE 工具消除了输入，视觉化工具绕开了语法，AI 甚至能直接生成完整函数。

每一次进步，都解决了真实存在的摩擦点。

但核心挑战始终存在，因为它不是机械问题，而是认知问题。软件开发，是把思考变成可运行的现实。无论是 COBOL 程序、Delphi 窗口，还是 Python 脚本，它们都只是复杂思考的外在表现。

这种思考，无法被“跳过”，就像建筑设计或医学诊断一样。工具能帮助，经验能加速，但终究需要有人把问题想清楚。

9 带着清醒前行，因为梦想本身就有意义

新的开发浪潮还会到来。有的会真正创造价值，有的会用新技术重复旧承诺。理解这条历史曲线，能帮助你更理性地使用新工具。

使用 AI 助手，评估低代码平台，尝试新框架——但最重要的投入，依然应该放在提升人们理解和驾驭复杂性的能力上。这一点，自阿波罗时代至今，从未改变。

登月成功，不是因为工具多么先进，而是因为一群杰出的人，把极端复杂的问题逐一想透。他们手写软件，只是因为当时别无选择。如果有更好的工具，他们一定会用。但工具，从来不是替他们思考的东西。

我们今天处在同样的基本处境中：工具更强了，强得多，但思考依然不可或缺。

也许，一次次想要“替代开发者”的梦想，并不是错误。也许，正是这种带着理想主义色彩的乐观，推动了工具的进步。每一次尝试，都没有按最初设想实现，却都创造了真实的价值。

COBOL 没让业务人员写程序，却支撑了一代商业系统；CASE 工具没自动生成应用，却推动了建模思想；Visual Basic 没消灭开发者，却让更多人走进开发世界；AI 不会取代工程师，但必然深刻改变我们的工作方式。

这个模式之所以不断重演，是因为它源于一个真实而迫切的需求：我们需要更快、更高效地创造软件。只是一次又一次，我们发现，真正的限制从来不在工具，而在问题本身的复杂性。

理解这一点，并不意味着拒绝新工具，而是带着清醒的期待去使用它们——知道什么可以交给技术，什么永远需要人类的判断。

https://www.caimito.net/en/blog/2025/12/07/the-recurring-dream-of-replacing-developers.html