每10年一次的“开发者淘汰战”，自1969年就已开局！

每十年，总有人信心满满地宣称：“这次，我们终于可以让软件开发变得简单，不再需要那么多开发者了。”但现实是，我们真的不再需要开发者了吗？

近日，资深开发者 Stephan Schwab 在《Why We’ve Tried to Replace Developers Every Decade Since 1969》一文中回顾了过去五十年软件开发的迭代历程——从阿波罗计划手写导航软件的壮举，到 COBOL、CASE 工具、Visual Basic，再到今天的 AI 编程助手，他深度分析了为什么试图“替代开发者”的梦想总是反复出现。

通过剖析这一模式，我们不仅能理解工具如何改变开发方式，更能看清软件工作的本质：复杂性不可消解，而真正的核心，是人的思考。这篇文章带你回到每一次技术浪潮的现场，看看每一次尝试如何既带来便利，又揭示了不可绕过的挑战——也让我们明白，开发者从未真正被替代，只是工作方式在不断进化。

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

作者 | Stephan Schwab 责编 | 苏宓

出品 | CSDN（ID：CSDNnews）

梦想诞生于人类最伟大的成就

1969 年，当尼尔·阿姆斯特朗踏上月球时，全世界见证了有组织的人类智慧能实现的奇迹。而这背后，是玛格丽特·汉密尔顿及其团队手写的阿波罗导航软件，通过仔细复核捕捉关键错误，证明软件可以至关重要。

阿波罗计划展示了软件开发在实现“不可能”任务中的核心价值，但也暴露了一个让企业高管数十年困扰的问题：写软件需要专业知识、高度专注和大量时间投入。于是，让开发更简单、减少对这些昂贵专家依赖的梦想几乎立刻诞生。

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

上世纪 60-70 年代，COBOL 出现了，其名字本身就明确目标：Common Business-Oriented Language（通用业务导向语言）。理念很清晰：让语言像英语一样可读，业务分析师就能自己写程序，无需专业程序员。

“如果语法足够易读，任何理解业务的人都能写代码。”

这个愿景确实很吸引人。软件对业务运作越来越关键，但程序员仍然稀缺且昂贵。COBOL 承诺让软件开发大众化。

然而，现实并非如此。COBOL 最终还是一门需要专业培训的语言。业务分析师尝试写 COBOL 时很快发现：可读的语法并不能消除逻辑、数据结构或系统设计的复杂性。于是，出现了一类新的 COBOL 程序员，而消除专业开发者的梦想依然未能实现。

梦想并未消亡，它只是等待下一波技术浪潮。

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

20 世纪 80 年代，计算机辅助软件工程（CASE）工具出现，带来了巨大的期望。只需绘制流程图或实体关系图，工具就能生成可运行的代码。它的宣传口号很有吸引力：可视化设计比输入复杂难懂的命令更直观。业务专家可以建模自己的流程，而软件就会自动生成。

企业投入巨大，供应商承诺生产力提升十倍以上。然而，大多数 CASE 工具项目要么挣扎，要么彻底失败。

生成的代码往往需要大量手工干预。性能问题频出。维护更是噩梦——生成代码与视觉模型一旦偏离，问题层出不穷。最关键的是，画准确的图表仍然需要理解与编程同样的逻辑复杂性。工具改变了界面，但没改变根本挑战。

问题再次证明，比解决方案更难应对。

Visual Basic 和 Delphi：拖一拖，写好了

90 年代出现了不同的思路。微软的 Visual Basic 和 Borland 的 Delphi 大幅降低了用户界面开发难度：拖组件、设置属性、写事件处理程序，Windows 应用开发对经验有限的开发者来说也变得可行。

这波浪潮与 COBOL 或 CASE 工具不同。它承认编程知识仍然必不可少，但降低了入门门槛，让更多人能够创建有用应用。

然而，消除开发者的梦想依然存在：“高级用户”和“公民开发者”可以构建部门级应用，IT 部门只管基础设施，业务部门解决自己的软件需求。

现实更微妙。简单应用确实更易被更多人使用，但随着需求复杂度增加——与现有系统集成、安全性要求、负载性能、长期维护——对经验丰富开发者的需求变得显而易见。工具扩大了可编程人群，却无法消除构建复杂系统所需的专业知识。

于是，这个循环延续到新千年。

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

每个十年都会带来新的变化。Ruby on Rails 推出了“约定优于配置”；低代码平台提供可视化开发，几乎无需编码；无代码平台宣称可以完全免编程完成常见业务应用。

每一波都带来了真正价值。开发在特定场景下确实更快了，更多人能参与软件创建。然而，专业开发者仍不可或缺，且对其技能的需求非但没有减少，反而持续增长。

这就引出一个问题：为什么这个模式总是重复？

为什么这个梦想一直存在

反复出现的模式揭示了我们对复杂性认知的重要事实：软件开发看起来应该简单，因为我们可以用普通语言描述需求。

“当客户下单时，检查库存、计算运费、处理支付，并发送确认邮件。”这样的描述听起来很简单明了。

但复杂性隐藏在细节中：库存被其他订单暂时占用怎么办？部分付款如何处理？邮件服务暂时不可用怎么办？是否重试？重试几次？客户在结账时会话过期怎么办？如何避免重复订单？

每个答案又会引出更多问题。累积的决策、极端情况和交互产生真正的复杂性，没有工具或语言可以消除。有人必须思考这些情境，这就是软件开发——无论是用 COBOL、CASE 工具图、Visual Basic 还是 AI 提示。

AI：漫长故事中的最新章节

今天的 AI 编程助手是迄今最强大的尝试，它们可以根据自然语言描述生成大量可运行代码，解释现有代码、提出改进建议、帮助调试。

这确实是进步。对经验开发者来说，它们提高了效率；对学习者来说，交互式指导非常有帮助。

然而，我们已经看到熟悉的模式出现：初期对 AI 替代开发者的兴奋，正在被更细致的理解取代——AI 改变的是开发者的工作方式，而不是消除他们的判断需求。复杂性依然存在：有人必须理解业务问题，评估生成代码是否正确，考虑安全性，确保与现有系统整合，并在需求变化时维护代码。

AI 扩大了开发者能力，却无法替代那些既懂业务又懂技术的人。

机会巨大，但仍然捉襟见肘

这是让这个模式更具讽刺意味的悖论。软件能力进步惊人：阿波罗导航电脑只有 4KB 内存，你的智能手机计算能力比它强几百万倍。我们拥有真正能让开发更容易的工具和框架。

然而，对软件的需求远超我们创造能力。每个组织需要的软件比能开发的还多，待办功能和新项目的积压增长速度超过开发团队的处理能力。

这种紧张关系——强大工具却不足以应对——让梦想保持活力。企业高管看到积压功能时会想：“一定有办法更快，让更多人参与。”这是合理的思路，也自然催生了对任何“让软件开发大众化”工具的热情。

问题是，软件开发的瓶颈并不是打字速度或语法知识，而是处理复杂性所需的思考。打字再快，也无法解决并发数据库更新的设计思考；语法更简单，也不能帮你推理安全问题。

那么，领导者应该如何运用这种认知？

对领导者的启示

理解这个模式能改变你评估新工具和方法的方式。当有人承诺业务用户无需开发者就能构建应用时，你可以理解他们的愿景，同时保持现实预期。

正确的问题不是：“这会让我们不再需要开发者吗？”

而是：

• 这能让开发者在处理复杂问题时更高效吗？

• 这能让我们更快地构建某些类型的解决方案吗？

• 这能减少重复性任务，让开发者专注于独特挑战吗？

• 团队是否需要学习新技能才能有效使用？

这些问题承认开发涉及不可简化的复杂性，同时对提供真正杠杆作用的工具保持开放态度。

模式揭示了问题的本质

五十年的循环教会我们一个基本道理：软件开发的挑战不是机械性的——不是打字太多、语法太复杂、步骤太多。COBOL 让语法可读，CASE 工具减少了输入，视觉工具消除了语法，AI 可以根据描述生成完整的函数。

每一次进步都解决了实际存在的痛点，但根本挑战依旧存在，因为它并非机械性的，而是智力性的。软件开发是“思考的可视化”。我们创造的产物——COBOL 程序、Delphi 表单、Python 脚本——是对复杂性进行思考的可见结果。

这种推理没有捷径，就像设计建筑或诊断病症一样。工具更好，经验丰富确实有帮助，但有人仍必须认真思考。

目光清醒地前行

新一波开发工具迟早会到来，有些能带来真正价值，有些则只是用新技术重复旧承诺。理解这个循环模式，能让你更有效地使用新工具。

使用 AI 助手，评估低代码平台，尝试新框架。但最重要的是投资于团队清晰思考复杂问题的能力——这才是限制因素，就像阿波罗计划时期一样。

登月之所以成功，是因为杰出的科学家们对极其复杂的挑战进行了周密的思考，考虑到了每一个细节。他们手写软件，因为这是当时可用的工具。如果有更好工具，他们会欣然使用，但工具无法消除思考复杂性的需求。

如今情况相同。我们有更好的工具——但思考仍不可或缺。

梦想的意义

或许，人们反复萌生 “替代开发者” 的想法并非谬误。这种执念更像是一种必要的乐观主义，持续推动着工具的迭代与创新。每一次尝试让开发更易上手，都会带来真正帮助。梦想可能未能按最初设想实现，但追求它本身创造了价值。

COBOL 没让业务分析师写程序，但让一代开发者有效构建了业务系统；CASE 工具没生成完整应用，但推进了视觉建模的思考；Visual Basic 没消除专业开发者，但让更多人能开发应用；AI 不会替代开发者，但会改变我们的工作方式。

这种模式之所以持续存在，因为梦想反映了真实需求。我们确实需要更快、更高效地创造软件，只是发现限制因素不是工具，而是我们要解决问题的复杂性。

理解这一点，不意味着拒绝新工具，而是要明确它们能提供什么，以及哪些永远需要人类判断。