本文来自微信公众号： InfoQ ，编译：宇琪、Tina，作者：宇琪、Tina，原文标题：《第三个软件黄金时代来了！软件工程宗师、70 岁 UML 之父发声：AI 自动化被严重夸大，Dario Amodei 又越界了》
每隔几十年，软件工程就会被宣告一次“已死”，或者“即将被自动化彻底取代”。类似的说法，我们其实早就听过很多次了。但如果这一次，并不是终结，而是另一种形态的软件工程“黄金时代”的开始呢？就像历史上多次发生过的那样。
最近，软件工程领域的奠基人物之一Grady Booch在播客节目中，与主持人Gergely Orosz细致分享了对自20世纪40年代以来计算领域三次“黄金时代”的理解，以及这些时代如何在各自的技术约束下应运而生。
这场对话之所以引发广泛关注，还有一个直接原因。在节目中，Booch正面评价了Anthropic CEO Dario Amodei最近引发巨大争议的判断——“软件工程将在12个月内被自动化”。他的结论明确：如果用一个技术性的词来形容，这个判断在根本上是错误的。
在Booch看来，这类说法混淆了“写代码”和“软件工程”本身，也忽略了一个反复在历史中出现的事实：工具会一次次改变，但软件工程真正要解决的难题，从来没有消失。恰恰相反，每一次“自动化恐慌”，最终都对应着一次更高抽象层级的到来，以及一个新的黄金时代的开启。
基于该播客视频，InfoQ进行了部分删改。
核心观点如下：
现代计算的许多成果，其实是织就于“悲伤的织机”之上。
软件是一个极其动态、流动且高度可塑的领域。一旦我们掌握了构建某类系统的方法，并形成了可复用的模式，便会迅速发现它们在经济上具有新的应用空间。
很多所谓的“职业危机叙事”，其实源于对行业的狭隘理解。真正发生的事情是：软件正在扩展到更广泛的人群中。非职业开发者将会写出更多软件，而这是极其积极的变化。
当你站在通往新事物的门槛上，可以选择凝视深渊、害怕坠落；也可以选择纵身一跃、展翅高飞。现在，就是该飞的时候。
第一个黄金时代：
算法抽象撑起的软件世界
Gergely：你曾多次提到，软件工程的整体演进，本质上是抽象层级不断提升的过程。你能否梳理一下其中几个关键的转折点，帮助我们理解这一脉络，并进一步说明AI在其中扮演的角色？
Grady：“软件工程”这一术语本身，其实出现得相当晚。最早明确使用这一说法的，通常被认为是Margaret Hamilton。当时她刚离开“载人轨道实验室”项目，转而参与阿波罗计划。在一个几乎完全由硬件与结构工程师构成的男性团队中，她是极少数的软件开发者之一。她希望用一个词来区分自己的工作，于是开始使用“软件工程师”这一称呼。
后来也有人沿用了这一说法，尤其是人们常提到的NATO软件工程会议。事实上，那次会议的召开比Margaret的工作还要晚几年，而“软件工程”这一命名本身也带有一定争议性，正如“人工智能”在其首次学术会议上所引发的争论一样。尽管如此，随着时间推移，这个词逐渐被接受并固定下来。
其核心含义在于：Margaret以及她的同时代人意识到，这是一种具有工程属性的活动。工程的本质在于，在各种静态与动态约束之间，构建尽可能合理的解决方案，而非追求完美。这一点与结构工程、电气工程或化学工程一致。
在软件领域，我们所面对的介质极其灵活、可塑、富有弹性，但约束同样真实存在。我们依然受制于物理定律，例如信息传输不可能超越光速；我们构建系统的规模受到硬件能力的限制；在算法层面，也存在根本性的边界。我们可能在理论上知道如何解决某些问题，比如对蜂窝通信至关重要的Viterbi算法，但在很长一段时间内，并不知道如何将其有效实现。快速傅里叶变换亦是如此：理论早已存在，但在具备可计算性之前，实际应用无法推进。
除了科学和计算层面的限制，人类因素同样重要。我是否能聚集足够的人来完成工作？能否有效组织团队？理想情况下，软件开发的最佳团队规模是零，其次是一人，但这显然并不现实。正因为这些系统在经济与社会层面具有长期且深远的影响，我们不能依赖个体，而必须让软件本身具备超越个人生命周期的能力。
随着软件逐渐渗透到社会结构的缝隙之中，法律问题随之而来，例如数字版权管理。但更为根本的是伦理问题：我们或许知道如何构建某些系统，但是否应该构建它们？这是否符合人类的价值与尊严？
正是这些科学、技术、人类与伦理层面的静态和动态力量，共同作用于软件工程师。工程师所做的，正是在多重约束之间取得平衡，并在一种极其美妙的媒介中构建系统。
软件工程的发展可以划分为不同的时代。最早的时候，几乎不存在“软件”这一概念。人们只是直接操作机器，硬件与软件之间并无明确界限。以ENIAC为例，在插线板上插拔线路是否算编程？可以算，但那并不是我们今天所理解的软件。
直到20世纪40年代末、50年代初，随着计算机形态的演进，人们才逐渐区分出软件这一独立存在。当时的软件几乎完全是定制化的，并且与特定机器紧密绑定。但软件本身的成本开始变得不可忽视。人们希望硬件不断升级，却不愿意因此放弃既有的软件投资，这促使了“软硬件解耦”这一关键问题的出现。值得注意的是，“数字化”这一术语直到20世纪40年代末才被提出，“软件”一词更是要到50年代才出现。软件作为一种独立实体被承认，其实就在我这一生中发生，这本身就令人震惊。
随着软件逐渐从硬件中解耦，Grace Hopper等人开始意识到，软件不仅是一种技术活动，也可以成为一门产业和制度。最早的软件主要以汇编语言形式存在，与具体机器高度耦合。到了20世纪60年代，IBM意识到可以构建一整套拥有统一指令体系的计算机架构，从而在升级硬件的同时保留软件资产。这一决定既是工程选择，也是商业和经济选择。一旦这一思路确立，软件需求迅速爆发，软件工程由此进入了第一个黄金时代。
在这一时期，软件成为一个独立产业，其核心挑战是“复杂性”。虽然以今天的标准看，当时的系统相对简单，但在那个时代，它们已经极难理解与构建。由于软件仍然高度贴近机器，最主要的抽象形式是算法抽象。计算机最初被用于数学运算，因此像Fortran这样的语言，本质上就是为了实现公式翻译。
Gergely：从时间线上看，这一代大致对应哪个阶段？
Grady：大约从20世纪40年代末持续到70年代末。这一时期的代表人物包括Ed Yourdon、Tom DeMarco、Larry Constantine等，实体关系模型等思想也在此时出现，并影响了数据领域。
这是一个极其活跃的阶段。流程图被发明出来，用于辅助系统设计；软件开发形成了分工体系，有系统分析人员、程序员、打孔员和计算机操作员。这种分工主要由经济因素驱动，当时机器的成本远高于人力成本，因此一切都围绕着如何最大化利用稀缺而昂贵的计算资源展开。
这一阶段的主要任务集中在数学计算和既有业务流程的自动化。例如会计、薪资等工作原本需要大量人工，通过软件不仅可以加速流程，还能提高精度。因此，当时绝大多数软件都是商业、数值和计算密集型系统。
在公众视野之外，国防、航空、气象和医疗等领域同样在推动关键创新。真正前沿的探索，往往发生在这些边缘领域，尤其是国防系统。冷战背景下，分布式、实时系统成为刚需。Whirlwind计算机、SAGE（半自动地面环境系统）等项目相继出现。SAGE系统的规模之大，据估计曾占用当时美国20%到30%的软件工程师资源。这是一个前所未有的工程规模，也标志着第一代软件工程黄金时代在边缘地带孕育出的深远影响。
Gergely：军事领域是当时软件研究和产业推进中最大的出资方，对吗？因为他们有这种现实需求。
Grady：确实如此。正因为当时存在明确而现实的威胁，军事领域不得不持续投入。因此，许多关键创新都发生在国防体系中。我在正在制作的一部计算机历史纪录片里用过一句话：计算机发展史中有两个最重要的驱动力，一个是商业，我们已经讨论过它的经济逻辑；另一个是战争。
现代计算的许多成果，其实是织就于“悲伤的织机”之上。我们今天习以为常的许多技术，例如互联网、微型化技术，几乎都源自政府资助，尤其是在冷战背景下。所以，从某种意义上说，我们确实“受益于”冷战。
为什么第一黄金时代走到了极限？
Gergely：那这一阶段仍然属于第一代软件工程的黄金时代吗？还是已经跨过去了？
Grady：这些事情依然发生在第一代黄金时代之中。当时的软件工程有一个相对清晰的“重心”，但在边缘地带也同时发生着大量推动行业演进的探索。在第一代软件工程黄金时代，软件的主要应用集中在数学计算和商业系统上，系统分解的核心方式是算法抽象，我们更多从过程和函数的角度理解世界，而非从数据或对象的角度出发。但在边缘领域，一些应用场景正在不断突破这一范式，例如对分布式系统的需求、多机协同的需求、实时系统的需求，以及对人机交互界面的需求。
今天我们所使用的图形用户界面，其源头可以追溯到Whirlwind和SAGE系统。当时最早的图形界面基于阴极射线管（CRT），这些探索并不处于当时软件开发的中心地带，却在后来产生了深远影响。这里的一个重要启示是：软件是一个极其动态、流动且高度可塑的领域。一旦我们掌握了构建某类系统的方法，并形成了可复用的模式，便会迅速发现它们在经济上具有新的应用空间。这正是软件工程第一个黄金时代的特征。
不过，到20世纪70年代末、80年代初，这一体系开始显现出裂痕。NATO举办的软件工程会议，是首次在公共层面清晰指出问题：NATO意识到自己面临严重的软件困境：对软件的需求几乎无穷无尽，但在质量和速度上，行业却无法有效交付。这便是后来被称为“软件危机”的背景。
Gergely：这场“软件危机”究竟指的是什么？人们当时具体在担忧什么？
Grady：软件已经被证明具有巨大的价值，也具备明确的经济激励，但整个行业无法以足够快的速度、足够高的质量，生产出足够规模的软件。
Gergely：也就是说，软件既昂贵、又缓慢，而且质量还不稳定？
Grady：还要再加上一点：需求极其旺盛。人们不断地说，“我们还需要更多软件”。这四个因素叠加在一起，构成了当时的危机。这与今天我们担心的隐私监控、系统崩溃等问题并不相同。每一个黄金时代所面对的“危机”，其性质都会发生变化。
Gergely：站在今天回看那个时代，真的很难想象当时的处境。
Grady：在当时，这种危机是真实而迫切的，同时也是一个令人兴奋的时代。软件作为一种高度灵活、可扩展的媒介，几乎只受限于我们的想象力。
再叠加上微型化技术的突破：集成电路的出现、Fairchild的诞生，以及硅谷的形成——这一切都源于晶体管技术。Fairchild的第一大客户其实是美国空军，用于导弹项目。早期硅谷生产的大部分晶体管，都被用于冷战相关计划。但正是这些需求，奠定了规模化生产的经济基础，继而催生了集成电路、个人计算机等一系列后续发展。
到了20世纪70年代末，软件危机已经非常明显。以美国政府为例，他们意识到自己正陷入“巴别塔”问题：军方系统中使用的编程语言多达一万四千种。即便以今天的标准来看，这个数字也极其惊人，更何况当时软件系统的规模远小于现在。JOVIAL、COBOL等语言被广泛使用，同时，ALGOL等语言推动了形式化方法的发展。在Dijkstra、Hoare等人的影响下，人们开始将数学严谨性引入编程语言研究，形式语言理论由此兴起。
正是在这一背景下，美国政府推动了Ada项目，最初由一个联合项目工作组发起，目标是减少语言数量，试图以一种统一语言取而代之。这背后汇聚了大量研究成果，例如抽象数据类型、信息隐藏、关注点分离，以及Knuth提出的文学化编程思想。Ada是一次试图在宏观层面整合这些理念的实践，这种规模的推动，只有当时的美国军方具备条件完成。
与此同时，贝尔实验室孕育出了C语言和Unix，这些成果同样极为关键。而在学术与产业的边缘，一位名叫Bjarne Stroustrup的研究者开始思考：是否可以将Simula中的面向对象思想引入C语言，以解决其固有缺陷。值得一提的是，Simula是最早的面向对象语言。这一切反映出一个更深层的变化：人们开始意识到，仅靠算法抽象已不足以应对复杂性，软件需要新的抽象方式：对象抽象。
有趣的是，这种“从过程看世界”与“从事物看世界”的分歧，早在柏拉图时代就已出现。柏拉图在其对话中探讨过，人们究竟应当以过程还是以对象来理解世界，“原子”这一概念本身就源自这一思想传统。换言之，抽象的选择并非新问题，只是被重新应用到了软件领域。
此外，函数式编程思想也在这一时期逐渐成形。Fortran的发明者在完成该语言后，转而探索以无状态数学函数为核心的编程范式。我曾在他去世前几个月采访过他，问他为何函数式编程始终未能成为主流。他的回答是：函数式编程让“难的事情变简单”，却让“简单的事情变得异常困难”。这也解释了为何它始终占据重要位置，却未成为主导范式。
至此，我们来到了第一代软件工程黄金时代的尾声，并逐步迈向第二代。推动这一转变的力量包括持续增长的系统复杂性、规模化开发的困难，以及在国防领域中对分布式系统价值的进一步认知。同时，微型化技术的成熟也催生了个人计算机的出现。
第二个黄金时代：
从“过程”到“对象”，软件开始变复杂
Gergely：这主要得益于晶体管和电子技术的突破，对吗？
Grady：正是如此。这是一个极具活力的时代。业余爱好者开始能够亲手组装计算机。在此前，这种规模的参与几乎是不可想象的。
Gergely：这是计算史上第一次，爱好者能够真正大规模参与进来吗？
Grady：是的。经济条件改善，加之军方推动的晶体管和集成电路生产，使得普通人能够获得这些元件。在硅谷，人们可以直接购买并实验这些技术。
“玩”在软件历史中始终扮演着重要角色。20世纪70年代末到80年代初，是一个高度实验性的时代。有一本书《What the Dormouse Said》指出，个人计算机的兴起与嬉皮士反主流文化密切相关。这是一种“权力下放”的精神，与Stewart Brand、Merry Pranksters等人物和社群紧密相连，也催生了早期的在线社区，如The WELL——后来我们称之为电子公告板系统。总的来说，70年代末到80年代初，是一个充满可能性的阶段，大量新的技术路径和思想在此时同时萌发。
当时我们逐渐意识到，软件工程正在发生一场重要转变：人们开始不再仅仅通过“过程”来理解世界，而是通过“对象”和“类”。与此同时，分布式系统的需求，以及构建愈发复杂系统的现实压力，共同形成了一场“完美风暴”，推动了软件工程的第二个黄金时代。
坦率地说，我正是在那个阶段进入这个领域的，只是恰好身处正确的时间和地点。那时我在范登堡空军基地工作，参与导弹系统和航天系统的相关项目，其中还包括一个设想中的军事航天飞机计划。那是一个非常有趣的地方，因为几乎每周都会有一到两次发射。你会跑出去看着火箭升空，感叹“太不可思议了”。
时间来到20世纪80年代末，世界已经为一种新的软件观念做好了准备，这就是面向对象编程与面向对象设计。与第一代软件工程相比，它最大的不同在于抽象层次的变化。我们不再只是把数据视为一片原始的数据湖，再用算法去操作它，而是将数据与行为整合到同一个概念之中，形成对象。这种方式极大地拓展了我们能构建的系统复杂度，奠定了许多重要软件的基础。
如果你去计算机历史博物馆看看MacWrite和MacPaint的源码，就会发现它们是用Object Pascal写成的，是我见过结构最优雅的软件之一。它们的设计严谨、组织清晰，其中许多设计决策至今仍然能在Photoshop等现代系统中看到延续。这本身也说明了软件生命周期的一个有趣事实。
从对象的视角理解软件，被证明是一种极为有效的方法，因为它为解决软件复杂性问题提供了全新的路径。正如第一黄金时代一样，第二黄金时代同样充满活力。20世纪80、90年代，涌现出一批重要人物，比如“三位一体”（我本人、Ivar Jacobson和Jim Rumbaugh），以及Peter Coad、Larry Constantine、Ed Yourdon等，共同推动了从“过程”转向“对象”的思考方式。当然，我们也犯过错误，例如一度过度强调继承，把它当成万能解法，这后来被证明并不完全正确。但从类和对象来理解世界的基本思想，最终被保留并沉淀下来。
与此同时，这也是一个经济层面的转折点。随着系统规模不断扩大，平台开始兴起。事实上，这在第一黄金时代就已有先例：人们反复构建相同的功能，于是开始将常用算法和过程打包复用，例如磁盘操作、终端输出、排序算法等。这些实践最终催生了软件共享的概念。在商业系统领域，IBM的SHARE用户组织便是典型代表，它是一个由客户自发组织、相互共享软件的社群。
Gergely：这是不是一种相对原始的“打包”方式？比如把排序算法或一些通用功能集中起来分发？
Grady：需要澄清的是，这并不是IBM官方在做，而是完全由用户社区推动的，这实际上是最早的开源软件形态之一。当时的软硬件经济结构也很不同，软件通常是随硬件免费提供的，直到20世纪60年代后期，IBM才意识到软件本身可以作为商品，开始将软硬件解耦并单独收费。
在更早的阶段，社区氛围非常开放，人们会说：“我写了这个工具，你拿去用吧。”这正是开源精神的雏形。类似的事情在第二黄金时代再次发生，只不过抽象层次更高了。人们开始共享库、组件和工具，比如驱动CRT显示器的程序。这些东西本身并不构成竞争优势，却极大地提升了构建复杂系统的能力。
在这种背景下，平台逐渐形成。随着库和组件规模不断扩大，分布式系统兴起，我们开始讨论“面向服务的架构”（SOA）。HTML和HTTP让信息交换成为可能，人们开始设想通过网络共享图像、消息乃至服务。SOAP等协议由此诞生，成为当今平台时代的前身。这些变化，正是在第二黄金时代为平台经济奠定基础。
Gergely：“平台”的兴起，具体是指什么？你如何定义平台？
Grady：AWS和Salesforce都是典型例子。这些平台就像一座座“经济城堡”，周围有护城河。平台方允许你付费跨过护城河，使用其能力，其前提是：如果你自己从头构建，成本会高得多。因此，在第二黄金时代，我们看到了SaaS类企业的兴起，因为某些软件的复杂性和成本已经高到足以支撑这种商业模式。进入90年代末、21世纪初，这是一个同样充满活力的阶段。互联网快速发展，软件开始真正渗透进社会的各个缝隙，成为文明基础设施的一部分。电子邮件就是一个典型例子。
Gergely：你什么时候有了第一个邮箱？
Grady：1987年，那时还是ARPANET。随着软件成为日常基础设施，第一黄金时代所担忧的许多问题逐渐“消失”了，不是被忽视，而是被内化进系统之中。优秀的技术会“蒸发”，成为空气的一部分。第二黄金时代，正是当今软件世界的根基。
2000年前后，互联网泡沫破裂，经济逻辑无法支撑此前的扩张，同时还发生了Y2K问题。事后看似乎“什么也没发生”，但那是因为无数工程师付出了巨大的努力，才避免了灾难，这正是“最好的技术你看不见”的典型例子。
Gergely：我还记得千年虫之前的紧张气氛，甚至有电影预言世界末日。结果什么都没发生，很多人因此不再相信这种预警。
第三个黄金时代：
不是AI时代，而是软件工程成熟期
Grady：此时，我想补充一条此前未展开的历史线索：AI。
AI的第一个黄金时代出现在20世纪40、50年代，以符号主义为核心，代表人物包括Herbert Simon、Newell和Minsky。当时也尝试过神经网络，比如用真空管实现的人工神经元，但由于算力和理论限制，最终失败，AI进入寒冬。第二个黄金时代出现在80年代，以规则系统和专家系统为代表，尽管硬件和架构有所进步，但仍然难以规模化，最终再次陷入停滞。
进入21世纪，我认为我们其实已经身处软件工程的第三个黄金时代。其标志在于抽象层次的再次跃迁：从单个程序，提升到平台级库、框架和服务。我们不再自己实现消息系统或数据管理，而是直接使用现成的平台能力。AI编程助手的出现，正是对这种复杂度增长的回应。它们并非偶然，而是第三黄金时代演进逻辑的自然结果。
当下的问题已经不同于前两代：软件规模空前庞大，安全、供应链攻击、系统信任成为核心议题；同时，软件巨头的重要性使其具备“系统性风险”；此外，技术伦理问题也被推到台前：我们能做到的事情，是否就意味着我们应该去做？
Gergely：很多人其实很少回头去想：这一切究竟是如何开始的，以及软件工程这门学科本身到底有多“年轻”。即便从70、80年这个尺度来看，它也不过勉强算是两代人的历史。
但我现在在行业里普遍感受到一种情绪，尤其是在最近这个阶段，很多软件工程师正在经历一种明显的“存在主义焦虑”。这种焦虑在这个冬歇期之后明显加速了。在冬歇期之前，AI和大语言模型主要还只是自动补全工具，偶尔能生成一些代码；但在冬歇期之后，新一代模型已经能写出质量相当高的代码，甚至到了我开始真正信任它们的程度。
从历史上看，写代码一直是一件困难的事情，我们往往需要多年训练才能熟练，真正做到优秀则更久。因此，现在很多人开始陷入一种深刻的不安：机器居然能写出如此好的代码，这到底是怎么在短短几个月内发生的？接下来会怎样？编码一直和软件工程高度绑定，但现在似乎不再如此了。从你的历史视角来看，你如何理解当下正在发生的事情？
Grady：这并不是软件工程师第一次经历这样的存在性危机。类似的焦虑在第一代、第二代软件工程时期都出现过。所以我的态度一直是：历史会重演，这一轮也终将过去。我经常对担忧的人说，不必恐慌，把注意力放在基本功上，因为那些能力不会消失。
我曾经见过Grace Hopper，正是她在20世纪50年代意识到，软件可以从硬件中抽象出来。这一思想在当时极具颠覆性，甚至引发了强烈反对。很多早期计算机工程师认为，如果不紧密依附硬件，就不可能写出高效的软件，他们担心这种做法会摧毁整个行业。事实证明，他们错了。
类似的争论后来也出现在Fortran出现时。有人坚信，人类手写的汇编代码一定比编译器生成的代码更高效，但随着抽象层级的提升，这种观点被一次次推翻。每一次抽象跃迁，都会让一部分既有技能失去中心地位，而这些变化往往正是由工程师自己推动的。
过去这种冲击没有引发如此剧烈的情绪，一个重要原因是：当时从业者规模很小，可能只有几千人；而今天，这个群体是数以百万计的。人们理所当然会问：那我怎么办？
我也经常被年轻工程师问到类似的问题：“我是不是选错了方向？”我的回答始终是：现在恰恰是进入软件行业的好时机。原因很简单，我们正在经历一次新的抽象层级跃迁，就像从机器语言到汇编语言，从汇编到高级语言，从高级语言到库和平台那样。
这种变化对我而言是极大的解放。我不再需要关注大量琐碎细节，但软件工程的基本原则依然存在。只要你是在构建需要长期维护、需要经得起时间考验的软件，这些能力就不可替代。
当然，如果你只是写一次性代码、写完就扔，那随便用什么工具都可以。我看到很多人正是用AI代理来完成这种“用完即弃”的自动化任务，这完全没问题，甚至非常有价值。
这让我想起早期个人计算机时代的“爱好者文化”。当年，许多原本与软件毫无关系的人开始自己写程序，产生了大量新想法。今天的情况极为相似。你可以用AI自动化一些过去经济上根本不值得做的事情，即便这些成果未必长期存在，但它们依然创造了价值。
Gergely：就像当年普通人可以买得起个人电脑一样，如今也有很多原本不在行业内的人开始写软件。我刚和楼上的邻居聊过，她是一名会计，但已经在用ChatGPT帮团队写代码，提高流程效率。
Grady：早期个人计算机时代，艺术家、游戏玩家纷纷涌入这一新媒介，创造了前所未有的活力，今天同样如此。很多所谓的“职业危机叙事”，其实源于对行业的狭隘理解。真正发生的事情是：软件正在扩展到更广泛的人群中。非职业开发者将会写出更多软件，而我认为这是极其积极的变化。就像当年的个人电脑反主流文化一样，历史正在重演。
Dario判断错在根上：
工具在变，软件工程的难题没变
Gergely：Anthropic的CEO Dario Amodei曾预测，大约90%的代码会由AI生成，当时听起来很夸张，但后来事实证明他并非完全错误。最近他又说了一句更令人不安的话：“软件工程将在12个月内被自动化”。考虑到编码只是软件工程的一部分，这个说法显得更加激进。你怎么看？
Grady：我有一两点要说。
首先，我用Claude，我用Anthropic的产品。我觉得它是我的首选系统。我用它来解决JavaScript、Swift、PHP（没错，甚至PHP）、还有Python的问题。我确实在用，而且它对我帮助很大——主要是因为我想用某些库：谷歌搜索太烂了，文档也很烂，所以我用这些agent加速对它们的理解。
但别忘了：我在这些领域里至少有一两年的经验——好吧，准确说是几十年——我理解基本原理。所以我才会说：基本功不会消失。这一点在任何工程学科里都成立：基本原理不会消失，变化的是我们使用的工具。
因此，Dario，我尊重你的表达，但也要认识到：他和我视角不同。他在带领一家公司，公司需要赚钱，他需要对利益相关方说话。所以他会说一些“耸动的”话。我记得他好像是在达沃斯讲的这些？
Gergely：对。
Grady：如果用一个“技术术语”来评价他的结论，那就是：它在根本上是错误的（profoundly wrong）。原因有几方面。
第一，我接受他的部分观点：它会加速某些事情。但它会消灭软件工程吗？不会。我认为他对“软件工程是什么”有根本误解。
回到我一开始说的：软件工程师是负责平衡各种力量的工程师。代码只是我们的一种机制，但不是驱动我们的唯一因素。而他或他同事讨论的那些东西，没有一个触及软件工程师必须面对的那些决策问题——那些都不在当前所谓“自动化”的范围之内。
他的工作主要聚焦在最低层的自动化——我会把它类比为当年编译器所做的事情。所以我说：这是一轮新的抽象层级上升。开发者们别害怕：工具在变，但问题并没有消失。
我反驳他的第二个理由是：像Cursor这类系统，大多训练在一组我们已经反复见过的题型上。这没问题。就像第一代、第一个黄金时代，我们也面对的是一组相对固定的问题，于是围绕它们建库。现在同样如此。
如果我要在CRUD之上搭一个UI，或者做一个偏Web的东西，当然可以做到。更重要的是，这种能力开始“下沉”——很多原本需要专业工程能力才能完成的事情，如今被更高层抽象直接交付给了更多人。多数人不会因此去做一门生意，当然也会有极少数人能把它做成产品。但关键在于：更高层抽象让他们能做以前做不到的事。
而Dario忽略了一点——我借用一句莎士比亚式的转述来讲：“计算世界里还有更多东西，超出你哲学所能梦到的范围。”计算世界远远不只是“可规模化的Web系统”那一块。我们今天确实把很多东西应用在这种以Web为中心的大规模系统上，我觉得这很好、很棒，但这也意味着：外面还有大量东西尚未被自动化。我们会不断把“边界/前沿”继续往外推。
我一开始讲那些故事，就是因为历史正在重复——或者有人说，历史在押韵。今天发生的现象本质相同，只是发生在不同的抽象层级上。
这是第一点：软件世界比他所看的更大，不仅是“软件密集型系统”，也不仅是他关注的那一小块。
第二点，如果你看这些agent主要处理的系统类型，它们本质上是在自动化那些我们反复见过、它们也在训练中反复学过的模式。模式本身就是一种新的抽象：它不只是单个算法或单个对象，而是由一群对象和算法组成的“社会”，彼此协作。
这些agent很擅长自动化“模式的生成”。我想做某种东西，我可以用英语描述——因为模式本来就是我们用自然语言来描述的。
所以这就是为什么我认为他错了。祝他好运。但我觉得这是一个更令人兴奋的时代，而不是一个需要在存在层面恐慌的时代。
我再讲一个关于“抽象层级上升”的故事。
英语是一种非常不精确的语言，充满歧义与细微差别。你可能会想：这种语言怎么可能成为“有用的语言”？答案是：我们作为软件工程师其实一直在这样做。
我去找一个人说：“我希望系统能做这件事，大概长这样。”然后给一些例子。我一直在做这个。然后会有人把它转成代码。也就是说，我们早就处在一个更高层抽象：我说“我想要它做什么”。
举个具体例子：我最近在用一个以前从没碰过的库——JavaScript的D3，它能做非常迷人的可视化。我去找了一个网站，叫Victorian Engineering Connections。那是个很可爱的小站，一个人给某个博物馆做的项目（叫Andrew）。你可以输入一个名字，比如George Boole，然后你能看到他的信息，还能看到围绕他的社交网络，你可以点进去探索，非常酷。
我当时想：“我也想要这种东西，但天哪，我根本不会做，怎么办？”他把代码给了我，我发现它用了D3。我对D3一无所知。于是我对Cursor说：“给我做一个最简单的版本：五个节点，展示出来。”这样我就能研究代码。
接着我又能继续说：“我真正想做的是这个。把节点做成某种样式，取决于它们的类型。”就像我对一个人类合作者提需求一样，我是在用英语表达我的需要，而现在我不必再为把它变成现实而苦苦劳作——我可以跟工具对话，让它帮我完成。
所以它缩短了“我想要什么”和“它能做到什么”之间的距离。我觉得这非常棒，这是一种突破。
但别忘了，我对Dario说过：这只在某些场景下有效——当我做的事情是别人已经做过成百上千次的那类事。按费曼（Feynman）的风格，他可能会说：“你自己去做，这才是你理解的唯一方式。”我的反应是：这没错，但世界上我好奇的东西太多了，我不可能全部都靠自己从零理解完。那就让工具替我做一部分吧——我来决定我想做什么。
所以我才说，这些工具就是一次新的抽象层级跃迁：它们在缩短我用英语说的需求，与最终落到编程语言之间的距离。
最后我还想说：什么语言既精确又足够表达，能用来构建“可执行的工件”？我们把它叫作编程语言。恰好，英语在某些条件下也足够“像一门编程语言”——有点像COBOL：如果我在一个结构足够清晰的领域里用足够明确的短语表达需求，它能给我一个“足够好”的解，而我作为懂基本功的人，可以再去推进、校正、清理这些细节。
这就是为什么基本功如此重要。
低垂的果实先被摘走：该往上爬了
Gergely：每一次抽象层级的跃迁，都会让一部分技能变得过时，同时催生对新技能的需求。比如从汇编语言过渡到更高级语言之后，熟悉某块硬件指令集、并针对其进行极致优化的能力，就被更高层次的抽象思维所取代。而在当下这次跃迁中，可以说我们正在进入一个“无需再亲手写代码，计算机会自动生成，我们只需检查和微调”的阶段。作为软件从业者，哪些技能会逐渐过时？又有哪些能力会变得更加重要？
Grady：如今的软件交付流水线比它本应具备的复杂得多，如果没有成熟的流水线，仅仅让一个系统跑起来都非常困难。而在Google、Stripe这样的公司内部，已经构建了规模庞大且高度定制化的基础设施体系。
正因如此，这里存在大量“低垂的果实”，非常适合被自动化取代。我并不需要人类去填补这些繁琐而边缘化的环节。在这些领域，我们很可能会看到智能代理的出现：当我需要在某个地区快速部署资源时，我并不想亲自编写那些复杂、混乱的代码，而是更愿意让代理系统来完成。这类工作在经济效率和安全性上都具有明显的自动化价值，因此确实会带来一部分岗位的消失。对应地，人们需要重新学习，转向更高层次的应用构建。
同样地，那些过去专注于开发某个iOS应用或具体前端产品的技能，也会面临岗位收缩。因为现在，很多事情只需通过提示就能完成。这并非坏事，它让新一代人能够完成过去只有专业工程师才能完成的工作，这正如个人电脑时代所发生的一切。
因此，人们应该做的不是抗拒变化，而是向上移动一个抽象层级，开始关注“系统”本身。我认为，当前的转变不再是从程序到应用，而是从应用到系统。新的技能重心在于：如何在大规模环境中管理复杂性，如何同时处理技术因素与人的因素。只要你具备这种系统性能力，你的工作不仅不会消失，反而会更加稀缺和值得被需要。
Gergely：你会建议学生、即将进入行业的新人，以及希望回过头来夯实基础的资深工程师，从哪些方面入手？
Grady：当我面对极其复杂的问题时，最常回归的，是系统理论。可以去读Herbert Simon和Allen Newell的研究成果，也可以关注圣塔菲研究所关于复杂性与系统的相关工作。这些系统理论的基本原理，为我构建下一代系统提供了稳固的支点。
我曾参与NASA火星任务的研究。当时的问题是：如何支持人类执行长期深空任务，并让机器人在火星表面自主运作。这本质上是一个系统工程问题，因为这些能力必须“具身”于航天器之中。而当今大量AI软件是去物理化的，它们与现实世界并无直接连接。
那段时间，我也在跟随多位神经科学家学习，试图理解大脑的结构。正是在这个过程中，我意识到系统工程中的某些结构模式，可以直接应用于超大规模系统的设计。比如Marvin Minsky提出的“心智社会”模型，本质上是一种多智能体系统架构，而今天我们才刚刚开始真正触及智能体编程的潜力。
类似的还有早期AI系统中提出的“黑板模型”“全局工作空间”，以及Rodney Brooks提出的次级控制架构，这些都受到生物系统的启发。生物系统本身具备高度有效的架构方式，即便没有中央控制，也能完成复杂行为。
因此，回到你的问题，我的建议是：从系统视角重新审视架构，从生物学、神经科学和真实世界的复杂系统中汲取灵感。很多问题其实早已被研究过，只是我们在新的语境下重新应用了它们，工程的基本原理并没有消失。
Gergely：回顾以往几次抽象层级跃迁和软件工程的黄金时代，那些在新时代初期脱颖而出、即便在旧时代并不出众的人，往往做对了什么？从历史中，你会给出怎样的建议？
Grady：正如我之前提到的，软件领域真正限制我们的，其实是想象力。当然，我们同时也受到物理规律、算法能力以及伦理约束的限制。但现在正在发生的是：许多开发过程中的摩擦、成本和阻力正在消失。这意味着，我们终于可以把更多注意力投入到想象力本身，去构建过去根本无法实现的事物。以前做不到，是因为无法组织足够的人力、无法承担成本、也无法获得全球性的影响力。而现在，这些限制正在被解除。
因此，你应该把这一切视为机会。对某些既得利益者而言，这可能是损失；但从整体来看，这是一次净增益。它解放了我们的想象力，让我们能够在现实世界中做出此前不可能实现的事情。这是一个令人兴奋、同时也令人恐惧的时代，但这正是应有的状态。当你站在通往新事物的门槛上，可以选择凝视深渊、害怕坠落；也可以选择纵身一跃、展翅高飞。现在，就是该飞的时候。
参考链接：
https://www.youtube.com/watch?v=OfMAtaocvJw