本文翻译自 The Eternal Promise: A History of Attempts to Eliminate Programmers，原载于 Hacker News。

回顾软件发展的历史，有一个模式始终如一地出现：简化软件创建、降低成本、最终完全消除对程序员需求的承诺。这不是一个新想法——自 1960 年代以来，这就是我们行业的核心追求。每一代人都相信自己正在见证前所未有的变革，但实际上，他们正在参与一个已经重复了六十多年的循环。

今天，当大语言模型（LLM）生成代码、AI 助手与开发者结对编程时，我们听到了熟悉的声音：编程即将终结、软件开发将平民化、很快任何人都能在不需要写一行代码的情况下构建复杂系统。这些说法值得审视，不是因为它们完全错误，而是因为它们与 1959 年、1973 年、1985 年和 2015 年的承诺如出一辙。理解这段历史对于任何试图理清我们真正所处位置和未来方向的人来说都至关重要。

原罪：COBOL 与业务用户的梦想

故事始于 1950 年代末，那时的编程确实是一项神秘的艺术。程序员使用汇编语言或机器代码编写程序，直接操作寄存器和内存地址。这项工作需要深厚的技术知识，而且速度极慢。企业需要软件，但理解业务问题的人很少懂计算机，而懂计算机的人很少理解业务问题。

Grace Hopper 和 CODASYL 委员会登场了。1959 年，他们创造了 COBOL（Common Business-Oriented Language，通用商业导向语言）。明确的目标是革命性的：创建一种如此接近英语的编程语言，以至于业务经理可以阅读它、理解它，甚至最终自己编写它。语法故意设计得冗长。COBOL 不使用晦涩的符号，而是使用 MOVE、ADD、MULTIPLY 和 PERFORM 这样的单词。一个程序读起来几乎像一份官僚备忘录。

营销信息很明确：COBOL 将消除专业程序员的瓶颈。业务分析师将编写自己的程序。技术专家的”祭司阶层”将被解散。软件创建将平民化。

结果并非如此。

COBOL 作为编程语言取得了惊人的成功。它成为全球银行、保险和政府系统的支柱。数十亿行 COBOL 代码今天仍在运行，处理着数万亿美元的交易。但 COBOL 并没有消除程序员。相反，它创造了一个新的职业——COBOL 程序员。这种语言是可读的，但编写正确、高效、可维护的 COBOL 仍然需要专业技能、对底层系统的深刻理解和多年的经验。

讽刺意味深远。一种旨在消除程序员需求的语言，成为计算机历史上最持久的就业创造者之一。今天，COBOL 程序员非常抢手，正是因为学习这门语言的人太少，而他们维护的系统太过关键而无法替换。

第一次 AI 寒冬：专家系统与 1970 年代的炒作周期

今天讨论 AI 的大多数人似乎没有意识到我们曾经来过这里。1960 年代和 1970 年代初，人们对人工智能的乐观情绪爆发，相比之下，当前的预测显得相当保守。

1965 年，AI 研究的创始人之一 Herbert Simon 预测，在二十年内，机器将能够完成人类能做的任何工作。1967 年，另一位 AI 先驱 Marvin Minsky 预测，在一代人的时间里，创造人工智能的问题将基本解决。资金大量涌入。政府机构，特别是美国的 DARPA，在 AI 研究上投入巨资。

软件开发的影响被认为是革命性的。如果机器能思考，它们当然能自己编程。研究人员致力于自动编程，即能够将自然语言规范转化为可工作代码的系统。专家系统承诺在基于规则的引擎中捕获人类专业知识，能够在没有人类干预的情况下做出决策和解决问题。

愿景是诱人的。用简单的英语描述你想要什么，计算机就会想出如何去做。编程将变成规范，而规范将变成对话。

到了 1970 年代中期，现实介入了。1973 年的 Lighthill 报告通过系统地揭示 AI 承诺与 AI 成就之间的差距，摧毁了英国的 AI 资金。该报告指出，在狭窄领域的早期成功创造了不切实际的期望。在玩具问题上有效的系统在现实世界的复杂性面前失败了。可能性的组合爆炸压倒了当时的计算资源。

随之而来的是第一次 AI 寒冬。资金崩溃。研究项目被取消。”人工智能”这个短语在某些圈子里变得令人尴尬。研究人员将他们的工作重新包装为专家系统、知识工程或计算智能，以与失信的炒作保持距离。

教训应该是清楚的：将人类意图转化为可工作的软件是根本困难的。自然语言规范与正确实现之间的差距不是一个可以解决的技术问题，而是一个反映人类交流和软件复杂性深层真理的概念挑战。

第四代语言：1980 年代的承诺

到 1980 年代初，一个新的希望出现了：第四代语言，或称 4GL。推理很诱人。汇编语言是第一代。FORTRAN 和 COBOL 是第二代。Pascal 和 C 等结构化语言是第三代。第四代将进一步抽象复杂性，允许非程序员通过高级声明而非过程代码创建应用程序。

FOCUS、NOMAD、Ramis，以及后来的 PowerBuilder 和 Microsoft Access 等产品承诺彻底改变软件开发。用户不再编写代码，而是通过图形界面定义数据结构、指定业务规则和设计屏幕。底层代码将自动生成。

营销材料与我们今天听到的关于无代码平台的说法惊人地相似。最终用户将构建自己的应用程序。IT 部门将变成促进者而非瓶颈。开发时间将减少十倍以上。

4GL 在某些领域取得了真正的成功。报告生成、简单数据库应用程序和部门工具使用这些技术构建得更快。特别是 Microsoft Access，使数百万用户能够在不需要传统编程的情况下创建功能性应用程序。

但基本承诺再次未能实现。复杂的应用程序仍然需要复杂的思考。当业务逻辑变得复杂、当性能很重要、当系统需要与其他系统集成时，4GL 显露了它们的局限性。生成的代码通常效率低下。定制很困难。而且 4GL 最复杂的用户不是业务分析师，而是既理解工具又理解底层原理的专业开发者。

模式重复了：承诺消除程序员的工具反而创造了新的编程工作类别。

CASE 工具与大教堂建造者

1980 年代末和 1990 年代初见证了计算机辅助软件工程（CASE）工具的兴起。愿景是全面的：使用图表和规范为整个系统建模，工具将生成完整的、可工作的应用程序。

公司在 CASE 工具套件上投资了数百万。会议召开了。方法论被开发出来。承诺是软件工程最终将成为真正的工程，具有可预测的结果、可重复的过程和从规范自动生成代码。

我记得那个时代。顾问们带着庞大的数据字典和实体关系图到达。项目会在建模阶段花费数月，产生详细的文档，旨在捕获每个需求和设计决策。然后代码生成阶段会将这些模型转化为工作系统。

现实令人失望。生成的代码通常臃肿且效率低下。随着需求变化，模型难以维护。基本问题仍然存在：把规范做对至少与直接编写代码一样困难。图表和模型只是另一种编程语言，只是恰好使用方框和箭头而不是文本。

到 1990 年代中期，CASE 工具已基本淡出主流。一些概念在 Rational Rose 等面向对象分析和设计工具中存活下来，但从规范自动生成代码的宏伟愿景已被证明是虚幻的。

第二次 AI 浪潮：专家系统重现

1980 年代还见证了第二波 AI 热潮，聚焦于专家系统。Inference Corporation、Intellicorp 和 Teknowledge 等公司承诺在基于规则的系统中捕获人类专业知识，这些系统可以做出与人类专家一样好的决策。

应用令人信服：医疗诊断、财务分析、设备配置，是的，还有自动编程。Digital Equipment Corporation 的 R1/XCON 系统取得了真正的成功，通过自动配置计算机系统为公司节省了数百万美元。

1982 年启动的日本第五代计算机项目，获得了政府的大量投资，旨在创建能够使用逻辑编程进行推理的计算机。明确的目标是跨越西方技术，创建能够进行自然语言理解、自动编程和人工智能的机器。

到 1990 年，第五代项目基本未能实现其目标。专家系统被证明是脆弱的，当遇到狭窄专业知识之外的情况时，会以意想不到的方式失败。随着系统的增长，维护规则库变得越来越困难。而知识获取的基本挑战——让人类专家以机器可以使用的形式表达他们的专业知识——被证明比预期的要困难得多。

第二次 AI 寒冬在 1990 年代初到来。资金再次崩溃。研究人员再次重新包装他们的工作。机器可以自己编程的基本承诺再次退入未来。

互联网时代：Web 开发与平民化梦想

1990 年代中期带来了万维网，随之而来的是简化软件创建的新希望。HTML 应该是如此简单，以至于任何人都可以构建网页。确实，数以百万计的人学会了只用一个文本编辑器和一些决心来创建基本网站。

但网络很快变得更加复杂。JavaScript 增加了交互性。CSS 增加了样式。服务器端编程变得必不可少。数据库支持内容。安全变得至关重要。性能变得具有竞争力。

回应是可预测的：承诺简化 Web 开发的新工具。Dreamweaver、FrontPage，以及后来的 WordPress 和 Wix 承诺任何人都可以在不需要编码的情况下构建专业网站。内容管理系统抽象掉了复杂性。

这些工具确实成功地将基本的网络存在带给非开发者。但专业的 Web 开发变得更加复杂，而不是更简单。单页应用程序、移动优先设计、渐进式 Web 应用和现代 JavaScript 生态系统的兴起创造了需要新类别专家的新复杂性层。

模式继续：简化基本任务的工具使更雄心勃勃的项目成为可能，这需要更复杂的技能，从而创造了对更专业开发者的需求。

模型驱动架构与 UML 梦想

2000 年代初见证了通过模型驱动架构（MDA）进行自动代码生成的另一次尝试。对象管理组织提出，可以通过自动化工具将平台无关的模型转换为平台特定的实现。

统一建模语言（UML）成为标准符号。Rational Rose、Together 和 Enterprise Architect 等工具承诺从 UML 图表生成完整的应用程序。愿景是熟悉的：在高级抽象层次上建模你的系统，让工具处理实现细节。

MDA 在专业领域取得了一些成功，特别是在模型到代码的映射很好理解且生成的代码不需要大量定制的情况下。但对于大多数应用程序来说，这种方法被证明很繁琐。维护模型和代码之间的同步很困难。模型本身变得复杂，需要专业技能来创建和维护。

到 2010 年代，MDA 已淡出主流实践，尽管其概念影响了现代代码生成和领域特定语言。

无代码和低代码的复兴

从 2015 年左右开始，新一代无代码和低代码平台出现了。Bubble、Webflow、Airtable、Zapier 和 Microsoft Power Platform 等名字承诺使公民开发者能够通过可视化界面和拖放组件构建应用程序。

营销呼应了每一代之前的承诺。业务用户将构建自己的应用程序。IT 积压将消失。数字化转型将加速。程序员将变得过时，或者至少不再那么必要。

无代码工具在它们的领域取得了真正的成功。与传统开发相比，简单应用程序、工作流自动化、基本网站和内部工具可以使用这些平台更快地构建。对于某些类别的问题，它们代表了真正的进步。

但模式仍然成立。复杂的应用程序仍然需要复杂的思考。当需求超出平台能力时，用户会遇到墙壁。与现有系统的集成通常很困难。大规模的性能具有挑战性。而且无代码平台最复杂的用户通常是理解底层原理的前开发者。

更重要的是，无代码并没有减少对传统开发者的需求。如果有的话，数字应用程序的爆炸增加了需求。软件开发商场继续增长，即使无代码平台激增。

大语言模型：当前的浪潮

这把我们带到了当下。GPT-4、Claude 和 Gemini 等大语言模型可以从自然语言描述生成功能性代码。GitHub Copilot 和类似工具实时协助开发者，建议补全并生成样板代码。改进是真实而令人印象深刻的。

预测也如往常一样大胆。编程工作将被消除。软件开发将平民化。任何人都可以通过用简单英语描述他们想要什么来构建复杂系统。

我们以前听过这些。1959 年的 COBOL。1973 年的专家系统。1985 年的 4GL。1995 年的 CASE 工具。2015 年的无代码。

这并不意味着当前的浪潮与以前的浪潮完全相同。大语言模型代表了真正的能力突破。它们可以执行以前技术无法完成的任务。它们生成的代码通常是正确和有用的。对熟练开发者的生产力改进是真实的。

但基本挑战保持不变：将人类意图转化为正确、高效、可维护、安全的软件是困难的。不是因为工具不足，而是因为问题本身就很复杂。

为什么承诺总是落空

理解为什么每一波简化工具都未能兑现承诺，需要审视软件开发本身的本质。

软件不仅仅是代码。它是对所有可能条件下行为的精确规范。当你说你想要一个简单的电子商务应用程序时，你隐含地指定了关于用户认证、支付处理、库存管理、运费计算、税费处理、错误恢复、可访问性、负载下的性能和安全防御攻击的数千个决策。这些决策大多数从高级描述中并不明显。

软件开发的困难部分从来不是输入代码。它一直是弄清楚软件到底应该做什么，并确保它在所有情况下实际上做到了这一点。这就是为什么规范语言和自动代码生成反复未能消除程序员：它们只是将复杂性从代码转移到规范，而规范至少同样困难。

此外，软件存在于生态系统中。它必须与其他软件集成，适应不断变化的需求，在不断发展的平台上运行，并服务于需求不断变化的用户。随着时间推移维护和发展软件需要超越任何规范语言或生成工具的理解。

最后，软件反映了人类关于权衡的决策。性能与可维护性。安全性与可用性。灵活性与简单性。这些决策需要无法自动化的判断，因为它们取决于因情况而异的背景、优先级和价值观。

实际上改变了什么

每一波简化工具确实改变了一些真实的东西，只是不是营销人员承诺的那样。

COBOL 没有消除程序员，但它确实使业务编程更加容易访问，并创造了一个巨大的产业。4GL 没有取代传统语言，但它们确实使某些类别应用程序的快速开发成为可能。无代码平台不会让开发者过时，但它们确实使非开发者能够创建有用的工具。

模式是一致的：新工具降低了简单任务的进入门槛，这增加了被创建的软件总量，这创造了对更复杂软件的需求，这创造了对更复杂开发者的需求。

这不是失败。这是技术演进的方式。每个抽象层都启用了新的能力。每个简化都启用了新的雄心。总体效果是积极的，即使具体预测被证明是错误的。

从历史中学习

当我们驾驭当前一波 AI 驱动的开发工具时，我们应该从这段历史中汲取什么？

首先，对极端预测的怀疑是必要的。声称编程将在几年内被消除的说法呼应了每个过去十年的说法。模式表明，这样的预测持续高估变革的步伐，低估挑战的复杂性。

其次，真正的改进是真实的。大语言模型确实为开发者提供了生产力提升。它们确实使某些任务更容易。因为以前的炒作周期失败而否定这些改进，与不加批判地接受最极端的预测一样错误。

第三，编程工作的性质将继续演变。正如 COBOL 程序员所做的工作与汇编语言程序员不同，Web 开发者所做的工作与 COBOL 程序员不同，未来的开发者将做与当前开发者不同的工作。工作会改变，但不会消失。

第四，人类技能仍然必不可少。理解需求、做出设计决策、调试意外行为、随着时间推移维护系统以及与利益相关者沟通，是每一波自动化都未能取代的技能。随着工具处理更多常规工作，这些技能可能变得更加重要，而不是更不重要。

第五，能够茁壮成长的开发者将是那些学会有效使用新工具，同时保持对底层原理深刻理解的人。工具来来去去，但关于算法、数据结构、系统设计和软件架构的基础知识在几代人中仍然有价值。

理解的持久价值

也许六十年来简化承诺最重要的教训是：没有理解的替代品。

每次成功使用 COBOL 都需要理解业务流程和数据管理。每次成功使用 4GL 都需要理解数据库和应用程序架构。每次成功使用无代码平台都需要理解工作流设计和系统集成。每次成功使用 AI 代码生成都需要理解软件原理、代码质量和系统设计。

工具会改变。语言会改变。平台会改变。但对深刻理解他们正在构建什么以及为什么的人的需求保持不变。

这不是系统中的错误。它反映了关于软件本质和问题解决本质的一些基本东西。软件是结晶的思想。创建好的软件需要好的思考。没有任何工具可以替代这一点。

用清醒的眼光展望未来

当我们展望未来时，软件简化的历史提供了一个有价值的视角。我们应该期望 AI 工具变得更加强大。我们应该期望革命性变化的新承诺。我们应该期望其中一些承诺以意想不到的方式实现，而另一些则未能达到炒作。

最重要的是，我们应该期望基本挑战仍然存在：构建可靠、高效、安全地做人们实际需要的事情的软件，在一个需求不断变化、系统必须以复杂方式协同工作的世界中。

那个挑战从来主要不是关于输入代码的困难。它一直是关于清晰思考、精确沟通和在不确定性下做出良好决策的困难。这些是人类技能，只要软件重要，它们就会保持价值。

未来的程序员可能直接编写更少的代码。他们可能在更高的抽象层次上工作。他们可能使用我们目前无法想象的工具。但他们仍将从事将人类意图转化为可工作软件的基本工作。而这项工作将继续需要没有任何工具尚未取代的技能、判断和理解。

历史表明，关于编程消亡的报道被大大夸大了，反复地，超过六十年。没有理由相信这次根本不同。有充分理由相信，那些投资于深刻理解的人将继续有价值，无论出现什么工具。

核心要点

1. 历史总是惊人地相似：从 COBOL 到 AI，每一代技术革新都伴随着”消除程序员”的承诺，但程序员这个职业不仅没有消失，反而不断演进壮大。

2. 工具改变的是工作方式，而非工作本身：新工具降低了简单任务的门槛，但同时也创造了对更复杂软件的需求，进而需要更专业的开发者。

3. 软件开发的本质是思考和决策：真正困难的部分从来不是写代码，而是理清需求、做出正确的架构决策、处理边界情况。这些需要人类的判断力。

4. 理解比工具更重要：工具会过时，但对算法、数据结构、系统设计的深刻理解是跨越时代的资产。

5. 对 AI 保持理性态度：既不要盲目否定 AI 带来的生产力提升，也不要轻信”编程已死”的极端预测。历史告诉我们，真相往往在两者之间。