Why We've Tried to Replace Developers Every Decade

本文探讨了软件开发领域一个持续了五十多年的现象：每隔十年左右，就会出现一种旨在简化或取代专业开发者工作的新技术或方法。从 1960-70 年代的 COBOL 语言，到 1980 年代的计算机辅助软件工程工具，再到 1990 年代的 Visual Basic 和 Delphi，以及 2000 年代以来的各种低代码/无代码平台和如今的 AI 编码助手，这个循环不断重演。尽管这些工具每次都承诺能让业务人员直接编写程序，从而减少对专业开发者的依赖，但最终结果都未能完全实现这一目标。

作者指出，这个模式之所以反复出现，是因为人们误以为软件开发的复杂性主要来自语法或编码过程本身。然而，真正的复杂性在于处理业务逻辑的细节、边缘情况、系统集成、安全性和长期维护等需要深度思考的问题。无论是用 COBOL、可视化工具还是 AI 提示，都无法消除这种固有的逻辑复杂性。

文章的核心观点是，这些新技术工具真正带来的价值并非取代开发者，而是让他们能更高效地工作，将精力从重复性劳动中解放出来，专注于解决更独特的挑战。AI 也不例外，它改变了开发者工作的方式，但并未消除对人类判断力的需求。

最后，作者为领导者提供了建议：与其期待新工具能彻底解决问题，不如提出更务实的问题，例如它能否帮助团队更有效地处理复杂问题，或减少重复性工作。投资于培养开发者清晰思考复杂问题的能力，才是长久之计。这个不断重现的“取代梦”本身并非错误，它反映了对更高效软件创建方式的真实需求，并持续推动着工具的创新和进步。

持续半个世纪的“取代开发者”之梦

从 1969 年阿波罗登月计划证明软件的极端重要性开始，一个困扰商业领袖的悖论也随之诞生：软件开发至关重要，但它却依赖昂贵且稀缺的专业人才。于是，一个梦想应运而生——让软件开发变得足够简单，以至于不再需要这么多专业开发者。

这个梦想在过去五十年里，以不同的技术形式反复出现：

COBOL 语言 (1960-70年代)：其设计初衷是“面向业务的通用语言”，希望通过接近英语的语法，让业务分析师直接编写程序，从而摆脱对专业程序员的依赖。然而事实证明，可读的语法并未消除程序逻辑和系统设计的复杂性，最终COBOL只是成为了另一门需要专门学习的编程语言。
计算机辅助软件工程工具 (1980年代)：这些工具承诺通过绘制流程图和图表，即可自动生成完整代码。尽管企业大力投资，但多数项目以失败告终。生成的代码难以维护，性能问题频出，最重要的是，绘制精确的图表本身就需要理解编程所涉及的同样复杂的逻辑。
Visual Basic 和 Delphi (1990年代)：这些工具通过“拖放”组件的方式，极大简化了用户界面构建，降低了入门门槛，让更多人能创建简单应用。但当应用需要处理复杂的系统集成、安全、性能及长期维护时，经验丰富的开发者仍然不可或缺。
21世纪以来的新技术：无论是 Ruby on Rails 等 Web 框架，还是低代码/无代码平台，甚至是今天的 AI 编码助手，都沿着相似的轨迹演进。它们都在特定领域提升了开发效率，让更多人能参与到软件构建中，但专业开发者的需求不降反升，且技能要求更高。

梦想不灭的根源：误判了复杂性的本质

这个循环之所以不断重演，根源在于我们对“复杂性”的误判。从表面看，用自然语言描述一个业务需求（如“客户下单后，检查库存、计算运费、处理支付、发送确认邮件”）似乎很简单，软件工具理应能理解并执行。

然而，真正的复杂性隐藏在这些描述的“细节”之中：

库存被其他订单暂时占用怎么办？
如何处理部分付款？
邮件服务临时不可用，系统应重试几次？间隔多久？
客户在结账过程中会话过期怎么办？
如何防止产生重复订单？

每一个问题的答案都可能引出更多新的问题。所有这些关于决策、边缘情况和系统交互的思考，共同构成了软件开发的真正核心。这种逻辑复杂性是任何工具、语言或平台都无法消除的。有人必须去思考和定义这些场景，而这个过程本身就是软件开发，无论它使用的是什么表达方式。

这正是软件开发的悖论所在：尽管工具不断进步，计算能力飞速增长，但社会对软件的需求增长得更快。每个组织都积压着远超出其开发能力的软件需求。这种“强大工具与有限能力”之间的持续张力，使得商业领袖们总是渴望寻找能进一步提速、让更多人参与开发的“银弹”。

领导者的正确应对：拥抱工具，投资思维

理解这个持续五十年的模式，能帮助领导者以更现实的视角来评估和接纳新技术。当面对一个声称能让业务人员无需开发者即可构建应用的新平台时，正确的反应不是问“这能帮我们省掉多少开发者？”，而是提出一系列更务实的问题：

赋能而非取代：这个工具能否帮助我们的开发者更有效地处理复杂问题？
加速特定场景：它能否让我们更快地构建特定类型的解决方案？
解放重复劳动：它是否能减少花在重复性任务上的时间，让开发者专注于更独特的挑战？
技能要求：我们的团队需要学习哪些新技能才能有效使用它？

这些问题承认了软件开发中固有的复杂性，同时对能提供真正助力的工具保持开放。这个持续不断的“取代梦”本身并非毫无意义，它反映了对更高效软件创建方式的真实需求。正是这种乐观的追求，推动了一代又一代工具的诞生和进步。

COBOL 没能让业务分析师编程，但它让一代开发者能高效地构建商业系统。CASE 工具没能完全自动化应用开发，但它深化了我们对可视化建模的理解。Visual Basic 没有淘汰专业开发者，但它让应用开发惠及了更多人。同样，AI 不会取代开发者，但它将深刻改变我们的工作方式。

最终，投资的重点应始终放在提升开发者“清晰思考复杂问题”的能力上。无论是阿波罗计划的手写代码，还是今天借助AI辅助编程，工具在变，但思考并驾驭复杂性的核心能力，始终是软件开发领域最稀缺、最宝贵的资源。

问答

问：文章指出的“每十年一次试图取代开发者”的模式具体是怎样的？ 答：这个模式是指，每隔十年左右，就会出现一种新的技术或工具（如 COBOL、CASE工具、Visual Basic、低代码平台、AI），它们最初都被寄予厚望，认为能让软件开发变得极其简单，以至于业务人员或其他非技术人员可以直接创建软件，从而大幅减少甚至消除对专业软件开发者的需求。然而，尽管这些工具带来了真实进步，但最终都未能完全实现取代专业开发者的承诺，专业开发者依然不可或缺。

问：为什么这些试图“取代开发者”的努力总是无法完全成功？ 答：因为这些努力都误判了软件开发复杂性的根源。人们通常认为复杂性来自繁琐的语法或编码过程，而新技术正是为了解决这些问题。但实际上，软件开发的真正复杂性在于处理业务逻辑的细节、无数的边缘情况、系统间集成、安全性、性能以及长期维护等需要深度思考和判断的问题。这种逻辑上的复杂性是任何工具都无法消除的，必须由具备专业知识和经验的人来处理。

问：文章认为像 AI 这样的最新技术，对开发者的真正价值是什么？ 答： AI 的真正价值不在于取代开发者，而在于“赋能”和“提效”。AI 编码助手可以帮助开发者生成代码框架、解释现有代码、辅助调试，从而减少他们在重复性、模式化任务上的时间投入。这改变了开发者工作的方式，让他们能将更多精力集中在解决更独特、更复杂的业务和技术挑战上，放大和增强了开发者的能力。

问：根据文章的分析，企业领导者应该如何正确看待和使用新的软件开发工具？ 答：领导者应该摒弃寻找“银弹”来彻底解决问题的想法，转而提出更现实的问题：

这个工具能否帮助我们的开发者更有效地处理复杂问题？
它能否加速特定类型解决方案的构建？
它能否将开发者从重复劳动中解放出来，让他们专注于更有价值的工作？
我们的团队需要学习哪些新技能才能用好它？

问：这篇文章对于“软件开发的本质”给出了什么核心见解？ 答：文章的核心见解是：软件开发是将无形的、关于复杂性的思考，转化为有形的代码产物的过程。代码只是思考结果的呈现形式。无论工具如何进化，从手写代码到AI生成，这个“思考”的过程——即分析问题、拆解细节、权衡决策、预见风险——是无法被简化的核心环节。因此，培养和投资于开发者清晰思考复杂问题的能力，是应对未来挑战的不变法则。