【翻譯文】程式設計的終結，也是新起點：我們所知的程式設計將迎來變革

作者： Tim O’Reilly

本文出自於此， Tim O’Reilly 是美國科技出版界的重量級人物，他創辦的O'Reilly Media以出版深入淺出的電腦技術書籍而聞名，其書籍封面常以動物圖像為特色。他不僅是成功的出版人，更是科技趨勢的敏銳觀察者，他提出的「Web 2.0」概念，深刻影響了網際網路的發展方向。此外，O’Reilly 也是開放原始碼的積極推動者，他透過出版和會議，促進了開放原始碼社群的發展和壯大。他對科技的遠見和洞察力，使他被譽為「矽谷先知」，他的思想和工作，持續引導著科技界的創新和進步。

本文重點：

1. 程式設計正在演變而非消亡 - 文章指出，雖然媒體聲稱AI將導致程式設計師失業，但歷史告訴我們這只是程式設計形式的轉變，類似於從組合語言到高階語言的轉變。每次技術變革後，我們看到的不是程式設計師減少，而是更多人以新方式參與程式設計。

2. AI將成為程式設計師的輔助工具而非替代者 - 優秀的程式設計師將學會如何有效地使用AI作為協作工具，專注於高價值的系統思考而非機械性的編碼。AI可以處理重複性工作，讓人類專注於理解業務需求、設計系統架構和解決複雜的邊緣案例。

3. 新型程式設計技能的需求將增加而非減少 - 就像工業革命需要新技能一樣，AI時代需要新一代會使用AI工具的程式設計師。成功的程式設計師將不再只專注於寫程式碼，而是學習如何指導AI生成的程式碼、塑造AI系統，以及在複雜的業務環境中整合這些解決方案。而那些拒絕適應新工具的「固執開發者」才是真正會被淘汰的群體。

正文：

現今媒體充斥著軟體開發者即將被 AI 搶走飯碗的言論，但我並不認同。

這並非程式設計的終結，而是我們所知的程式設計的終結。 程式設計的演變並非新鮮事。 早期的程式設計師透過連接實體電路來執行每個計算，後來則演變成以機器指令的形式編寫二進制程式碼，並透過撥動電腦上的開關逐位輸入。 接著，組合語言程式設計的出現終結了這個時代。 它允許程式設計師使用類似人類的語言來指示電腦將數據移動到內存中的位置並對其執行計算。 隨後，Fortran、COBOL 等更高級的編譯語言及其後繼者 C、C++ 和 Java 的發展，意味著大多數程式設計師不再需要編寫組合語言程式碼。 相反，他們可以使用更高級的抽象概念來表達他們對電腦的要求。

最終，更容易除錯的直譯語言成為了主流。 BASIC 作為首批獲得巨大成功的直譯語言之一，最初被視為一種玩具，但很快就被證明是未來的趨勢。 程式設計不再侷限於大公司和政府機構的後勤人員，而是變得更容易讓兒童和創業家接觸。

消費者操作系統也是這個故事的重要組成部分。 在個人電腦的早期，每個電腦製造商都需要軟體工程師來編寫低階驅動程式，這些驅動程式負責讀寫內存板、硬盤和數據機、打印機等外圍設備。 Windows 的出現終結了這一切。 它的成功不僅是因為它提供了一個圖形用戶界面，讓未經訓練的人更容易使用電腦，還提供了 Marc Andreessen (其公司 Netscape 即將被微軟擊垮) 貶低 (且錯誤地) 稱為「只是一堆驅動程式」的東西。 這個由 Win32 API 支持的「驅動程式包」意味著程式設計師不再需要編寫低階程式碼來控制機器。 這項工作被有效地封裝在操作系統中。 Windows 和 macOS，以及行動裝置上的 iOS 和 Android，意味著今天大多數程式設計師不再需要了解早期程式設計師所掌握的許多知識。

程式設計師數量不減反增

儘管如此，程式設計師的數量不減反增。 數以億計的用戶享受著他們創造力的成果。 作為需求彈性的一個典型例子，隨著軟體更容易創建，其價格下降，允許開發者創建更多人願意付費的解決方案。

網路是另一個「程式設計的終結」。 突然之間，用戶界面由人類可讀的文件組成，這些文件顯示在瀏覽器中，並帶有可以調用遠程伺服器上程式的連結。 任何人都可以使用最少的程式設計技能構建一個簡單的「應用程式」。 「無程式碼」成為了一個流行詞。 很快，每個人都需要一個網站。 WordPress 等工具讓非程式設計師無需編碼即可創建網站。 然而，隨著技術能力的增長，成功的網站變得越來越複雜。 「前端」和「後端」程式設計之間的分工越來越明顯。 Python 和 JavaScript 等新的直譯程式語言佔據了主導地位。 行動裝置增加了一個新的、無處不在的前端，需要新的技能。 再一次，複雜性被隱藏在框架、函數庫和 API 的背後，這些框架、函數庫和 API 使程式設計師不必像幾年前那樣必須學習大量關於低階功能的知識。

大數據、網路服務和雲端計算建立了一種「網際網路操作系統」。 Apple Pay、Google Pay 和 Stripe 等服務使得以前困難、高風險的企業任務 (如收款) 無需太多程式設計專業知識即可完成。 各種各樣深奧而強大的功能都可以通過簡單的 API 獲得。 然而，網際網路網站以及連接它們的網路協議和 API 的爆炸式增長最終導致了對更多程式設計師的需求。

程式設計師不再構建每隔幾年更新一次的靜態軟體，而是持續開發、整合和維護長期服務。 更重要的是，Google 搜索、Google 地圖、Gmail、Amazon、Facebook 和 Twitter 等大型服務中的大部分工作都是大規模自動化的。 程式是由人類設計和構建的，而不是 AI，但大部分工作是由當今通用 AI 的特殊用途前身完成的。 在這些公司中，承擔大部分繁重工作的其實是程式。 人類程式設計師是他們的管理者。 現在有數十萬程式設計師在做這種監督工作。 他們已經生活在一個創造和管理數位同事的世界中。

(引用) 「Google、Facebook、Amazon 或許多新興的矽谷創業公司……僱用了數以萬計的員工。 如果你用 20 世紀的工廠思維來思考，這些員工就像他們的工業前輩一樣，每天都在生產產品，只是今天他們生產的是軟體而不是實物。 相反，如果你退一步，用 21 世紀的思維來看待這些公司，你就會意識到這些公司的大部分工作——提供搜索結果、新聞和信息、社群網路狀態更新和相關產品以供購買——都是由軟體程式和演算法完成的。 這些才是真正的工人，而創造它們的程式設計師則是他們的管理者。」——Tim O’Reilly，「管理正在管理業務的機器人」，麻省理工學院斯隆管理評論，2016 年 5 月 21 日

在每一波浪潮中，舊技能都變得過時——仍然有用，但不再是必需的——而新技能成為成功的關鍵。 仍然有一些程式設計師編寫編譯器，數千名程式設計師編寫流行的 JavaScript 框架和 Python 庫，但數千萬程式設計師編寫網路和行動應用程式以及支持它們的後端軟體。 數十億用戶消費著他們生產的產品。

這次會有所不同嗎？

然而，突然之間，非程式設計師似乎可以簡單地用英語 (或你選擇的人類語言) 與 LLM 或專門的軟體代理進行對話，並獲得 Python (或你選擇的程式語言) 編寫的有用原型。 甚至還有一個新的流行詞來形容這種情況：CHOP，即「面向聊天的程式設計」。 高級推理模型的興起開始證明 AI 可以通過解釋要完成的任務的高階提示來生成 even complex programs。 因此，很多人說「這次不一樣了」，AI 將完全取代大多數人類程式設計師，實際上，還會取代大多數知識工作者。 他們說我們面臨著普遍的人類失業浪潮。

我仍然不這麼認為。 當一項突破將先進的計算能力交到更多人手中時，是的，普通人可以做到曾經是訓練有素的專家才能做的事情。 但同樣的突破也催生了新型服務和對這些服務的需求。 它創造了只有少數人才能理解的新型深度魔法。

現在出現的魔法是最強大的。 這意味著我們正處於一個深刻的探索和創造時期，試圖理解如何讓魔法發揮作用並從其力量中獲得新的優勢。 採用該技術的聰明開發者將會炙手可熱，因為他們可以做更多的事情，專注於增加價值的更高層次的創造力。

邊做邊學

AI 不會取代程式設計師，但會改變他們的工作。 最終，程式設計師今天所做的許多工作可能會像使用示波器除錯的舊技能一樣過時 (嵌入式系統程式設計師除外)。 程式設計大師和有先見之明的技術觀察家 Steve Yegge 觀察到，被取代的不是初級和中級程式設計師，而是那些墨守成規而不願擁抱新程式設計工具和範例的人。 那些獲得或發明新技能的人將會炙手可熱。 掌握 AI 工具的初級開發者將能夠勝過不掌握 AI 工具的資深程式設計師。 Yegge 將其稱為「頑固開發者的消亡」。

我的想法不僅源於我自己過去 40 多年在電腦行業的經驗以及像 Yegge 這樣的開發者的觀察，還源於經濟歷史學家 James Bessen 的著作，他研究了第一次工業革命是如何在 19 世紀早期在馬薩諸塞州洛厄爾的紡織廠中發揮作用的。 隨著熟練工匠被「非熟練」勞動力操作的機器所取代，工資確實受到了抑制。 但貝森通過比較新興工廠工人的工資記錄和以前在家工作的工匠的工資記錄，注意到了一些奇怪的事情。 學徒工匠達到熟練技工的全部工資所需的時間與新入職的非熟練工廠工人達到全部工資和生產力所需的時間大致相同。 這兩種制度下的工人實際上都是熟練工人。 但他們擁有不同種類的技能。

貝森發現，在工業革命的前 50 年中，工資在大部分時間裡保持平穩或下降，然後才開始騰飛並導致普遍的繁榮，這其中有兩個主要原因。 首先是工廠主囤積了新生產力带来的好处，而不是與工人分享。 但其次是最大的生產力提升需要數十年才能實現，因為關於如何最好地使用新技術的知識尚未廣泛傳播。 發明家們花費了數十年時間才使機器更堅固，使用機器的人們才想出新的工作流程以提高效率，創造可以用機器製造的新型產品，更廣泛的企業才採用新技術，以及工人獲得利用這些技術所需的技能。 工人需要新的技能，不僅要使用機器，還要維修機器、改進機器、創造他們暗示但尚未完全實現的未來。 所有這些都是通過貝森所說的「邊做邊學」的過程發生的。

僅僅少數人走在採用新技能的曲線前面是不夠的。 貝森解釋說，「對工廠、行業和整個社會而言，重要的不是培訓一名工人需要多長時間，而是建立一支穩定、訓練有素的勞動力隊伍需要什麼」 (邊做邊學，36)。 今天，每一家將會受到這場革命影響的公司 (也就是說，每一家公司) 都需要付出努力。 我們需要一支具備 AI 素養的勞動力隊伍。 畢竟，什麼是程式設計？程式設計不就是人類讓電腦按照我們的吩咐做事的方式嗎？ 「程式設計」越來越接近人類語言，我們的機器可以理解我們，而不是我們必須用他們的母語 0 和 1，或者某種專門的程式語言來與他們交談，這應該值得慶祝。

人們將創造、使用和改進更多的程式，新的行業將誕生，以管理和建立在我們創造的基礎之上。 歷史的教訓告訴我們，當自動化使人們更容易、更便宜地交付他們想要或需要的產品時，需求的增長通常會導致就業的增長。 只有當需求得到滿足時，就業才會開始下降。 就程式設計而言，我們遠未達到這一點。

毫不奇怪，沃頓商學院教授和 AI 傳播者 Ethan Mollick 也是貝森著作的粉絲。 這就是為什麼他如此有說服力地主張「始終將 AI 引入桌面」，將其融入您工作的方方面面，並探索「有效和無效的鋸齒狀邊緣」。 這也是為什麼他敦促公司使用 AI 來賦予員工權力，而不是取代他們。 關於如何應用新技術，我們還有很多東西要學習。 企業應用研發的最佳來源是您現有員工的探索，因為他們使用 AI 來解決問題並尋找新機會。

程式設計的定義將會改變

微軟的副首席技術官之一 Sam Schillace 贊同我的分析。 在最近的一次談話中，他告訴我：「我們正處於圍繞 AI 系統發明新的程式設計範例的過程中。 當我們從桌面時代進入網際網路時代時，堆棧中的所有東西都發生了變化，即使堆棧的所有層級都相同。 我們仍然有語言，但它們從編譯變成了直譯。 我們仍然有團隊，但他們從瀑布式變成了敏捷式再到 CI/CD。 我們仍然有數據庫，但它們從 ACID 變成了 NoSQL。 我們從一個用戶、一個應用程式、一個線程變成了多個分佈式，等等。 我們現在正在對 AI 做同樣的事情。」

以下是一些正在組裝到新的 AI 堆棧中的技術。 這甚至不包括大量的 AI 模型、它們的 API 和它們的雲端基礎設施。 它已經過時了！

但是，新工具、框架和實踐的爆炸式增長只是程式設計如何變化的開始。 Schillace 指出，一個問題是模型不像人類那樣具有記憶力。 即使有很大的上下文窗口，他們也很難做到他所說的「元認知」。 因此，他認為人類仍然需要為他們的 AI 共同開發者提供大量的運作環境。

Schillace 在最近的一篇文章中詳細闡述了這個想法。 他寫道：「大型語言模型 (LLM) 和其他 AI 系統正在嘗試自動化思維。 這與工業革命期間運動自動化的相似之處令人震驚。 今天，自動化仍然很粗糙：我們正在做認知上的抽水和錘擊等基本任務——例如摘要、模式識別和文本生成。 我們還沒有弄清楚如何為這種新能源構建強大的引擎——我們甚至還沒有達到 AI 的機車階段。」

即使是機車階段，也在很大程度上擴展了人類在移動物體時所能施加的蠻力。 接下來的重大突破是增加了對這種力量的控制手段。 Schillace 問道：「如果傳統的軟體工程在這裡並不完全相關怎麼辦？ 如果構建 AI 需要根本不同的實踐和控制系統怎麼辦？ 我們正在嘗試創造新的思維方式 (我們對運動的類比)：更高級別、元認知、自適應系統，它們可以做的不僅僅是重複預先設計的模式。 為了有效地使用這些，我們需要發明全新的工作方式、新的學科。 正如早期蒸汽動力的挑戰催生了冶金學一樣，AI 的挑戰將迫使認知、可靠性和可擴展性的新科學的出現——這些領域尚不存在。」

在企業中部署 AI 技術的挑戰

Bret Taylor 曾任 Salesforce 聯席首席執行官、Meta 首席技術官，很久以前還是 Google 地圖開發團隊的負責人，現在是 AI 代理開發商 Sierra 的首席執行官，這家公司處於開發和部署 AI 技術的核心地位。 在最近的一次談話中，Bret 告訴我，他相信公司的 AI 代理將成為其主要的數位界面，與其網站、其行動應用程式一樣重要，甚至可能更重要。 公司的 AI 代理必須對其所有關鍵業務政策和流程進行編碼。 這件事 AI 最終可能能夠自行完成，但今天，Sierra 必須為其每位客戶分配一個工程團隊來協助實施。

「將一個很酷的平台和一堆業務流程結合起來，並體現出一個代理，這最後一哩路實際上很難做到，」Bret 解釋道。 「現在出現了一個新角色，我們稱之為代理工程師，這是一種看起來有點像前端網路開發者的軟體開發者。 這是軟體中最常見的原型。 如果你是一名 React 開發者，你可以學習製作 AI 代理。 多麼棒的重新學習技能並使你的技能與時俱進的方式。」

當人們可以與能夠真正解決他們問題的 AI 代理交談時，誰還願意費力地瀏覽客戶服務電話樹呢？ 但是讓這些代理正確無誤將是一個真正的挑戰。 困難的不是程式設計。 而是深入了解業務流程並思考新功能如何轉變它們以利用新功能。 僅僅複製現有業務流程的代理將與僅僅重新創建紙質表單的網頁或行動應用程式一樣令人尷尬。 (是的，這些確實仍然存在！)

Google Chrome 用戶體驗主管 Addy Osmani 將此稱為 70% 問題：「雖然工程師報告說使用 AI 的效率顯著提高，但我們每天使用的實際軟體似乎並沒有變得明顯更好。」 他指出，使用 AI 程式碼生成工具的非程式設計師可以製作出色的演示或解決簡單的問題，但他們會在複雜程式的最後 30% 上卡住，因為他們不知道如何除錯程式碼並引導 AI 找到正確的解決方案。 同時：

當你看到一名資深工程師使用 Cursor 或 Copilot 等 AI 工具時，它看起來就像變魔術一樣。 他們可以在幾分鐘內搭建出完整的特性，包括測試和文檔。 但仔細觀察，你會注意到一個關鍵：他們不僅僅是在接受 AI 的建議……他們正在運用多年來辛苦得來的工程智慧來塑造和約束 AI 的輸出。 AI 正在加速他們的實施，但他們的專業知識才是保持程式碼可維護性的關鍵。 初級工程師經常會錯過這些關鍵步驟。 他們更容易接受 AI 的輸出，導致我所說的「紙牌屋程式碼」——它看起來很完整，但在現實世界的壓力下就會崩潰。

在這方面，新書《AI 工程》的作者 Chip Huyen 在給我的一封電子郵件中提出了一個具有啟發性的觀點：

我認為 AI 並沒有引入一種新的思維方式。 它揭示了什麼才是真正需要思考的。

無論多麼手工，如果一項任務只能由少數受過最高教育的人來完成，那麼這項任務就被認為是智力任務。 一個例子是寫作，即將文字複製到紙上的物理行為。 過去，當只有一小部分人識字時，寫作被認為是智力活動。 人們甚至以他們的書法為榮。 現在，「寫作」一詞不再指這種物理行為，而是指將思想整理成可讀格式的更高抽象概念。

同樣，一旦編碼的物理行為可以自動化，「程式設計」的含義將會改變，指的是將思想整理成可執行程式的行為。