每隔幾十年，軟體工程就會被宣告一次「已死」，或者「即將被自動化徹底取代」。類似的說法，我們其實早就聽過很多次了。但如果這一次，並不是終結，而是另一種形態的軟體工程「黃金時代」的開始呢？就像歷史上多次發生過的那樣。
最近，軟體工程領域的奠基人物之一 Grady Booch 在 Podcast 節目中，與主持人 Gergely Orosz 細緻分享了對自 1940 年代以來運算領域三次「黃金時代」的理解，以及這些時代如何在各自的技術限制下應運而生。
這場對話之所以引發廣泛關注，還有一個直接原因。在節目中，Booch 正面評價了 Anthropic CEO Dario Amodei 最近引發巨大爭議的判斷——「軟體工程將在 12 個月內被自動化」。他的結論明確：如果用一個技術性的詞來形容，這個判斷在根本上是錯誤的。
在 Booch 看來，這類說法混淆了「寫程式碼」和「軟體工程」本身，也忽略了一個反覆在歷史中出現的事實：工具會一次次改變，但軟體工程真正要解決的難題，從來沒有消失。恰恰相反，每一次「自動化恐慌」，最終都對應著一次更高抽象層級的到來，以及一個新的黃金時代的開啟。
基於該 Podcast 影片，InfoQ 進行了部分刪改。
核心觀點如下：
現代運算的許多成果，其實是織就於「悲傷的織機」之上。
軟體是一個極其動態、流動且高度可塑的領域。一旦我們掌握了建構某類系統的方法，並形成了可重複使用的模式，便會迅速發現它們在經濟上具有新的應用空間。
很多所謂的「職業危機敘事」，其實源於對產業的狹隘理解。真正發生的事情是：軟體正在擴展到更廣泛的人群中。非職業開發者將會寫出更多軟體，而這是極其正面的變化。
當你站在通往新事物的門檻上，可以選擇凝視深淵、害怕墜落；也可以選擇縱身一躍、展翅高飛。現在，就是該飛的時候。
Gergely：你曾多次提到，軟體工程的整体演進，本質上是抽象層級不斷提升的過程。你能否梳理一下其中幾個關鍵的轉折點，幫助我們理解這一脈絡，並進一步說明 AI 在其中扮演的角色？
Grady：「軟體工程」這個術語本身，其實出現得相當晚。最早明確使用這一說法的，通常被認為是 Margaret Hamilton。當時她剛離開「載人軌道實驗室」計畫，轉而參與阿波羅計畫。在一個幾乎完全由硬體與結構工程師構成的男性團隊中，她是極少數的軟體開發者之一。她希望用一個詞來區分自己的工作，於是開始使用「軟體工程師」這一稱呼。
後來也有人沿用了這一說法，尤其是人們常提到的 NATO 軟體工程會議。事實上，那場會議的召開比 Margaret 的工作還要晚幾年，而「軟體工程」這一命名本身也帶有一定爭議性，正如「人工智慧」在其首次學術會議上所引發的爭論一樣。儘管如此，隨著時間推移，這個詞逐漸被接受並固定下來。
其核心含義在於：Margaret 以及她的同時代人意識到，這是一種具有工程屬性的活動。工程的本質在於，在各種靜態與動態限制之間，建構盡可能合理的解決方案，而非追求完美。這一點與結構工程、電機工程或化學工程一致。
在軟體領域，我們所面對的介質極其靈活、可塑、富有彈性，但限制同樣真實存在。我們依然受限於物理定律，例如資訊傳輸不可能超越光速；我們建構系統的規模受到硬體能力的限制；在演算法層面，也存在根本性的邊界。我們可能在理論上知道如何解決某些問題，比如對蜂巢通訊至關重要的 Viterbi 演算法，但在很長一段時間內，不知道如何將其有效實現。快速傅立葉轉換亦是如此：理論早已存在，但在具備可計算性之前，實際應用無法推進。
除了科學和運算層面的限制，人類因素同樣重要。我是否能聚集足夠的人來完成工作？能否有效組織團隊？理想情況下，軟體開發的最佳團隊規模是零，其次是一人，但這顯然並不現實。正因為這些系統在經濟與社會層面具有長期且深遠的影響，我們不能依賴個人，而必須讓軟體本身具備超越個人生命週期的能力。
隨著軟體逐漸滲透到社會結構的縫隙之中，法律問題隨之而來，例如數位版權管理。但更為根本的是倫理問題：我們或許知道如何建構某些系統，但是否應該建構它們？這是否符合人類的價值與尊嚴？
正是這些科學、技術、人類與倫理層面的靜態和動態力量，共同作用於軟體工程師。工程師所做的，正是在多重限制之間取得平衡，並在一種極其美妙的媒介中建構系統。
軟體工程的發展可以劃分為不同的時代。最早的時候，幾乎不存在「軟體」這一概念。人們只是直接操作機器，硬體與軟體之間並無明確界限。以 ENIAC 為例，在插線板上插拔線路是否算程式設計？可以算，但那並不是我們今天所理解的軟體。
直到 1940 年代末、1950 年代初，隨著電腦形態的演進，人們才逐漸區分出軟體這一獨立存在。當時的軟體幾乎完全是客製化的，並且與特定機器緊密綁定。但軟體本身的成本開始變得不可忽視。人們希望硬體不斷升級，卻不願意因此放棄既有的軟體投資，這促使了「軟硬體解耦」這一關鍵問題的出現。值得注意的是，「數位化」這一術語直到 1940 年代末才被提出，「軟體」一詞更是要到 1950 年代才出現。軟體作為一種獨立實體被承認，其實就在我這一生中發生，這本身就令人震驚。
隨著軟體逐漸從硬體中解耦，Grace Hopper 等人開始意識到，軟體不僅是一種技術活動，也可以成為一門產業和制度。最早的軟體主要以組合語言形式存在，與具體機器高度耦合。到了 1960 年代，IBM 意識到可以建構一整套擁有統一指令體系的電腦架構，從而在升級硬體的同時保留軟體資產。這一決定既是工程選擇，也是商業和經濟選擇。一旦這一思路確立，軟體需求迅速爆發，軟體工程由此進入了第一個黃金時代。
在這一時期，軟體成為一個獨立產業，其核心挑戰是「複雜性」。雖然以今天的標準看，當時的系統相對簡單，但在那個時代，它們已經極難理解與建構。由於軟體仍然高度貼近機器，最主要的抽象形式是演算法抽象。電腦最初被用於數學運算，因此像 Fortran 這樣的語言，本質上就是為了實現公式翻譯。
Gergely：從時間線上看，這一代大致對應哪個階段？
Grady：大約從 1940 年代末持續到 1970 年代末。這一時期的代表人物包括 Ed Yourdon、Tom DeMarco、Larry Constantine 等，實體關聯模型等思想也在此時出現，並影響了資料領域。
這是一個極其活躍的階段。流程圖被發明出來，用於輔助系統設計；軟體開發形成了分工體系，有系統分析人員、程式設計師、打孔員和電腦操作員。這種分工主要由經濟因素驅動，當時機器的成本遠高於人力成本，因此一切都圍繞著如何最大化利用稀缺而昂貴的運算資源展開。
這一階段的主要任務集中在數學運算和既有業務流程的自動化。例如會計、薪資等工作原本需要大量人工，透過軟體不僅可以加速流程，還能提高精確度。因此，當時絕大多數軟體都是商業、數值和運算密集型系統。
在公眾視野之外，國防、航空、氣象和醫療等領域同樣在推動關鍵創新。真正前沿的探索，往往發生在這些邊緣領域，尤其是國防系統。冷戰背景下，分散式、即時系統成為剛需。Whirlwind 電腦、SAGE（半自動地面環境系統）等計畫相繼出現。SAGE 系統的規模之大，據估計曾占用當時美國 20% 到 30% 的軟體工程師資源。這是一個前所未有的工程規模，也標誌著第一代軟體工程黃金時代在邊緣地帶孕育出的深遠影響。
Gergely：軍事領域是當時軟體研究和產業推進中最大的出資方，對嗎？因為他們有這種現實需求。
Grady：確實如此。正因為當時存在明確而現實的威脅，軍事領域不得不持續投入。因此，許多關鍵創新都發生在國防體系中。我正在製作一部電腦歷史紀錄片，裡面用過一句話：電腦發展史中有兩個最重要的驅動力，一個是商業，我們已經討論過它的經濟邏輯；另一個是戰爭。
現代運算的許多成果，其實是織就於「悲傷的織機」之上。我們今天習以為常的許多技術，例如網際網路、微縮技術，幾乎都源自政府資助，尤其是在冷戰背景下。所以，從某種意義上說，我們確實「受益於」冷戰。
Gergely：那這一階段仍然屬於第一代軟體工程的黃金時代嗎？還是已經跨過去了？
Grady：這些事情依然發生在第一代黃金時代之中。當時的軟體工程有一個相對清晰的「重心」，但在邊緣地帶也同時發生著大量推動產業演進的探索。在第一代軟體工程黃金時代，軟體的主要應用集中在數學運算和商業系統上，系統分解的核心方式是演算法抽象，我們更多從過程和函數的角度理解世界，而非從資料或物件的角度出發。但在邊緣領域，一些應用場景正在不斷突破這一範式，例如對分散式系統的需求、多機協同的需求、即時系統的需求，以及對人機互動介面的需求。
今天我們所使用的圖形使用者介面，其源頭可以追溯到 Whirlwind 和 SAGE 系統。當時最早的圖形介面基於陰極射線管（CRT），這些探索並不處於當時軟體開發的中心地帶，卻在後來產生了深遠影響。這裡的一個重要啟示是：軟體是一個極其動態、流動且高度可塑的領域。一旦我們掌握了建構某類系統的方法，並形成了可重複使用的模式，便會迅速發現它們在經濟上具有新的應用空間。這正是軟體工程第一個黃金時代的特徵。
不過，到 1970 年代末、1980 年代初，這一體系開始顯現出裂痕。NATO 舉辦的軟體工程會議，是首次在公共層面清晰指出問題：NATO 意識到自己面臨嚴重的軟體困境：對軟體的需求幾乎無窮無盡，但在品質和速度上，產業卻無法有效交付。這便是後來被稱為「軟體危機」的背景。
Gergely：這場「軟體危機」究竟指的是什麼？人們當時具體在擔憂什麼？
Grady：軟體已經被證明具有巨大的價值，也具備明確的經濟誘因，但整個產業無法以足夠快的速度、足夠高的品質，生產出足夠規模的軟體。
Gergely：也就是說，軟體既昂貴、又緩慢，而且品質還不穩定？
Grady：還要再加上一點：需求極其旺盛。人們不斷地說，「我們還需要更多軟體」。這四個因素疊加在一起，構成了當時的危機。這與今天我們擔心的隱私監控、系統當機等問題並不相同。每一個黃金時代所面對的「危機」，其性質都會發生變化。
Gergely：站在今天回看那個時代，真的很難想像當時的處境。
Grady：在當時，這種危機是真實而迫切的，同時也是一個令人興奮的時代。軟體作為一種高度靈活、可擴展的媒介，幾乎只受限於我們的想像力。
再疊加上微縮技術的突破：積體電路的出現、Fairchild 的誕生，以及矽谷的形成——這一切都源自電晶體技術。Fairchild 的第一大客戶其實是美國空軍，用於飛彈計畫。早期矽谷生產的大部分電晶體，都被用於冷戰相關計畫。但正是這些需求，奠定了規模化生產的經濟基礎，繼而催生了積體電路、個人電腦等一系列後續發展。
到了 1970 年代末，軟體危機已經非常明顯。以美國政府為例，他們意識到自己正陷入「巴別塔」問題：軍方系統中使用的程式語言多達一萬四千種。即便以今天的標準來看，這個數字也極其驚人，更何況當時軟體系統的規模遠小於現在。JOVIAL、COBOL 等語言被廣泛使用，同時，ALGOL 等語言推動了形式化方法的發展。在 Dijkstra、Hoare 等人的影響下，人們開始將數學嚴謹性引入程式語言研究，形式語言理論由此興起。
正是在這一背景下，美國政府推動了 Ada 計畫，最初由一個聯合專案工作小組發起，目標是減少語言數量，試圖以一種統一語言取而代之。這背後匯聚了大量研究成果，例如抽象資料型別、資訊隱藏、關注點分離，以及 Knuth 提出的文學化程式設計思想。Ada 是一次試圖在宏觀層面整合這些理念的實踐，這種規模的推動，只有當時的美國軍方具備條件完成。
與此同時，貝爾實驗室孕育出了 C 語言和 Unix，這些成果同樣極為關鍵。而在學術與產業的邊緣，一位名叫 Bjarne Stroustrup 的研究者開始思考：是否可以將 Simula 中的物件導向思想引入 C 語言，以解決其固有缺陷。值得一提的是，Simula 是最早的物件導向語言。這一切反映出一個更深層的變化：人們開始意識到，僅靠演算法抽象已不足以應對複雜性，軟體需要新的抽象方式：物件抽象。
有趣的是，這種「從過程看世界」與「從事物看世界」的分歧，早在柏拉圖時代就已出現。柏拉圖在其對話錄中探討過，人們究竟應當以過程還是以物件來理解世界，「原子」這一概念本身就源自這一思想傳統。換言之，抽象的選擇並非新問題，只是被重新應用到了軟體領域。
此外，函數式程式設計思想也在這一時期逐漸成形。Fortran 的發明者在完成該語言後，轉而探索以無狀態數學函數為核心的程式設計範式。我曾在他去世前幾個月採訪過他，問他為何函數式程式設計始終未能成為主流。他的回答是：函數式程式設計讓「難的事情變簡單」，卻讓「簡單的事情變得異常困難」。這也解釋了為何它始終占據重要位置，卻未成為主導範式。
至此，我們來到了第一代軟體工程黃金時代的尾聲，並逐步邁向第二代。推動這一轉變的力量包括持續增長的系統複雜性、規模化開發的困難，以及在國防領域中對分散式系統價值的進一步認知。同時，微縮技術的成熟也催生了個人電腦的出現。
Gergely：這主要得益於電晶體和電子技術的突破，對嗎？
Grady：正是如此。這是一個極具活力的時代。業餘愛好者開始能夠親手組裝電腦。在此前，這種規模的參與幾乎是無法想像的。
Gergely：這是運算史上第一次，愛好者能夠真正大規模參與進來嗎？
Grady：是的。經濟條件改善，加上軍方推動的電晶體和積體電路生產，使得普通人能夠獲得這些元件。在矽谷，人們可以直接購買並實驗這些技術。
「玩」在軟體歷史中始終扮演著重要角色。1970 年代末到 1980 年代初，是一個高度實驗性的時代。有一本書《What the Dormouse Said》指出，個人電腦的興起與嬉皮士反主流文化密切相關。這是一種「權力下放」的精神，與 Stewart Brand、Merry Pranksters 等人物和社群緊密相連，也催生了早期的線上社群，如 The WELL——後來我們稱之為電子佈告欄系統。總的來說，1970 年代末到 1980 年代初，是一個充滿可能性的階段，大量新的技術路徑和思想在此時同時萌發。
當時我們逐漸意識到，軟體工程正在發生一場重要轉變：人們開始不再僅僅透過「過程」來理解世界，而是透過「物件」和「類別」。與此同時，分散式系統的需求，以及建構日益複雜系統的現實壓力，共同形成了一場「完美風暴」，推動了軟體工程的第二個黃金時代。
坦率地說，我正是在那個階段進入這個領域的，只是恰好身處正確的時間和地點。那時我在范登堡空軍基地工作，參與飛彈系統和航太系統的相關專案，其中還包括一個設想中的軍事太空飛機計畫。那是一個非常有趣的地方，因為幾乎每週都會有一到兩次發射。你會跑出去看著火箭升空，感嘆「太不可思議了」。
時間來到 1980 年代末，世界已經為一種新的軟體觀念做好了準備，這就是物件導向程式設計與物件導向設計。與第一代軟體工程相比，它最大的不同在於抽象層次的變化。我們不再只是把資料視為一片原始的資料湖，再用演算法去操作它，而是將資料與行為整合到同一個概念之中，形成物件。這種方式極大地拓展了我們能建構的系統複雜度，奠定了許多重要軟體的基礎。
如果你去電腦歷史博物館看看 MacWrite 和 MacPaint 的原始碼，就會發現它們是用 Object Pascal 寫成的，是我見過結構最優雅的軟體之一。它們的設計嚴謹、組織清晰，其中許多設計決策至今仍然能在 Photoshop 等現代系統中看到延續。這本身也說明了軟體生命週期的一個有趣事實。
從物件的角度理解軟體，被證明是一種極為有效的方法，因為它為解決軟體複雜性問題提供了全新的路徑。正如第一黃金時代一樣，第二黃金時代同樣充滿活力。1980、1990 年代，湧現出一批重要人物，比如「三位一體」（我本人、Ivar Jacobson 和 Jim Rumbaugh），以及 Peter Coad、Larry Constantine、Ed Yourdon 等，共同推動了從「過程」轉向「物件」的思考方式。當然，我們也犯過錯誤，例如一度過度強調繼承，把它當成萬能解法，這後來被證明並不完全正確。但從類別和物件來理解世界的基本思想，最終被保留下來並沉澱下來。
與此同時，這也是一個經濟層面的轉折點。隨著系統規模不斷擴大，平台開始興起。事實上，這在第一黃金時代就已有先例：人們反覆建構相同的功能，於是開始將常用演算法和過程打包重用，例如磁碟操作、終端輸出、排序演算法等。這些實踐最終催生了軟體共享的概念。在商業系統領域，IBM 的 SHARE 使用者組織便是典型代表，它是一個由客戶自發組織、相互共享軟體的社群。
Gergely：這是不是一種相對原始的「打包」方式？比如把排序演算法或一些通用功能集中起來分發？
Grady：需要澄清的是，這並不是 IBM 官方在做，而是完全由使用者社群推動的，這實際上是最早的開源軟體形態之一。當時的軟硬體經濟結構也很不同，軟體通常是隨硬體免費提供的，直到 1960 年代後期，IBM 才意識到軟體本身可以作為商品，開始將軟硬體解耦並單獨收費。
在更早的階段，社群氛圍非常開放，人們會說：「我寫了這個工具，你拿去用吧。」這正是開源精神的雛形。類似的事情在第二黃金時代再次發生，只不過抽象層次更高了。人們開始共享函式庫、元件和工具，比如驅動 CRT 顯示器的程式。這些東西本身並不構成競爭優勢，卻極大提升了建構複雜系統的能力。
在這種背景下，平台逐漸形成。隨著函式庫和元件規模不斷擴大，分散式系統興起，我們開始討論「服務導向架構」（SOA）。HTML 和 HTTP 讓資訊交換成為可能，人們開始設想透過網路共享影像、訊息乃至服務。SOAP 等協定由此誕生，成為當今平台時代的前身。這些變化，正是在第二黃金時代為平台經濟奠定基礎。
Gergely：「平台」的興起，具體是指什麼？你如何定義平台？
Grady：AWS 和 Salesforce 都是典型例子。這些平台就像一座座「經濟城堡」，周圍有護城河。平台方允許你付費跨過護城河，使用其能力，其前提是：如果你自己從頭建構，成本會高得多。因此，在第二黃金時代，我們看到了 SaaS 類企業的興起，因為某些軟體的複雜性和成本已經高到足以支撐這種商業模式。進入 1990 年代末、2000 年代初，這是一個同樣充滿活力的階段。網際網路快速發展，軟體開始真正滲透進社會的各個縫隙，成為文明基礎設施的一部分。電子郵件就是一個典型例子。
Gergely：你什麼時候有了第一個電子郵件信箱？
Grady：1987 年，那時還是 ARPANET。隨著軟體成為日常基礎設施，第一黃金時代所擔憂的許多問題逐漸「消失」了，不是被忽視，而是被內化進系統之中。優秀的技術會「蒸發」，成為空氣的一部分。第二黃金時代，正是當今軟體世界的根基。
2000 年前後，網際網路泡沫破裂，經濟邏輯無法支撐此前的擴張，同時還發生了 Y2K 問題。事後看似乎「什麼也沒發生」，但那是因為無數工程師付出了巨大的努力，才避免了災難，這正是「最好的技術你看不見」的典型例子。
Gergely：我還記得千禧蟲之前的緊張氣氛，甚至有電影預言世界末日。結果什麼都沒發生，很多人因此不再相信這種預警。
Grady：此時，我想補充一條此前未展開的歷史線索：AI。
AI 的第一個黃金時代出現在 1940、1950 年代，以符號主義為核心，代表人物包括 Herbert Simon、Newell 和 Minsky。當時也嘗試過神經網路，比如用真空管實現的人工神經元，但由於運算能力和理論限制，最終失敗，AI 進入寒冬。第二個黃金時代出現在 1980 年代，以規則系統和專家系統為代表，儘管硬體和架構有所進步，但仍然難以規模化，最終再次陷入停滯。
進入 21 世紀，我認為我們其實已經身處軟體工程的第三個黃金時代。其標誌在於抽象層次的再次躍遷：從單個程式，提升到平台級函式庫、框架和服務。我們不再自己實作訊息系統或資料管理，而是直接使用現成的平台能力。AI 程式設計助理的出現，正是對這種複雜度增長的回應。它們並非偶然，而是第三黃金時代演進邏輯的自然結果。
當下的問題已經不同於前兩代：軟體規模空前龐大，資安、供應鏈攻擊、系統信任成為核心議題；同時，軟體巨頭的重要性使其具備「系統性風險」；此外，技術倫理問題也被推到台前：我們能做到的事情，是否就意味著我們應該去做？
Gergely：很多人其實很少回頭去想：這一切究竟是如何開始的，以及軟體工程這門學科本身到底有多「年輕」。即便從 1970、1980 年這個尺度來看，它也不過勉強算是兩代人的歷史。
但我現在在產業裡普遍感受到一種情緒，尤其是在最近這個階段，很多軟體工程師正在經歷一種明顯的「存在主義焦慮」。這種焦慮在這個冬歇期之後明顯加速了。在冬歇期之前，AI 和大型語言模型主要還只是自動補全工具，偶爾能生成一些程式碼；但在冬歇期之後，新一代模型已經能寫出品質相當高的程式碼，甚至到了我開始真正信任它們的程度。
從歷史上看，寫程式碼一直是一件困難的事情，我們往往需要多年訓練才能熟練，真正做到優秀則更久。因此，現在很多人開始陷入一種深刻的不安：機器居然能寫出如此好的程式碼，這到底是怎麼在短短幾個月內發生的？接下來會怎樣？編碼一直和軟體工程高度綁定，但現在似乎不再如此了。從你的歷史視角來看，你如何理解當下正在發生的事情？
Grady：這並不是軟體工程師第一次經歷這樣的存在性危機。類似的焦慮在第一代、第二代軟體工程時期都出現過。所以我的態度一直是：歷史會重演，這一輪也終將過去。我經常對擔憂的人說，不必恐慌，把注意力放在基本功上，因為那些能力不會消失。
我曾經見過 Grace Hopper，正是她在 1950 年代意識到，軟體可以從硬體中抽象出來。這一思想在當時極具顛覆性，甚至引發了強烈反對。很多早期電腦工程師認為，如果不緊密依附硬體，就不可能寫出高效的軟體，他們擔心這種做法會摧毀整個產業。事實證明，他們錯了。
類似的爭論後來也出現在 Fortran 出現時。有人堅信，人類手寫的組合語言程式碼一定比編譯器生成的程式碼更高效，但隨著抽象層級的提升，這種觀點被一次次推翻。每一次抽象躍遷，都會讓一部分既有技能失去中心地位，而這些變化往往正是由工程師自己推動的。
過去這種衝擊沒有引發如此劇烈的情緒，一個重要原因是：當時從業人員規模很小，可能只有幾千人；而今天，這個群體是數以百萬計的。人們理所當然會問：那我怎麼辦？
我也經常被年輕工程師問到類似的問題：「我是不是選錯了方向？」我的回答始終是：現在恰恰是進入軟體產業的好時機。原因很簡單，我們正在經歷一次新的抽象層級躍遷，就像從機器語言到組合語言，從組合語言到高階語言，從高階語言到函式庫和平台那樣。
這種變化對我而言是極大的解放。我不再需要關注大量繁瑣細節，但軟體工程的基本原則依然存在。只要你是在建構需要長期維護、需要經得起時間考驗的軟體，這些能力就不可替代。
當然，如果你只是寫一次性程式碼、寫完就丟，那隨便用什麼工具都可以。我看到很多人正是用 AI 代理來完成這種「用完即棄」的自動化任務，這完全沒問題，甚至非常有價值。
這讓我想起早期個人電腦時代的「愛好者文化」。當年，許多原本與軟體毫無關係的人開始自己寫程式，產生了大量新想法。今天的情況極為相似。你可以用 AI 自動化一些過去經濟上根本不值得做的事情，即便這些成果未必長期存在，但它們依然創造了價值。
Gergely：就像當年普通人可以買得起個人電腦一樣，如今也有很多原本不在產業內的人開始寫軟體。我刚和樓上的鄰居聊過，她是一名會計師，但已經在用 ChatGPT 幫團隊寫程式碼，提高流程效率。
Grady：早期個人電腦時代，藝術家、遊戲玩家紛紛湧入這一新媒介，創造了前所未有的活力，今天同樣如此。很多所謂的「職業危機敘事」，其實源於對產業的狹隘理解。真正發生的事情是：軟體正在擴展到更廣泛的人群中。非職業開發者將會寫出更多軟體，而我認為這是極其正面的變化。就像當年的個人電腦反主流文化一樣，歷史正在重演。
Gergely：Anthropic 的 CEO Dario Amodei 曾預測，大約 90% 的程式碼會由 AI 生成，當時聽起來很誇張，但後來事實證明他並非完全錯誤。最近他又說了一句更令人不安的話：「軟體工程將在 12 個月內被自動化」。考慮到編碼只是軟體工程的一部分，這個說法顯得更加激進。你怎麼看？
Grady：我有一兩點要說。
首先，我用 Claude，我用 Anthropic 的產品。我覺得它是我的首選系統。我用它來解決 JavaScript、Swift、PHP（沒錯，甚至 PHP）、還有 Python 的問題。我確實在用，而且它對我幫助很大——主要是因為我想用某些函式庫：Google 搜尋太爛了，文件也很爛，所以我用這些代理加速對它們的理解。
但別忘了：我在這些領域裡至少有一兩年的經驗——好吧，準確說是幾十年——我理解基本原理。所以我才會說：基本功不會消失。這一點在任何工程學科裡都成立：基本原理不會消失，變化的是我們使用的工具。
因此，Dario，我尊重你的表達，但也要認識到：他和我視角不同。他在帶領一家公司，公司需要賺錢，他需要對利害關係人說話。所以他會說一些「聳動的」話。我記得他好像是在達沃斯講的這些？
Gergely：對。
Grady：如果用一個「技術術語」來評價他的結論，那就是：它在根本上是錯誤的（profoundly wrong）。原因有幾方面。
第一，我接受他的部分觀點：它會加速某些事情。但它會消滅軟體工程嗎？不會。我認為他對「軟體工程是什麼」有根本誤解。
回到我一開始說的：軟體工程師是負責平衡各種力量的工程師。程式碼只是我們的一種機制，但不是驅動我們的唯一因素。而他或他同事討論的那些東西，沒有一個觸及軟體工程師必須面對的那些決策問題——那些都不在當前所謂「自動化」的範圍之內。
他的工作主要聚焦在最低層的自動化——我會把它類比為當年編譯器所做的事情。所以我說：這是一輪新的抽象層級上升。開發者們別害怕：工具在變，但問題並沒有消失。
我反駁他的第二個理由是：像 Cursor 這類系統，大多訓練在一組我們已經反覆見過的題型上。這沒問題。就像第一代、第一個黃金時代，我們也面對的是一組相對固定的問題，於是圍繞它們建函式庫。現在同樣如此。
如果我要在 CRUD 之上搭一個 UI，或者做一個偏 Web 的東西，當然可以做到。更重要的是，這種能力開始「下沉」——很多原本需要專業工程能力才能完成的事情，如今被更高層抽象直接交付給了更多人。多數人不會因此去做一門生意，當然也會有極少數人能把它做成產品。但關鍵在於：更高層抽象讓他們能做以前做不到的事。
而 Dario 忽略了一點——我借用一句莎士比亞式的轉述來講：「運算世界裡還有更多東西，超出你哲學所能夢到的範圍。」運算世界遠遠不只是「可規模化的 Web 系統」那一塊。我們今天確實把很多東西應用在這種以 Web 為中心的大規模系統上，我覺得這很好、很棒，但這也意味著：外面還有大量東西尚未被自動化。我們會不斷把「邊界／前沿」繼續往外推。
我一開始講那些故事，就是因為歷史正在重複——或者有人說，歷史在押韻。今天發生的現象本質相同，只是發生在不同的抽象層級上。
這是第一點：軟體世界比他所看的更大，不僅是「軟體密集型系統」，也不僅是他關注的那一小塊。
第二點，如果你看這些代理主要處理的系統類型，它們本質上是在自動化我們反覆見過、它們也在訓練中反覆學過的模式。模式本身就是一種新的抽象：它不只是單個演算法或單個物件，而是由一群物件和演算法組成的「社會」，彼此協作。
這些代理很擅長自動化「模式的生成」。我想做某種東西，我可以用英語描述——因為模式本來就是我們用自然語言來描述的。
所以這就是為什麼我認為他錯了。祝他好運。但我覺得這是一個更令人興奮的時代，而不是一個需要在存在層面恐慌的時代。
我再講一個關於「抽象層級上升」的故事。
英語是一種非常不精確的語言，充滿歧義與細微差別。你可能會想：這種語言怎麼可能成為「有用的語言」？答案是：我們作為軟體工程師其實一直在這樣做。
我去找一個人說：「我希望系統能做這件事，大概長這樣。」然後給一些例子。我一直在做這個。然後會有人把它轉成程式碼。也就是說，我們早就處在一個更高層抽象：我說「我想要它做什麼」。
舉個具體例子：我最近在用一個以前從沒碰過的函式庫——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
聲明：本文為 InfoQ 整理，不代表平台觀點，未經許可禁止轉載。