为何自 1969 年起，我们每隔十年都试图取代开发者？

那个令所有人挫败的循环模式

每隔十年，行业里总会涌现出新的承诺：这一次，我们终于能把软件开发变得足够简单，不再需要那么多开发者了。从 COBOL 到人工智能（AI），这个模式周而复始。企业领导者们对迟缓的交付速度和高昂的成本日益焦虑，而开发者们则感到被误解、价值被低估。理解这一循环为何持续半个世纪之久，能让我们看清双方都需要了解的软件工作本质。

用 COBOL 到 AI 取代开发人员的重复梦想

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

1969 年，当尼尔·阿姆斯特朗踏上月球表面时，全世界见证了人类集智协作所能企及的高度。这项成就的背后，站着玛格丽特·汉密尔顿和她的团队。正是她们亲手编写了阿波罗的制导软件，通过缜密的审查捕捉关键错误，并最终证明了软件可以成为决定任务成败的核心要素。

阿波罗计划证明，软件开发对于实现那些看似不可能的目标至关重要。然而，它也揭示了一个在未来几十年将令企业领导者们倍感挫败的事实：编写软件需要极度专业的知识储备、高度的专注力以及大量的时间投入。于是，让软件开发变得更容易——即减少对这些昂贵专才的依赖——的梦想，几乎在同一时刻诞生了。

COBOL：业务人员将亲手编写程序

20 世纪 60 年代末至 70 年代，COBOL 语言应运而生，其名称便直白地宣示了目标：通用商业导向语言（Common Business-Oriented Language）。愿景清晰明了：让代码读起来像英语句子一样通顺，这样业务分析师就能自己编写程序，而不再需要专业的程序员。

“只要语法足够易读，任何懂业务的人都能写代码。”

这一愿景极具诱惑力。软件正逐渐成为业务运营的核心，而程序员依然是稀缺且昂贵的资源。COBOL 承诺要实现软件开发的“大众化”。

结果如何呢？COBOL 变成了另一种需要专业培训才能掌握的编程语言。那些尝试亲自编写 COBOL 程序的业务分析师很快发现，语法的易读性并不能消除逻辑、数据结构或系统设计的复杂性。一个新的群体——COBOL 程序员——应运而生，而那个“消灭专业开发者”的梦想依然未能实现。

当然，梦想并未消亡，它只是潜伏着，静待下一波技术浪潮的到来。

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

计算机辅助软件工程（CASE, Computer-Aided Software Engineering）工具在 20 世纪 80 年代带着巨大的光环登场。只需绘制流程图和实体关系图，工具就能生成可运行的代码。这一宣传理念引发了强烈共鸣：可视化设计显然比输入晦涩难懂的指令更直观。业务专家只需对流程建模，软件便会凭空而生。

各大机构纷纷斥巨资投入。供应商们信誓旦旦地承诺生产力将提升 10 倍甚至更多。然而，大多数 CASE 工具项目都步履维艰，最终惨淡收场。

生成的代码往往需要大量的人工干预修补，性能瓶颈频现。当生成的代码与可视化模型发生偏离时，系统的维护就成了噩梦。最为致命的是，绘制准确的图表所需的逻辑思维深度，与编程别无二致。工具改变了交互界面，却未能改变根本的挑战。

问题再次证明，它比解决方案更为顽固。

Visual Basic 和 Delphi：拖拽之间，大功告成

20 世纪 90 年代带来了一种不同的思路。微软的 Visual Basic 和 Borland 的 Delphi 极大地简化了用户界面的构建。将组件拖入窗体，设置属性，编写事件处理程序——突然之间，对于经验尚浅的开发者来说，构建 Windows 应用程序变得触手可及。

这一波浪潮取得了与 COBOL 或 CASE 工具截然不同的成功。这些开发环境承认编程知识仍是必需的，但它们大幅降低了准入门槛。更广泛的人群开始能够创建实用的应用程序。

然而，取代开发者的梦想依然挥之不去。“超级用户”和“公民开发者”将构建部门级应用的说法甚嚣尘上。人们设想，IT 部门只需专注于基础设施，而业务部门可以自行解决软件需求。

现实却更加微妙。简单的应用程序确实向更多人敞开了大门。但随着需求复杂度的攀升——与现有系统的集成、安全隐患的考量、高负载下的性能表现、长期的运维与迭代——对资深开发者的需求反而愈发凸显。这些工具扩大了软件编写者的群体，却未能消除构建大型系统所需的专业壁垒。

于是，这个循环伴随着我们进入了千禧年。

21 世纪及以后：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 不会取代开发者，但它将以深刻的方式重塑我们的工作形态。

这一模式之所以生生不息，是因为梦想折射出了一种合理的内在需求。我们确实渴求更快、更高效的软件构建之道。我们只是不断地发现，限制我们的从来不是手中的工具，而是我们试图解决的问题本身所固有的复杂性。

理解这一点，并不意味着要抗拒新工具。它意味着我们应在清晰认知的指引下使用它们——既明白它们能提供什么助力，也懂得什么环节将永远需要人类的智慧与判断。