最近媒體上有很多討論，說軟體開發者很快就會因為人工智慧 (AI) 而失業。我不這麼認為。
這不是程式設計的結束，而是我們今天所知的程式設計的結束。這並不新鮮。最早的程式設計師是將實體電路連接起來，來進行每一次計算。接著，程式設計師開始寫機器指令，使用二進位碼，一次輸入一位元，透過翻轉電腦前面的開關。然後，組合語言程式設計結束了這一切。它讓程式設計師可以使用類似人類的語言，告訴電腦如何將資料移動到記憶體中的位置並進行計算。隨著更高階的編譯語言如 Fortran、COBOL 及其後繼者 C、C++ 和 Java 的發展，大多數程式設計師不再寫組合碼。相反地，他們可以使用更高層次的抽象來表達他們的需求。
最終，解釋性語言變得更容易除錯，成為了主流。
BASIC 是最早受到廣泛使用的語言之一，起初被視為玩具，但很快證明它是未來的趨勢。程式設計變得對孩子和車庫創業者都可及，而不僅僅是大型公司和政府機構的後台專家。
消費者操作系統也是這個故事的重要部分。在個人電腦的早期，每個電腦製造商都需要能夠編寫低階驅動程式的軟體工程師，這些驅動程式負責讀取和寫入記憶體板、硬碟以及調製解調器和印表機等周邊設備。Windows 結束了這一切。它不僅因為提供了圖形使用者介面，使得未受訓練的人更容易使用電腦而成功。它還提供了馬克·安德森 (Marc Andreessen) 的 Netscape 公司即將被微軟 (Microsoft) 壓制時，輕蔑（且錯誤）地稱之為「只是一袋驅動程式」的東西。這袋驅動程式，透過 Win32 API，使得程式設計師不再需要編寫低階程式碼來控制機器。這項工作實際上已經被封裝在操作系統中。Windows 和 macOS，以及移動裝置的 iOS 和 Android，意味著今天大多數程式設計師不再需要了解早期程式設計師所知道的許多知識。
程式設計師的數量不減反增
這遠不是程式設計的結束。程式設計師的數量比以往任何時候都要多。數以億計的使用者享受著他們的創意成果。在一個經典的需求彈性示範中，隨著軟體變得更容易創建，其價格下降，讓開發者能夠創造出更多人願意支付的解決方案。
網路也曾被認為是「程式設計的結束」。突然之間，使用者介面由可人類閱讀的文件組成，這些文件在瀏覽器中顯示，並且可以通過鏈接調用遠端伺服器上的程式。任何人都可以用最少的程式設計技能建立一個簡單的「應用程式」。無需編碼（No code）成為了一個流行詞。很快，每個人都需要一個網站。像 WordPress 這樣的工具使得非程式設計師也能創建這些網站，而無需編碼。然而，隨著技術能力的增長，成功的網站變得越來越複雜。「前端」和「後端」程式設計之間的區別越來越大。新的解釋性程式語言如 Python 和 JavaScript 變得主導。移動設備增加了一個新的、無處不在的前端，要求新的技能。再次地，這種複雜性被框架、函數庫和 API 隱藏起來，讓程式設計師不必了解之前幾年他們必須學習的低階功能。
大數據、網路服務和雲計算建立了一種「網際網路操作系統」。像 Apple Pay、Google Pay 和 Stripe 這樣的服務使得以前困難的高風險企業任務，如接受付款，變得可能，並且只需要最少的程式設計專業知識。各種深層和強大的功能通過簡單的 API 提供。然而，這些網路網站的爆炸性增長以及將它們連接起來的網路協議和 API 最終導致了對更多程式設計師的需求。
程式設計師不再是每隔幾年就更新一次靜態軟體產品，而是持續開發、整合和維護長期運行的服務。更重要的是，像 Google 搜尋、Google 地圖、Gmail、亞馬遜 (Amazon)、Facebook 和 Twitter 這些龐大服務中的大部分工作，都是在大規模自動化的情況下進行的。這些程式是由人類設計和建造的，而不是 AI，但許多工作本身是由今天的通用 AI 的特殊前身完成的。在這些公司中，進行大量繁重工作的員工已經是程式。人類程式設計師是他們的管理者。現在有數十萬名程式設計師在做這種監督工作。他們已經生活在一個工作是創建和管理數位同事的世界中。
在每一波變化中，舊的技能變得過時——仍然有用但不再必需——而新的技能則成為成功的關鍵。仍然有一些程式設計師在編寫編譯器，數以千計的人在編寫流行的 JavaScript 框架和 Python 函式庫，但有數千萬人正在編寫網頁和移動應用程式，以及使其運行的後端軟體。數十億的使用者在消費他們所創造的東西。
這次會不會有所不同？
突然之間，似乎非程式設計師可以簡單地用普通英語（或你選擇的任何人類語言）與大型語言模型 (LLM) 或專門的軟體代理進行對話，並得到一個有用的 Python 原型（或你選擇的程式語言）。這甚至有了一個新的流行詞：CHOP，或「聊天導向程式設計」。先進推理模型的興起開始顯示出 AI 可以生成即使是複雜的程式，只需高層次的提示來解釋要完成的任務。因此，很多人說「這次會有所不同」，AI 將完全取代大多數人類程式設計師，事實上，大多數知識工作者。他們說我們面臨著普遍人類失業的浪潮。
我仍然不這麼認為。當有一個突破將先進的計算能力放入更大群體的手中時，普通人確實可以做一些曾經是高度訓練專家的領域的事情。但同樣的突破也會促使新型服務的出現和對這些服務的需求。它創造了只有少數人理解的新深層魔法。
現在即將到來的魔法是最強大的。這意味著我們開始了一個深刻的探索和創造時期，試圖理解如何使這種魔法運作，並從其力量中獲得新的優勢。聰明的開發者如果能採用這項技術，將會受到需求，因為他們能做得更多，專注於增加價值的高層次創造力。
透過實踐學習
AI 不會取代程式設計師，但它會改變他們的工作。最終，程式設計師今天所做的許多工作可能會變得過時（對於嵌入式系統程式設計師以外的所有人來說），就像用示波器除錯的舊技能一樣。大師級程式設計師和有遠見的技術觀察者史蒂夫·耶基 (Steve Yegge) 認為，取代的將不是初級和中級程式設計師，而是那些堅持過去而不擁抱新程式設計工具和範式的人。那些獲得或發明新技能的人將會受到高度需求。掌握 AI 工具的初級開發者將能超越不掌握這些工具的資深程式設計師。耶基稱之為「固執的開發者的死亡」。
我的想法不僅受到我在電腦產業超過40年的經驗和像耶基這樣的開發者觀察的影響，還受到經濟歷史學家詹姆斯·貝森 (James Bessen) 的研究影響，他研究了第一次工業革命如何在19世紀初的麻薩諸塞州洛威爾的紡織廠中展開。隨著熟練工匠被「非熟練」勞動者操作的機器取代，人類工資確實受到壓抑。但貝森通過比較新工業廠的工人和以前在家工作的工匠的工資記錄，注意到了一些特殊的情況。熟練工匠的學徒達到熟練工人的全額工資所需的時間，與新入職的非熟練工廠工人達到全額工資和生產力所需的時間幾乎相同。這兩種制度中的工人實際上都是熟練工人，但他們擁有不同類型的技能。
貝森發現，工資在工業革命的前50年大多保持平穩或壓抑的原因有兩個。第一，工廠所有者囤積了新生產力的好處，而不是與工人分享。但第二，最大的生產力增長需要幾十年才能到來，因為如何最好地使用新技術的知識尚未廣泛分散。發明者需要幾十年才能使機器更堅固，使用它們的人需要想出新的工作流程來使其更有效，創造出可以用它們製造的新產品，更多的企業需要採用新技術，工人需要獲得必要的技能來利用這些技術。工人需要新的技能，不僅是使用機器，還要修理它們、改進它們，發明未來。所有這些都是通過貝森所稱的「透過實踐學習」的過程發生的。
僅僅有少數個體在採用新技能方面走在前面是不夠的。貝森解釋說，「對於一個工廠、一個行業和整個社會來說，重要的不是訓練一個工人需要多長時間，而是創造一個穩定的、受過訓練的勞動力需要什麼。」（《透過實踐學習》，第36頁）今天，每個將受到這場革命影響的公司（也就是說，每個公司）都需要全力以赴。我們需要一個懂得 AI 的勞動力。畢竟，程式設計是人類讓電腦按照我們的意願行事的方式。「程式設計」越來越接近人類語言，我們的機器能理解我們，而不是我們必須用它們的母語 0 和 1，或某種專門的程式語言來與它們對話，這應該值得慶祝。
人們將創建、使用和改進更多的程式，新的產業將會誕生，以管理和建立我們所創造的東西。歷史的教訓告訴我們，當自動化使得提供人們想要或需要的產品變得更便宜和容易時，需求的增加往往會導致就業的增加。只有當需求得到滿足，就業才會開始下降。就程式設計而言，我們距離那一點還很遙遠。
不出所料，沃頓商學院的教授和 AI 擁護者伊桑·莫利克 (Ethan Mollick) 也是貝森工作的支持者。這就是為什麼他如此有說服力地主張「永遠將 AI 帶到桌上」，在你工作的每個方面都涉及它，並探索「不平坦的邊緣」，了解什麼有效，什麼無效。他也因此鼓勵公司使用 AI 來賦能其員工，而不是取代他們。關於如何應用新技術，有太多的學習空間。企業最好的應用研究與開發來源就是你擁有的人，因為他們使用 AI 來解決問題並尋找新機會。
程式設計的定義將改變
微軟的副首席技術官之一山姆·希拉斯 (Sam Schillace) 同意我的分析。在最近的一次對話中，他告訴我：「我們正處於圍繞 AI 系統發明新程式設計範式的過程中。當我們從桌面進入網際網路時，堆疊中的一切都改變了，即使堆疊的所有層次都是相同的。我們仍然有語言，但它們從編譯型變為了解釋型。我們仍然有團隊，但它們從瀑布式變為敏捷開發，再到持續集成/持續交付。我們仍然有資料庫，但它們從 ACID 變為 NoSQL。我們從一個使用者、一個應用程式、一個執行緒，變為多分佈式，無論如何。我們現在正在對 AI 做同樣的事情。」
這裡有一些正在組成新 AI 堆疊的技術。這甚至還不包括大量的 AI 模型、它們的 API 和雲基礎設施。這些技術已經過時了！
但新工具、框架和實踐的爆炸只是程式設計變化的開始。希拉斯指出的一個問題是，模型並不像人類那樣有記憶。即使有大型上下文窗口，它們在他所稱的「元認知」方面也很難做到。因此，他認為人類仍然需要提供大量的上下文，以便他們的 AI 共同開發者運作。
希拉斯在最近的一篇文章中擴展了這個想法。「大型語言模型 (LLMs) 和其他 AI 系統正在試圖自動化思考，」他寫道。「與工業革命期間運動的自動化相比，這些相似之處非常明顯。今天，自動化仍然很粗糙：我們正在進行認知等同於抽水和敲打的基本任務，如摘要、模式識別和文本生成。我們尚未弄清楚如何為這種新能量源構建穩健的引擎——我們甚至還沒有達到 AI 的火車頭階段。」
即使火車頭階段在很大程度上也是人類在移動物體時所能施加的力量的擴展。下一個關鍵突破是對該力量的控制手段的增加。希拉斯問：「如果傳統的軟體工程在這裡並不完全相關呢？如果構建 AI 需要根本不同的實踐和控制系統呢？我們正在嘗試創造新型思維（我們對運動的類比）：更高層次的、元認知的、自適應系統，能做的不僅僅是重複預設的模式。為了有效使用這些，我們需要發明全新的工作方式、新的學科。正如早期蒸汽動力的挑戰催生了冶金學，AI 的挑戰將促使新的認知、可靠性和可擴展性科學的出現——這些領域尚未完全存在。」
在商業中部署 AI 技術的挑戰
布雷特·泰勒 (Bret Taylor)，前 Salesforce 的聯合首席執行官、Meta 的首席技術官，以及很久以前創建 Google 地圖的團隊領導者，現在是 AI 代理開發公司 Sierra 的首席執行官，這家公司正處於開發和部署商業 AI 技術的核心。在最近的一次對話中，布雷特告訴我，他相信公司的 AI 代理將成為其主要的數位介面，與其網站一樣重要，與其移動應用程式一樣重要，甚至可能更重要。公司的 AI 代理必須編碼所有關鍵的商業政策和流程。這是 AI 最終可能能夠獨立完成的事情，但今天，Sierra 必須為每個客戶分配一個工程團隊來協助實施。
「將一個很酷的平台和一堆商業流程轉化為一個代理的最後一英里實際上相當困難，」布雷特解釋道。「現在出現了一個新的角色，我們稱之為代理工程師，這是一種看起來有點像前端網頁開發者的軟體開發者。這是軟體中最常見的原型。如果你是 React 開發者，你可以學會製作 AI 代理。這是一個重新技能並使你的技能相關的絕佳方式。」
誰會想要在客戶服務電話樹中掙扎，當他們可以與一個能夠真正解決他們問題的 AI 代理對話時？但要讓這些代理運作良好將是一個真正的挑戰。困難不在於程式設計，而在於深入理解商業流程，並思考如何利用新能力來改變它們。簡單地重現現有商業流程的代理將像一個簡單重建紙質表單的網頁或移動應用程式一樣尷尬。（是的，這些東西仍然存在！）
Google Chrome 的用戶體驗負責人艾迪·奧斯曼 (Addy Osmani) 稱這為70%問題：「雖然工程師報告說使用 AI 的生產力大幅提高，但我們每天使用的實際軟體似乎並沒有明顯改善。」他指出，非程式設計師使用 AI 代碼生成工具可以快速產出一個很好的演示或解決一個簡單的問題，但在一個複雜程式的最後30%上卻會卡住，因為他們不知道如何除錯代碼並引導 AI 得到正確的解決方案。與此同時：
當你看到一位資深工程師使用像 Cursor 或 Copilot 這樣的 AI 工具時，看起來就像魔法。他們可以在幾分鐘內搭建整個功能，還包括測試和文檔。但仔細觀察，你會注意到一個關鍵的事實：他們並不僅僅接受 AI 的建議……他們正在運用多年來獲得的工程智慧來塑造和約束 AI 的輸出。AI 加速了他們的實施，但他們的專業知識才是保持代碼可維護的關鍵。初級工程師往往會錯過這些關鍵步驟。他們更容易接受 AI 的輸出，導致我所稱的「紙牌屋代碼」——看起來完整，但在現實壓力下會崩潰。
在這方面，新書《AI 工程學》的作者奇普·惠恩 (Chip Huyen) 在給我發的電子郵件中做出了啟發性的觀察：
我不認為 AI 引入了一種新的思維方式。它揭示了實際上需要思考的東西。
無論多麼手動，如果一項任務只能由少數受過良好教育的人完成，那麼這項任務就被視為智力工作。一個例子是寫作，將單詞抄寫到紙上的物理行為。在過去，當只有一小部分人會讀寫時，寫作被視為智力工作。人們甚至為自己的書法感到自豪。如今，「寫作」這個詞不再指這一物理行為，而是指將想法安排成可讀格式的更高層次的抽象。
同樣，當編碼的物理行為可以自動化時，「程式設計」的意義將改變為將想法安排成可執行程式的行為。
斯坦福大學計算機科學系主任梅赫蘭·薩哈米 (Mehran Sahami) 簡單地說：「計算機科學是系統思考，而不是寫代碼。」
當 AI 代理開始與代理對話時……
……正確表達問題的重要性變得更加重要。作為公司前端的代理，提供訪問公司所有商業流程的能力，將不僅僅是與消費者對話，還將與這些消費者的代理和其他公司的代理對話。
代理方程式的整個側面仍然是非常投機的。我們尚未開始建立獨立 AI 代理之間合作的標準！最近一篇關於代理基礎設施需求的論文指出：
目前的工具在很大程度上是不足的，因為它們並未設計用來塑造代理如何與現有機構（例如法律和經濟系統）或行為者（例如數位服務提供者、人類、其他 AI 代理）互動。例如，對齊技術本質上無法保證當用戶指示代理執行非法行為時，會有某個人承擔責任。為了填補這一空白，我們提出了代理基礎設施的概念：設計用來調解和影響代理與其環境的互動和影響的技術系統和共享協議。代理基礎設施包括新工具以及現有工具的重新配置或擴展。例如，為了促進問責，將用戶與代理聯繫起來的協議可以基於現有的用戶身份驗證系統，如 OpenID。正如互聯網依賴 HTTPS 等基礎設施，我們認為代理基礎設施對於代理生態系統同樣不可或缺。我們為代理基礎設施確定了三個功能：1）將行動、屬性和其他信息歸因於特定代理、其用戶或其他行為者；2）塑造代理的互動；以及 3）檢測和補救代理的有害行為。
在這裡需要解決巨大的協調和設計問題。即使是我們能想像的最佳 AI 代理，在沒有人工指導的情況下也無法解決這樣的複雜協調問題。這裡需要的程式設計工作足以讓即使是 AI 協助的程式設計師在接下來的十年內忙碌不已。
總之，還有一個全新的軟體世界等待發明，而這不僅僅是 AI 獨自發明的，而是人類程式設計師利用 AI 作為超能力來發明的。這些程式設計師需要獲得許多新的技能。
我們正處於發明未來的早期階段
有太多新的東西需要學習和做。因此，是的，讓我們勇敢地假設 AI 共同開發者使程式設計師的生產力提高十倍。（你的情況可能會有所不同，取決於你的開發者學習新技能的熱情。）但我們也要假設，一旦這發生，企業、科學和我們的基礎設施的「可編程表面面積」將會平行上升。如果有 20 倍的機會讓程式設計發揮作用，我們仍然需要兩倍於這些新 10 倍程式設計師的數量！
使用者的期望也將上升。僅僅利用更高的生產力來降低成本的企業，將會輸給那些投資於利用新能力來構建更好服務的公司。
正如西蒙·威利森 (Simon Willison) 所說，他是一位長期的軟體開發者，一直在前沿展示程式設計如何在 AI 時代變得更容易和更好，AI 讓他「對自己的項目更有雄心壯志」。
從另一個能力爆炸的領域中吸取教訓：今天的漫威超級英雄電影中的單個畫面渲染可能需要的時間，與渲染第一部皮克斯電影的整個過程所需的時間相當，儘管 CPU/GPU 的價格和性能受益於摩爾定律。事實證明，電影產業並不滿足於更快、更便宜地交付低解析度的粗糙動畫。額外的計算周期投入到了數千個小改進中，如逼真的毛髮、水面、雲彩、反射，以及更多的像素解析度。技術的進步導致了更高的質量，而不僅僅是更便宜/更快的交付。有些產業因選擇更便宜/更快而得以實現（考慮用戶創建的在線視頻的爆炸），所以這不會是非此即彼。但質量在市場上將有其地位。它總是如此。
想像一下，數以千萬計的業餘 AI 協助程式設計師使用像 Replit 和 Devin 這樣的 AI 工具，或使用 Salesforce、Palantir 或 Sierra 等企業解決方案。他們會不會偶然發現能吸引數百萬人的用例？其中一些人將成為這一代與 AI 合作創造的軟體的企業家。但他們的許多想法將被現有的專業開發者採納、改進和擴展。
從原型到生產的旅程
在企業中，AI 將使得由最接近任何問題的人來構建解決方案變得更加可能。但這些解決方案中的最佳者仍然需要經歷什麼 Shyam Sankar，Palantir 的首席技術官所稱的「從原型到生產的旅程」。Sankar 指出，AI 對企業的價值在於「自動化，在於企業自主性」。但他也指出，「自動化受到邊緣案例的限制。」他回憶起 2005 年贏得 DARPA 大獎挑戰賽的自駕車 Stanley 的教訓：能做一些驚人的事情，但需要另外 20 年的發展才能完全處理城市駕駛的邊緣案例。
「工作流程仍然重要，」Sankar 辯稱，程式設計師的工作將是理解什麼可以由傳統軟體完成，什麼可以由 AI 完成，什麼仍然需要人類完成，以及如何將這些串聯起來以實現工作流程。他指出，「一個能讓你捕捉反饋並學習邊緣案例的工具鏈，能讓你儘快到達那裡，才是獲勝的工具鏈。」在 Sankar 想像的世界中，AI 實際上將使開發者能夠更深入地進入業務，並在他們所交付的影響中更加發揮作用。與此同時，頂尖的專業知識將在 AI 助手的幫助下成為程式設計師。失業的將不是程式設計師，而是每個工作角色中不成為 AI 協助程式設計師的人。
這不是程式設計的結束，而是它最新重塑的開始。
在4月24日，O’Reilly 媒體將舉辦「與 AI 一起編程：我們所知的軟體開發的結束」——一場現場虛擬技術會議，重點介紹 AI 如何已經在提升開發者的生產力，並為他們的組織提供真正的價值。如果你正在為明天的開發實踐而努力，並有興趣在活動中發言，我們希望在3月5日之前聽到你的消息。你可以在這裡找到更多信息和我們的演講徵集。
本文由 AI 台灣 運用 AI 技術編撰，內容僅供參考，請自行核實相關資訊。
歡迎加入我們的 AI TAIWAN 台灣人工智慧中心 FB 社團，
隨時掌握最新 AI 動態與實用資訊！
