圖片來源：

Matthew Berman

　　來源：Z Finance

　　編譯：Li Jiahui

當Thomas Dohmke第一次看到GPT-3生成Python代碼時，他的反應是：“這不可能奏效。”作為GitHub現任CEO、前Copilot項目負責人，他曾是代碼世界里最冷靜的現實主義者。但在2020年那個夏天，Codex完成了一個排序算法——沒有編譯器支持，卻語法完美，那一刻，他意識到軟件開發的未來已經到來。

本次訪談中，AI產品專家Matthew Berman與Thomas展開了一場極具穿透力的對話，回顧了從最早的代碼自動補全、到今天多模型Agent協作的全過程。他們探討了一個關鍵問題：

當AI不再只是建議代碼，而是開始主動設計、修改和驗證系統時，軟件開發者的角色到底發生了什么變化？

Thomas指出，真正的變革，不是“寫代碼這件事被AI取代”，而是

寫代碼的“起點、過程與目的”正在被重構

。過去，程序員從復制粘貼開始學編程，而現在，

AI正將“vibe coding”（氛圍編程）和“agentic DevOps”（代理驅動交付）結合起來，讓軟件開發更像構建一個系統生態，而非堆砌指令集

他還首次透露：GitHub Copilot將正式開源，這是繼VS Code之后又一次對開發者生態的深度承諾。他堅信，未來的代碼是由人類的創意、AI的算力和Agent的系統能力共建的。

“AI不會消滅開發者，只會激發他們更大的創造力。”

Thomas的經歷橫跨編譯器開發、開源運動、AI工程管理，是硅谷極少數在“模型尚未流行前就成功產品化生成式AI”的第一批實踐者。在這場對話中，他不僅復盤了一次技術奇跡的誕生，也給出了一個更清晰的行業方向：

Agent不是工具，而是平臺；開發者不是被替代者，而是新的指揮者。

　　以下是全文翻譯。

　　奇跡：AI生成式工具如何顛覆寫代碼的第一印象

　　Matthew Berman：Thomas，非常感謝你和我聊天。我真的很激動，特別期待討論軟件的未來，尤其是編碼Agent的未來。我的第一個問題是，你曾領導GitHub CodePilot的開發。這是在最近的生成式AI浪潮之前。在這個項目中，你輸入Alina代碼，點擊Tab鍵，它就會為你完成代碼。當我第一次看到它時，真的非常震撼。你第一次看到當時的GPT以及代碼補全功能時，你有什么感想？那種感覺是什么樣的？

　　Thomas：起初，我覺得它永遠不會奏效。我在上世紀90年代末和2000年代初在大學時做過很多編譯器的工作。所以我明白編譯器的工作原理。當時我簡直不能相信模型竟然能夠區分Python、Ruby或JavaScript的語法。我以為它肯定會搞混，把括號放錯位置，或者在不需要的地方加上分號等等。然而，當我在2020年夏天第一次看到GPT-3以及后來Codex時，這款開源的第一個編碼模型能夠根據提示生成代碼，比如說寫一個號碼檢測或某種語言的排序算法時，竟然可以提供整套正確語法的方法，盡管沒有編譯器支持。它還沒有像我們如今編碼Agent中用到的那種工具調用能力。

　　Matthew Berman：是的，當你和團隊首次推出時，那時我真的大開眼界。其他在我團隊工作的工程師們都說，“你一定要試試，這將帶來巨大的改變。”你馬上意識到軟件開發將永遠改變了嗎？

　　Thomas：我們在這之前就看到了一些跡象。在GitHub，我們總是先將每個功能發布給員工內測。所以我們對Copilot也做了同樣的事，大約在2021年6月發布預覽或公開預覽的三四個月之前。用戶的反饋非常出色。我們跟蹤了代碼的編寫量，第一次的遙測數據回來時，我的團隊進行每周回顧，他們發現啟用功能的文件中，它寫了大約25%的代碼。我們一開始不相信這個數據，就讓他們去重新檢查到底是怎么測量的。他們回來確認，沒錯，這個數據是真實的，現在甚至更高。對于不同的編程語言效果也不同，這也驗證了我們的想法，這不是什么隨機數字。比如說對于Python這樣的語言效果比較好，而對于C或C++這樣的語言效果較差，如果你考慮這些語言的歷史和它們對某些頭文件的導入或包含依賴，這就很合理了。

　　另一個指標是凈推薦值，這是用戶的反饋評價。我們大約是72分，這在-102到100的范圍內算是很高的滿意度分數。預覽版本通常很少有這么高的分數，特別是在我們改變開發者的日常工作流時。有很多開發者，包括我自己，對他們想要的配色方案和快捷方式配置都很挑剔。在VS Code中，你可以在設置和擴展中自定義很多選項，這也是一個重要的吸引力。所以每個人都有自己的開發環境。當我們把Copilot引入這個環境時，告訴他們現在你有了Copilot，它將總是預測接下來的十行代碼。然后你需要閱讀這些代碼并決定是否接受。我們原以為這種方法會被認為消極，實際上反饋卻是非常積極的。正如你所述，我們首次發布私人預覽，然后是公開預覽，很短時間內，Copilot用戶就突破了一百萬。許多人都有這樣的時刻：起初我懷疑這個工具，然后發現它確實有效，簡直像魔法一樣。這在當時引發了大量的推文和帖子，就像是在描述這一現象。

　　融入：從自動補全到行為設計，AI如何適配開發者日常

　　Matthew Berman：我想談談用戶體驗。現在回頭看，Tab補全功能似乎再顯而易見不過了。但在那之前并沒有這樣的功能。它讓學習曲線變得如此低。你是如何確定Tab補全作為你的AI編碼助手與開發者之間的第一個交互點的？

　　Thomas：在Visual Studio和Visual Code中，有一個稱為IntelliSense的功能，它利用編程語言和該語言的庫信息來告訴你類中有哪些方法。這會以小下拉菜單的形式顯示，你可以看到哪些選項是可用的。許多其他集成開發環境（IDE）也有類似的功能，比如在開發iPhone應用時使用的Xcode，它幫助你編寫那些冗長的Swift方法，并顯示這些方法的參數。所以有些行為已經成為開發者的習慣了：即便你不記得每個方法的完整拼寫，只要能夠記住前三四個字符，自動補全IntelliSense便能幫助你。編輯器如TextMate和Sublime也有智能自動補全功能，它們會查看你本地的文件，提取你已經編寫過的方法，并為你進行預測。因此，你可以編寫一個方法，當你調用這個方法時，它知道方法的聲明，將其自動補全。這種從開發者的自動補全中學來的行為已經有一段時間了。我想應該已經有差不多20年了，也許稍微少一點，但我第一次使用TextMate的時候，它就有智能自動補全功能。

　　另一方面，如果開發者沒有過目不忘的記憶力，總會有查找資料的時候。無論是在文檔中、瀏覽器里，還是在Reddit、博客文章，或者像Build這樣的開發者大會視頻中，當然還有GitHub上的庫和開源項目。他們可能在嘗試解決問題，例如如何訪問某個API、如何進行圓角處理、如何編碼一個字符串等。通常，他們會找到一段代碼片段并粘貼到編輯器中，然后根據自己使用的變量名和編程語言或庫的版本進行修改。因此，總會有這樣一種學習行為，即從別處獲取代碼，并讓它適應特定的場景。實際上，大多數人都是通過這種方式學習編程的。通過某種形式的反復嘗試，你可能從其他地方拿來一些東西，比如“Hello World”教程或指導，然后將其修改成自己的第一個應用程序。

　　在編輯器中擁有自動補全功能，你可以利用這種學習行為讓代碼正常工作，即使它不是完全完美的。然后，你將其與2020年的大型語言模型Codex結合，雖然它也存在一些不足之處，并有時會產生幻覺，但它已經足夠好，能夠簡化從別處查找資料的過程，幫助你保持在流狀態。我們相信，對于軟件開發者來說，這種“流狀態”是非常神奇的。你有一個想法，你想要構建它，就可以在有限的時間內集中精力和能量去實現。因此，只要我們能讓你在IDE中不斷構建，代碼順利流動，你繼續進行Tab補全并修改，編譯并持續推進，對許多開發者來說，這是最佳時刻，尤其是在代碼成功運行的時候。這樣，你可以看到，盡管只是依靠自己的雙手和一點思考、創意，就創造出了這些東西。

　　重塑：從學習語言到驗證Agent，開發者身份的演變

　　Matthew Berman：您提到學習編程時，通過獲取代碼片段并加以修改是一種常見的學習行為。那么，我想和您討論編程教育。這是您一直以來非常關心的話題，也是我關心的。學習編程可能是我學過的最重要的技能之一，因為它使我能夠將想法變成現實。從兩年多前開始，如果有人問我應該教孩子什么，我自己有兩個小孩，一個七歲，一個兩歲，我可能會說我想教他們編程。然而，現在我并不那么確定了。但我還是認為學習系統思維確實有很多好處。您怎么看？您是否仍然支持教孩子們學習基礎的編程語言？

　　Thomas：絕對支持，百分之百。孩子們應該學習編程，因為它在當今生活中是如此重要的一部分。軟件無處不在。顯而易見，我們口袋里的設備和我們的列表都在運行軟件。我們的汽車主要由軟件定義，而且如果你有一輛電動汽車，還包括一個電池。我們的房子、旅行都受軟件影響，當然，大多數職業生活也是一樣。即便是像農業或者警務這樣的領域，現在也大量使用軟件。因此，我覺得就像數學、物理、化學以及在學校里學的其他科目一樣，盡管以后可能不會再去使用，但學習它們是為了理解這個世界。理解計算機科學，具備基本的閱讀代碼能力，了解二進制邏輯、布爾邏輯及二進制編碼，是每個人都應該學習的技能。無論他們是否會在未來成為計算機科學家、物理學家或者只是因為我在學校學了音樂并不意味著我該站上舞臺唱歌。我個人是這么認為的，我不知道你怎么看。但這并不意味著我不該在學校接受這些課程。

　　首先，可以說軟件、計算機和技術在未來幾十年甚至幾百年內會繼續發揮重要作用，這點是無法爭論的。其次就是，現在我們已經構建并推出了編碼Agent，例如GitHub Copilot。這很神奇，因為你給它一個任務或問題，或者描述你要構建的東西，它會在現有的代碼庫和存儲庫中找出如何在代碼庫中實現該問題。所以它不僅僅是從零開始，我們已經看到了很多這樣的演示。我自己也做過，比如構建一個貪吃蛇游戲。但實際上，它是利用現有的代碼庫，基于描述對代碼庫進行修改，并創建我們稱之為“拉取請求”的東西，以顯示代碼是如何更改以實現功能的。

　　現在，工程師的角色變成了驗證Agent所做的事情。他們需要閱讀所有這些變化。如果你有足夠長的工作經驗和理解力，你如何驗證Agent所做的內容確實符合你的目標、符合你的業務，并且能夠保持客戶對我們的信任？因為顯而易見的危險是，Agent可能會創建不安全的代碼，導致安全事故，使得我們需要去解釋、處理客戶數據丟失的假設情境。比如，你可以想象很多這樣的情況，Agent做了一些事情，當下感覺很好，因為它做得非常快，但是由于你沒有真正理解它的工作，可能會損害業務。因此，對于每個正在進行軟件開發的企業來說，至關重要的一點是理解這些Agent建造的東西，以及如何利用它們來最終創造競爭優勢。

　　Matthew Berman：所以，現在不僅僅是學習核心編程語言及其如何運作，比如語法、邏輯運算符的使用，學習AI輔助工具的使用也同樣重要。請告訴我你的看法或糾正我。

　　Thomas：學習這門技藝，就像學習工藝一樣。你必須掌握這種技藝，還需要不斷發展它。在軟件開發中，如果你從事這個行業已經20年了，你會知道20年前的軟件開發方式和今天的方式是非常不同的。20年前，開源軟件在許多企業里仍是一個新鮮事物，它們對安全性和合規性以及一旦開源項目的創建者失去興趣時，誰來維護這些項目存有擔憂。如今，20年后，從操作系統到容器管理，再到開源編輯器，以及數以萬計的從后端到前端的開源庫，幾乎每個人的技術堆棧都會使用開源軟件。

　　20年前，我們并沒有全棧工程師這樣的概念。數據庫開發、后端開發和前端開發都是獨立的學科。以前開發Windows應用的程序員需要了解PC的架構、可用內存的大小以及內核中的方法。當時可能有一個叫PDC的東西，而不是我們現在熟悉的Build大會，重點也更多是關于Windows，因為它在當時扮演著更大的角色。而那些Windows開發者需要理解PC的架構、可用內存以及內核中的方法。而如今，多數開發者是為網絡應用進行開發，他們不需要深入至硬件層面。

　　他們基本上假設自己可以在需要的時候啟動一個更大的虛擬機。所以軟件開發的方式正在不斷演變，開發者必須不斷提高他們的技能，了解下一次的大變革是什么。學習如何使用AI和新的模型，管理這些工具以滿足客戶的信任期望，這已經成為全棧工程師技能集合的一部分。現在不再僅僅局限于前端和后端開發，還包括對模型的使用。我們在GitHub和微軟都不認為未來只有一個單一的模型。會有多個模型用于不同的應用場景。比如代碼補全功能，你已經提到了，它使用快速且低延遲的模型。對于Agent來說，延遲就沒有那么重要了，因為你有更多的時間。Agent調用工具，因此模型需要具備強大的工具調用能力。所以，這個領域會不斷發展，將會有許多應用程序同時利用多個模型。這就是軟件開發的未來，開發者需要隨著技術的進步而不斷學習和發展。

　　共建：開源開放如何推動Agent系統與多模型未來

　　Matthew Berman：好的，你提到了開源和多模型，也提到了關于開源的一些一般性內容。微軟在Satsya的領導下，過去十年中在開源方面有了令人難以置信的轉變和采用。你今天做了一個重要的宣布，我一聽到就立刻發了推文：GitHub Copilot是開源的！這是怎么考慮的？為什么你們這么做？我們能從這樣一個強大的開源項目中期待什么？

　　Thomas：我們對今天的宣布感到非常興奮，將Copilot在VS Code中開源。這延續了VS Code作為開源編輯器的悠久歷史。事實上，就在上個月，2025年4月，VS Code迎來了10周年紀念。Satsya在主題演講中提到，在這10年間，VS Code已經發布了超過100次版本更新。幾乎每個月都有一個新版本發布。其實只有少數幾個月份，團隊沒有發布新版本。但這是穩定版本的情況。實際上，每個工作日都有VS Code Insider版本發布，我相信周末是不會發布的，至少我沒有注意到團隊在周末發布。

　　不僅如此，VS Code團隊確實像一個開源項目一樣運作。他們所有的規劃都是公開的。在VS Code的存儲庫里，他們會展示下個月的計劃。發布說明都是存儲庫的一部分，文檔，甚至博客文章也都在存儲庫中的一個文件里。因此，過去幾個月我們觀察并決定，是時候讓Copilot本身也開源，并將其整合到VS Code項目中，以繼續向開發者生態系統提供他們喜歡的東西。這個舉措是針對過去10年一直在使用VS Code、為VS Code做貢獻、支持VS Code團隊和產品的那些人。

　　另一個關鍵點是認識到，在VS Code中為Copilot編寫的客戶端代碼，實際上為那些希望構建AI軟件的人提供了很好的學習機會。不管他們是想構建一個VS Code和Copilot的競爭產品，還是想將其集成到自己喜歡的IDE中，或者為他們正在構建的新編輯器開發一個類似Copilot的工具，還是想將其整合到開發者工具棧中的全新東西里，這些代碼都可以給予啟發。通過MIT許可證，他們能夠將Copilot集成到自己的系統中，并使用我們的API，我這里指的是GitHub API和Microsoft API，因為Copilot是建立在Azure AI Foundry之上的，這對我們來說創造了業務價值，而這一點比將Copilot的部分內容保密更重要，因為這些內容最終都會泄露出去。比如，系統提示已經為人所知，而VS Code是用JavaScript編寫的，因此逆向工程Copilot并不難。實際上，自從2021年Copilot發布不久之后，就有很多人在博客文章，包括GitHub頁面上探討它是如何工作的以及在幕后如何構建提示的。

　　因為對于自動完成，你無需寫明提示，你只需編寫，然后它會收集光標上方、下方、相鄰選項卡中的文件信息、系統提示等內容。我們早在開源之前就記錄了這一切，因為人們可以輕松地逆向工程JavaScript擴展。所以對我們來說，這感覺是一個順理成章的路徑。我們為此感到非常興奮，因為我們正在回饋給予我們長期支持的社區。

　　Matthew Berman：現在，他們實際上可以在微軟的全力支持下，將其進行分叉并在此基礎上進行構建，盡管之前已經有過泄漏或公開可用的情況。

　　Thomas：我們都是工程師，能夠逆向工程。是的，可以完全分叉并為項目做出貢獻。當然，提交一個出色的拉取請求，比如說，“我在Copilot中構建了這個功能，因為我喜歡Copilot，我想回饋社區。”

　　Matthew Berman：你對看到其他外部開發者所做的工作最感興趣的是什么？是否有某些功能集或工作流是你希望能被構建到GitHub Copilot中的，而這些可能是微軟還沒有優先考慮的？

　　Thomas：哦，還沒有能夠優先考慮。我們今年及去年已經優先考慮了很多事情，畢竟現在是2025年5月。在這段時間里，已經有接近100個關于Copilot的變更日志。我們正在快速發布新功能。去年底在GitHub Universe大會上，我們宣布了多模型選擇，這讓我們非常興奮。因此，一個明顯的例子就是將其他模型引入Copilot。我們的團隊時間有限，要整合新模型，同時還要進行驗證測試和維護等工作，以便為Copilot添加官方支持的模型。

　　我們提供了"自帶密鑰"的功能，所以你實際上可以連接到OpenAI、Olama和許多其他東西。這為開發者提供了機會，可以讓Copilot與其他模型協作，進行所有的測試，甚至決定將模型托管在Azure AI Foundry上，以便推動模型領域本身的創新。雖然現在有一些大公司在這個領域中占據主導地位，但也有很多初創公司正在崛起。盡管我們喜歡相信科技行業是一個零和游戲，但總會有新的顛覆出現。沒有任何一切是固定不變的，狀態也尚未穩定，我想我們仍然對Agent模式的發展感到非常興奮，并且可以在這個領域期待很多創新。今天我們宣布了針對Java和.NET應用的App遷移，這也意味著還有很多其他編程語言沒有涵蓋。所以，你可以看到，有人可以利用Copilot并擴展Agent模式，提供從COBOL到Java或從Perl到Python的遷移。有很多技術債務問題尚未解決，不可能涵蓋世界上的所有場景。其次，就是通過查看Agent模式，理解其工作機制。也許有人有更好的想法，知道如何更好地應用這些更改，或者有一個想法，可以確保當修改出錯時，他們總是能夠回滾一兩步。因此，在許多較小的用戶體驗功能上，開發者常常有自己對某事物運作方式的想法，并與他們在VS Code項目中進行開放對話，允許他們分叉、貢獻回去，或者保持以開源分叉的形式運行。我希望這就是我們對VS Code未來的期望。

　　Matthew Berman：讓我們繼續討論未來的話題。談談軟件的未來吧。確定性代碼、傳統軟件與非確定性生成部分之間的界限變得越來越模糊。首先，您對此有什么看法？您認為未來的軟件架構狀態會是什么樣的？這條界限會如何移動？

　　Thomas：代碼希望總是具有確定性的，因為從設計上講，代碼本身就是CPU指令集的抽象。但你所說的是，我用來生成代碼的提示可能會因為模型自身的非確定性而導致不同的代碼，即使是使用相同的模型也是如此。我想象未來的軟件工程師將需要能夠在這兩個抽象層之間切換：一個是自然語言的非確定性層。在團隊中與其他工程師、產品經理或設計師互動時，總有可能出現對未來該如何構建的誤解。在多人共同開發軟件項目時，本質上就有可能產生非確定性的結果。世界上沒有一個公司，即便像GitHub這樣有3000名員工的公司，我作為CEO描述我對一個功能的愿景，三個月后，團隊返回并完全按照我的愿景構建出該功能，這并不現實。因為人類有自己的想法，他們會將我所說的內容轉換成已有的計劃，映射到其他客戶的反饋上，也許會進行競爭研究，或者意識到我描述的方案實際上行不通，我們需要做些不同的東西。

　　而當我們與模型和編程語言一起工作時，同樣的道理適用。例如，我向模型描述某個功能，實際上已經有多種方法可以在開始使用Agent模式之前與模型進行頭腦風暴，比如讓Cloud 3.7與我一起進行功能規范的討論，并告訴它產品經理給我的需求文檔，然后說：“看看我的代碼庫，我該如何實現這一點？”然后，它會利用開源庫代碼來幫你先寫規范，而不是直接寫代碼，比如以項目符號的形式寫一個Markdown文件。接著，你可能會選擇第一個項目符號和其下面的三個子項目符號，將其輸入到Agent模式中，先構建那個功能。這其實就是工程的意義所在。你把一個非常復雜的問題分解成更小的模塊，就像樂高積木或樂高積木組一樣。然后，你知道在某個點上，復雜性降低到模型可以以更加確定性的方式實現它，也就是更接近你預期的方式，你不必之后再去修改。但這里的關鍵部分是，作為工程師，他們必須知道什么時候該使用模型，什么時候該自己動手。當規范過于復雜時，模型可能只會生成垃圾。就像一些簡單的場景，你給它一個任務，比如構建GitHub，模型可能會幫你生成一個頁面，但肯定無法構建出GitHub的所有功能。或者它可能會直接告訴你，它無法做到這一點，你需要提供更具體的信息，或者告訴你它們將如何處理這個問題。當工程師達到一個合適的復雜度水平時，模型實際上能比他們自己更快地完成任務。

　　Matthew Berman：好的。像這樣理解了確定性和非確定性之間的區別，最終都歸結為確定性代碼，但也許存在一個未來，您告訴我整個操作系統實際上是在實時生成的。您認為這在遙遠的未來可能實現嗎？或者如果可能的話，大概是什么樣的時間線？

　　Thomas：總會有一個內核存在。它運行在CPU之上，可能你甚至看不到它。我確實可以看到未來的一種情況，即你不再關心運行什么操作系統。我相信，對于那些在科技領域之外的人，他們可能不太關心iPhone上的操作系統，因為很多操作系統功能，比如文件系統、終端等，已經在iPhone上被隱藏了。用戶更關心的是用戶界面和功能。如果你這樣看待這個問題，那么是的，操作系統會逐漸被隱藏。我可以想象一個世界，其中主要的用戶界面是Agent，一個聊天Agent，一個助手。例如，Ironman在他的耳朵里、房子里有Jarvis，而這個Agent可以使用軟件工具或瀏覽器來幫助你預訂旅行、購買鞋子或訂購壽司。而不是你自己去導航用戶界面，它知道你的住址、知道使用哪張信用卡、知道你的常規訂單，然后直接把東西送到你家門口。當然，至于能否真正實現這一點還有待觀察。雖然汽車可以無駕駛員駕駛，目前還沒有機器人能夠將食物帶到你家門口并敲門。因此，在這個過渡時期，你可能需要走下樓去一個盒子里取食物，而我們期望回到那種便利狀態，可以有人敲門、你開門取食物。我能想象這樣的世界，我們與Agent互動更多的世界。ChatGPT正在走向這個目標，或者看看中國的微信，也是走在這條路上，許多日常生活通過人與人的聊天、與Agent的聊天和各類小應用程序組織起來。這些小應用程序可能是實時生成的，專門針對你的場景來解決特定問題，解決完問題后就消失了，沒有持續存在的狀態，因為生成所有這些代碼太便宜了，作為一種服務去妥善保存它是不值得的。

　　及時個人應用，這是我最喜歡的例子之一，就像你提到的，你有孩子，我有孩子，在追蹤他們的零花錢，并給予他們機會查看他們在零花錢賬戶中有多少，不管那是真實賬戶還是虛擬賬戶，然后可以說，好吧，這是我這周存的5美元，我可以買一包Pokemon卡。你可以用一個服務來做這件事，但問題是顯然你需要為自己、你的伴侶和孩子們創建賬戶，現在你得管理權限，并確保給孩子們提供的功能確實符合你希望他們看到或不看到的內容，或者你可以使用像co-pilot這樣的工具生成自己的一個小型應用。這個應用可以根據你、你的伴侶和孩子們的需求進行調整，你輸入他們本周獲得的零花錢，他們可以從中虛擬提取資金，然后說，“爸爸，我想訂購這個玩具或Pokemon包。”在這條路上，我們可以想象出許多其他場景，在這些場景中，我們可以用個性化的軟件來更好地組織我們的生活。

　　Matthew Berman：我一定會和我的孩子一起做那個。

　　Thomas：這的確是一個很好的練習，其實可以讓孩子們學會編程。而其中的妙處在于，當你因為時間不夠需要回去工作或者去做其他事情，比如園藝時，他們可以繼續進行。因為所有的編程都是自然語言，它可以是英語、德語、漢語等多種語言。孩子們真的很擅長探索世界，并且有很強的探索動力，而往往是父母出了問題，比方說沒耐心了，天黑了，或者沒答案了。當我學習編程時，我家的所有人沒有一個會編程，所以我沒地方問問題。我那時只有書籍和雜志，沒有網絡。在今天的世界，只要你有任一種連接和一部智能手機，你就可以問任何與你一起并肩作戰的助手任何有關編程的問題，它會幫助你減少很多挫折感，并在你能夠進化自己的軟件的時候，正如你可以通過那些圖像生成器生成小狗的圖像一樣。

　　終點：在“vibe”和Agent之間尋找開發的理想狀態

　　Matthew Berman：好的，我想換個話題。GitHub宣布推出了編碼Agents。我相信你聽說過vibe coding。我想了解一下編碼Agents作為vibe coding的基礎層和促進者的作用。你對編碼Agents有什么看法？對于在開發中稍微放手，不必看到或理解所有代碼，而是與AI協作以獲得所需結果的這種方式，你有什么看法呢？

　　Thomas：我不認為這件事是關于“放手方向盤”的問題。事實上，這更像是你在決定一個時刻，比如說，“我是不是該讓這輛車啟動駕駛輔助系統”。當然，如果你沒法更好地完成這個動作，系統也不會幫你完成。但如今大多數的駕駛輔助系統其實仍然要求你手握方向盤，因為這是一種優勢——系統知道它并不完美，所以它會把責任保留在駕駛者身上。當然，Vamel是一個相反的例子，但Vamel目前只在某些城市中有效。要真正達到理想狀態，我們還需要一些時間。未來我們確實會走到那一步：Agent能夠在明確的范圍內構建完整應用，而你可能甚至無需查看代碼。但我始終認為，在絕大多數軟件項目中，你還是需要理解和處理代碼的。畢竟，大多數軟件開發，其實都是在維護和改進別人已經寫好的東西。即使在初創公司也是這樣，比如兩個創始人在最初六個月內完成了產品的第一版，但接下來他們就會開始招人。新加入的工程師就需要在現有的代碼基礎上繼續工作。我們很少有從零開始、完全自由開發的機會。即使你真的擁有這種機會，當你回頭看一年前寫的代碼，可能也會感到羞恥——因為你在過去一年里學到了更多，現在知道了更好的實現方式。如果你回頭看五年前、十年前寫的東西，那感覺可能更糟。所以，軟件開發的“匠心”不會被wipe coding所取代，它只會被支持、被增強。

　　從我的角度來看，wipe coding和coding Agents的興起，背后其實有兩個關鍵原因。工程特別是軟件開發，始終都圍繞著一個核心命題：我有一個想法，我希望盡快把它變成現實。但現實中常常是這樣：我有了想法，開始查資料、找庫、研究怎么實現它。到了晚上，我項目才剛剛搭建好，基本還什么都不能做，只是出現了三個按鈕。然后我心想：如果我接下來三個月持續開發，也許能接近我早上設想的目標。所以人們心中的夢想一直是：我有一個點子，我能有多快將它變為現實？過程中不需要被各種樣板代碼、復雜性、環境配置問題所困擾，比如“為什么我本地的Python又跑不起來了”之類的問題。正是wipe coding發揮巨大作用的地方——你只需要把自己的想法輸入進去，它就能幫你生成一些內容，而且通常看起來會比你自己在短時間內做出來的還要好。你可以持續“vibe”，不斷迭代，構建出原型。這正是wipe coding最強的價值所在：原型開發。

　　但另一方面，在真正的軟件項目中，就需要coding Agent的介入了。因為你仍然得考慮安全漏洞、代碼質量、團隊設定的編碼規范、性能目標等等。你不能隨意消耗CPU或GPU，特別是當你所在的團隊有預算限制時。這種限制在不同團隊中表現不同——有些團隊有較長的盈利窗口期，有些則短得多，但不管怎樣，你在為某個商業目的而構建軟件。所以你就需要一個“嚴肅的Agent”，就像一個工程師向你提交拉取請求一樣，它會向你提出代碼方案，而你來進行審查。你會運行code review Agent、執行CI/CD流程，確保測試通過。這不再是vibe coding，而更接近我們所說的Agentic DevOps：在一個成熟的軟件開發流程中引入Agent的協助。這個過程中，我會把我不想做的那些工作交給Agent，比如修bug、找安全漏洞、寫測試用例。在我的那些興趣項目里，我幾乎不寫測試——不是因為我寫的代碼完美，而是因為寫測試太無聊了。而且它并不會讓我更快實現自己的想法。所以，把這些繁瑣的事情交給Agent來處理，而我可以在本地“進入vibe模式”專注創作，這才是理想狀態——你能花更多時間寫你想寫的代碼，而那些不那么有趣但又不可或缺的事情，就交給不同的Agent去完成。

　　Matthew Berman：有些人聯系我，他們從來沒有寫過一行代碼，還有我團隊里的幾個人——他們現在正在開發應用程序。而且這些應用是真正能在他們生活中產生價值的。但在某個階段，AI Agent就會開始有些“失靈”，而這并不是因為代碼行數達到了某個明確的閾值，而是它自然而然地開始跟不上了。現在看來，我們似乎正處在一個臨界點，AI真的快要能夠vibe code更大型的代碼庫了。你認為，為了提升coding Agents的能力，最有杠桿作用的改進會是什么？

　　Thomas：你看，其實零代碼這件事已經存在有一段時間了。早在我們擁有AI之前，我們就已經在賦能一些人，尤其是IT專業人士，甚至普通用戶去構建網頁、小應用，解決一些業務邏輯問題。當時這些東西不是靠AI構建的，而是通過模板、可定制模板來實現的。但核心理念其實是一樣的：就是在不了解代碼的情況下，也能走完一段開發旅程，在某個框架下完成一些構建工作。現在AI把這個可能性極大地拓展了。AI如今所能生成的內容，即使完全不懂代碼，也能做到的事情，真的是非常驚人。但同時你也會發現，很多人在這個過程中也會走到一個節點——也就是Agent再也無法幫助他們邁出下一步的時候。到了這一步，你至少需要對系統有一定的理解，比如說：一個系統是如何架構的，如何從支持100個用戶擴展到支持1萬個用戶？又或者說，如何引入身份服務提供商來實現身份驗證？這些都是Agent目前還難以應對的。

　　未來Agent會變得更強大，但與此同時，我們人類也會提出更復雜的想法。我非常確信，大多數有志于開發軟件的人，總會有比手頭工具更宏大的想法和愿景。工具永遠追不上創意。唯一的問題是：我們如何把這些創意擴展到足以觸碰到那些工具的邊界。現實是，在我見過的幾乎所有軟件公司里，他們都有一個“無止境的待辦事項列表”。我自己也一樣。雖然說不上真的是“無限”，但它已經長到讓我明白——以我們現在所擁有的工具，加上我們的開發人員、產品經理、設計師等團隊成員，這個待辦事項列表是我這輩子都完成不了的。而在這些待辦事項列表之外，還有各種各樣的其他問題，比如技術債務、合規性問題、數據存儲位置要求、無障礙訪問標準等等，這些標準在持續演進。還有總是層出不窮的新設備、新操作系統，還有我們正在用的一些早就過時的開源庫。我們永遠不會缺活干。

　　我夢想有一天，只要打個響指，所有合規性的待辦事項列表就能瞬間清零，所有問題都得到解決。如果能做到這點，我會直接宣布勝利：AI Agent真的讓軟件開發發生了翻天覆地的變化。但即使那一刻到來，我們仍然還會有許多待辦事項列表，是關于“我們到底要實現什么”的——我們仍然需要人類之間的討論：團隊要怎么做？這個功能將來在產品中扮演什么角色？我們要怎么命名它？等等。這些還是需要人類共同參與。Agent會持續在這個旅程中幫助我們。借助它們的力量，我們將能把更多想法變成現實。

　　Matthew Berman：我很高興你提到了這一點。我自己對人工智能的未來也是極度樂觀的。我真心相信，當我們擁有“無限智能”的時候，并不是說人類會被取代，軟件工程師會被取代，而是我們將能夠解決更多的問題。比如你說的那些待辦事項，以前我們每天只能完成其中的一小部分，而現在我們可以完成更多。就像制作人Alex說的，這簡直就像是軟件工程領域的Jevon悖論——你能構建得越多，你就會想構建更多。所以這真的非常有趣。我們已經看到AI編碼出現了很多不同的形態。GitHub現在有自己的coding Agent。我們見過自動補全、VS Code的各種fork、插件，還有完全“免手動”的Agent和AI助手。那這些不同類型的AI編程輔助工具，最終會融合成一種統一的交互方式嗎？還是說，它們始終會保持某種程度的碎片化，我們根據不同的使用場景去選擇最合適的工具？

　　Thomas：兩者都有。從一個角度來說，作為科技行業的一員，我們總是傾向于設想存在某種統一的組織層，所有東西都能整合在一起。但現實情況是，系統太多了，公司太多了，商業利益也五花八門。盡管從某種角度看，一個能包辦一切的單一Agent聽起來很理想，甚至可以代替我的工作，但現實是，我們永遠都會有多個Agent。比如，你車里的那個東西——"Hey Mercedes"。我并不認為“Hey Mercedes”會和我的GitHub Copilot是同一個AI Agent。但我看到的是，這些不同的AI Agent是可以互相連接的。其實我們已經有了實現這種連接的工具，比如用GitHub登錄，系統之間的數據雖然不是完全打通，但GitHub現在已經可以和JFrog Artifactory連接了，或者與Vercel連接，然后你就可以把你的GitHub倉庫通過Next.js部署到Vercel的云平臺上了。

　　在開發者領域，我們已經實現了系統與系統之間的集成。我也可以想象這樣一個世界，你有一個個人Agent，它貫穿你整個個人生活，也許從高中開始一直到退休。它了解你的一切——你去過的旅行、拍過的照片。它很可能已經與你的手機有某種集成，因為你的手機本身就包含大量相關信息。所以當你問它“今晚吃什么”、“接下來讀什么書”、“最近有什么值得一看的節目”時，它就能給出推薦。與此同時，你還有一個 工作Agent，它來自你的雇主，擁有公司級的知識體系，了解代碼庫、GitHub，能幫助你完成在公司里作為知識工作者的各種任務。我可以想象一個未來世界，在那里，你的個人Agent和工作Agent是可以互相連接的。所以，當你在一家公司工作時，你會有一個統一的界面來使用這些Agent。而當你離職——我們每個人總會在某個時點離開公司——你就可以斷開這些連接。這樣，那些屬于你工作內容的知識就隨公司一同保留，而那些屬于你個人生活的部分，則繼續保留在你的個人Agent中。當然，這其中肯定會有交叉。比如，像這段對話，到底是屬于我的工作，還是我的個人生活？這種邊界并不總是清晰的。很可能會有一些智能Agent來輔助判斷：哪些內容是公司的知識產權，哪些內容可以保留在我的個人Agent中。

　　此外，你可能還有一個旅行Agent，或者是基于任務的Agent，比如由旅游公司或航空公司提供的Agent，幫助你預訂行程。這些Agent的數據可能會通過Agent-to-Agent協議傳遞到你的個人Agent或工作Agent中。谷歌已經在做Agent-to-Agent通信，還有像MCP這樣的技術，它們都可以接入你使用的各種工具。未來一定會出現一個Agent生態系統，而且希望這些Agent之間都是可以互聯的。最初，它們可能只是運行在操作系統上的多個app，但理想的情況是，它們都采用統一的、基于語言的用戶界面。這樣你就不需要自己在不同上下文之間頻繁切換了。畢竟，現實生活中，工作與個人生活、出差與私人旅行等，其實往往沒有那么涇渭分明，就像很多雇主所設想的那樣。

　　主持人：把“記憶”視作某種終極的治理層是一個非常有趣的思考角度。你剛才提到，或許會有另一個Agent位于更高的層級，它能識別出哪些記憶屬于公司，哪些是你個人的。這種設想讓我印象很深。我喜歡向AI領域的領導者們提出這樣一個問題：現在不僅是軟件開發，整個知識型工作的未來都讓人焦慮。很多人會問：“我會被取代嗎？”那么，你會對那些不在人工智能核心圈子里、開始感到緊張和不安的人說些什么，讓他們感到安心和有信心？你會如何回應他們？

　　Thomas：我相信將會有一些工作，也就是說，一些原本由人類完成的任務，現在模型已經可以自動執行了。翻譯就是一個這樣的例子。尤其是，如果你有兩個人彼此不會說對方的語言，我可以想象這樣一個世界：我們只需要戴上耳機，然后我說德語、你說英語，而你聽到的是我用英語說話，我聽到的是你用德語說話。這樣我們之間就不再需要一個翻譯來傳達我們說的話。所以在某些場景下，確實會需要更少的人來完成工作。與此同時，還會出現一整類由AI幫助創造的新工作。這種轉變正在發生。而且實際上如果我們回過頭來看“Co-pilot”的出現，它為地球上任何一個想成為軟件開發者的人打開了巨大的空間。你不再需要查閱文檔，也不需要家人中有能回答你問題的人，尤其是當你還是個孩子時，你甚至不需要會英語了。就像你自己提到的，你只需要創建一個小應用，然后通過提示語不斷迭代它。所以我們會看到越來越多的公司利用AI來處理那些在二十年前難以想象的用例。這應該讓我們有信心——即便現在某些人從事的工作由于AI而不再存在，他們也會通過AI的幫助重新學習技能，找到新的工作，也許那些工作甚至更有趣、更有創造性。

　　在工業革命、個人計算機的時代，這樣的事情已經發生過很多次了。某些工作被自動化取代，比如軟件行業中的用戶界面測試就是一個例子。在微軟，過去曾有一個專門的測試工程師職位。所以當時有工程師、產品經理和測試人員。而后來測試這個角色消失了，因為沒人想再手動測試軟件.大家寧愿寫自動化測試來完成這個任務。所以我們替代了測試員這個角色。但很多測試人員后來轉型成了工程師或產品經理。這是一個很好的例子，我想這就是我能給你的信心：如果你回顧過去的技術發展歷程，你會發現每當技術替代了一些崗位，我們總能為那些人找到新的機會。我相信在AI時代，這也同樣適用。

　　Matthew Berman：Thomas，非常感謝你。這次談話非常有趣，我感到非常榮幸。

　　原文章：GitHub CEO predicts the future of programming...(Full Interview)

　　https://www.youtube.com/watch?v=3WNukz5-Ch0