AI 寫程式的真相：從 Vibe Coding 到軟體工程的未來

本文整理自《Lex Fridman Podcast》2026 年 2 月播出的第 490 集。

本文是 Lex Fridman Podcast #490 系列整理的第一篇，共四篇：

1. AI 寫程式的真相（本篇）
2. Scaling Laws 還沒撞牆，但遊戲規則正在改寫
3. 開源 vs 閉源、中國 vs 美國：AI 的新冷戰已經開打
4. 通往 AGI 的路上，我們更可能先遇到什麼？

一場近五小時的 AI 現況盤點

Lex Fridman 這集找來兩位在 AI 研究圈第一線工作的人：Sebastian Raschka 與 Nathan Lambert。Sebastian Raschka 是 Lightning AI 的資深研究工程師，寫過暢銷書 Build a Large Language Model (From Scratch)，也經營 Ahead of AI 電子報，長年追蹤 LLM 技術演進。Nathan Lambert 是艾倫人工智慧研究所（AI2）的後訓練團隊負責人，主導 Atom Project（美國開放模型計畫），去年出版的 Reinforcement Learning from Human Feedback 是 RLHF 領域的重要著作。

這場對談長達四小時三十九分鐘，涵蓋 pre-training、post-training、AI coding、開源生態、中國模型、AGI 時間表等十幾個主題。本文聚焦在最貼近開發者日常的段落：AI 到底把「寫程式」這件事改變了多少？改變了什麼？改變的邊界又在哪裡？

資深工程師反而更依賴 AI 生成的程式碼

Lex Fridman 在節目中提到一份針對 791 位專業開發者（工作經驗十年以上）的調查。結果顯示，不管資深或資淺，工程師都在把 AI 生成的程式碼直接用在正式出貨的產品中。大多數人使用 AI 生成的比例在 50% 左右，甚至更高。而在「超過 50% 程式碼由 AI 生成」這個類別裡，資深工程師的比例明顯高於資淺者。

這個結果乍看違反直覺。一般會預期新手更依賴 AI 來補足自己不會的東西，但實際上是老手用得更兇。Sebastian Raschka 的解讀是：「專家更擅長使用 AI，也更擅長審查程式碼。他們知道什麼時候該用、怎麼用、怎麼判斷結果是否可靠。」重點不是 AI 還不夠好，而是有效運用 AI 工具本身就是一種需要經驗的技能。

這裡藏著一個令人不安的訊號。如果使用 AI 寫程式是一種需要累積的能力，新手要怎麼培養？Sebastian 提出了一個教育上的兩難：「如果你從來不自己動手嘗試，從來不經歷掙扎的過程，你可能永遠無法達到那個能有效運用 AI 的專家水準。」他建議每天留兩個小時不用 AI、純手動學習，其餘時間再搭配 AI 工作。聽起來簡單，但在工作進度的壓力下，有多少人真的做得到？

Claude Code vs Codex：根本是兩種東西

談到具體的 AI coding 工具，Nathan Lambert 的觀點很鮮明。他認為 Claude Code 和 OpenAI 的 Codex 代表兩種截然不同的開發哲學。Claude Code 讓使用者「用英文在宏觀層面寫程式」，你描述你要什麼，它幫你完成整個模組。Codex 那種逐行生成、微觀管理程式碼產出的模式，使用體驗完全不同。

Nathan 還透露了一個有趣的細節：Anthropic 內部大量使用 Claude Code 來建造 Claude Code 本身。他引述 Dario Amodei 談過 Claude 的使用狀況，推測這些在前沿實驗室工作的人，花在 AI 推理上的錢可能是一般使用者的 10 到 100 倍。「我們用的是每月 100 到 200 美元的訂閱方案，他們是真的放手讓它跑。」

這帶出一個容易被忽略的現實：目前 AI coding 工具之間的巨大體驗差距，可能不完全是工具本身的問題，而是使用量級的問題。每個月投入的推理成本從 200 美元變成 2000 美元，得到的結果可能完全不同。Nathan 直接點出：「進入這個世界的門檻可能是每月 2000 美元，只有科技公司和有錢人負擔得起。」

「超人類程式設計師」是個不精確的說法

Lex Fridman 追問了一個很多人心裡的疑問：AI 會不會成為「超人類程式設計師」（superhuman coder）？Nathan 的回答很直接，這個說法本身就有問題，因為它暗示了一種完整性。實際情況是，AI 在某些類型的程式碼上已經超越人類，在另一些領域卻還很笨拙。

他用「jagged frontier」（鋸齒狀前沿）來描述這個現象。AI 寫網站、做資料分析的能力已經非常強，但面對分散式系統訓練、需要多組 GPU 溝通的基礎架構程式碼，模型表現仍然很差，因為這類程式碼的訓練資料本來就極為稀少。Nathan 認為，人類的創造力會去利用 AI 超強的部分來補足弱的部分，形成一種持續的協作。「最優秀的 AI 研究者，是那些最能發揮這個超能力的人。」

Sebastian Raschka 從更長遠的角度提了一個類比：LLM 解決程式設計的方式，最終會像計算器解決計算一樣。「我不懷疑 LLM 在某個時間點會在某種意義上『解決』coding，就像計算器解決了計算。你永遠不需要人類去算那個數字了。但問題是，那個指揮的人還在不在？會不會有 AI 自己決定要蓋什麼網站、自己動手？還是永遠需要一個人類說『幫我蓋這個』？」

從零重建 Slack，但「差不多」和「完全」之間差了一個世界

Nathan 分享了一個案例：Anthropic 今年某次 Claude 發布時，其中一項測試是給 Claude 一份軟體的規格描述，讓它在沙盒環境中獨立運作，嘗試從頭重建整個軟體。結果，Claude 幾乎可以從零重建 Slack。

Lex 聽到這裡的反應很精準：「我喜歡 ‘幾乎’ 這個詞。」

這個「幾乎」的差距，正是整場討論的核心張力。從頭蓋一個東西，和在一個已經運行多年、充滿歷史包袱的 codebase 上加功能，是完全不同的挑戰。Nathan 因此做出一個推論：「也許較小、較新的公司反而佔優勢。它們不需要處理那些臃腫和複雜性，這個未來對它們更有利。」

但 Lex 持保留態度。他身邊有很多程式設計師，不少人對 AI coding 的能力偏向懷疑。他舉了一個例子：如果你想在 Chrome 瀏覽器裡把標籤頁從上方移到左側，聽起來很簡單，但在 Chrome 這麼龐大的 codebase 裡實現？「這不是明年就能做到的事。」

Nathan 沒有反駁，但提了一個折衷觀點：也許短期內 AI 不會改寫 Chrome，但在 Slack 或 Microsoft Word 這樣的產品中，AI 很可能已經可以端到端地實作新功能。「如果組織允許的話，AI 可以很輕鬆地實作你想嘗試的功能，而且做得還不錯。」

工程師的未來：不是不寫程式，而是當好「技術主管」

三個人對軟體工程師角色轉變的看法高度一致。Nathan 的描述最有畫面感：未來幾年內，很多人會被推向更接近「設計師和產品經理」的角色，手上管理多個 AI agent。這些 agent 可能花一到兩天實作一個功能或嘗試修復一個 bug。工程師的工作變成在 dashboard 上審查 agent 的產出、給回饋、決定方向。

Sebastian 的觀點則帶著一層對人類心理的擔憂。他問了一個少有人問的問題：「如果你把寫程式完全交給 AI，而寫程式正好是你熱愛的事，那你每天八小時都在管理一個替你寫程式的東西，兩年後你還會有成就感嗎？還會對工作感到興奮嗎？」

這不只是效率問題，是工作意義的問題。Sebastian 把它比喻成聖誕禮物：「我小時候覺得期待禮物的過程比拿到禮物更開心。吃東西也是，餓的時候特別好吃。debugging 也一樣，過程很痛苦，但找到 bug 的那一刻是世界上最棒的感覺。」如果 AI 跳過了所有掙扎的過程，直接給你答案，那份成就感也就消失了。

Lex 從另一個角度補了一個比較溫暖的觀察。他坦言，對他來說 AI coding 最大的價值不是效率，是「不再孤獨」。寫程式本質上是很寂寞的活動，有了 AI 就像有了一個 pair programmer。「它可能找不到 bug，但它能給你一些直覺上的提示，你們一起穿越沙漠，一起找到那口水。」

我的觀察：從祖克柏的預測到一年後的現實

去年五月，祖克柏在 LlamaCon 2025 預測「一年內 50% 的開發工作會由 AI 完成，而不是人類」。微軟執行長納德拉在同一場對談中也證實，微軟部分專案已有 20-30% 的程式碼由 AI 撰寫。九個月過去了，Nathan Lambert 在這集描述的實況是：Claude Code 可以從零幾乎重建一個像 Slack 這樣的軟體，但面對複雜的分散式系統和前沿研究程式碼，模型仍然力不從心。

這個落差本身就說明了 AI 寫程式的本質。它不是均勻進步的。某些領域早已超越人類，某些領域卻還在犯「連續 14 次嘗試同一個你沒安裝的 CLI 指令」這種低級錯誤（Nathan 在節目中的原話）。祖克柏的預測不能說錯，但需要加上很多星號。「50% 的程式碼由 AI 產生」和「50% 的軟體工程工作由 AI 完成」是兩件非常不同的事。

Vibe Coding 不是跟著感覺走

吳恩達（Andrew Ng）幾個月前在 LangChain 大會上說了一段讓很多開發者有共鳴的話：他不喜歡「Vibe Coding」這個詞，因為它暗示使用 AI 寫程式是一件輕鬆隨意的事。「用了一整天 AI 寫程式之後，坦白說，我已經精疲力盡了。這是深度的智力活動。」

Nathan Lambert 在這集提供了同樣的觀察，但從技術層面解釋了原因。當你使用 Claude Code 這類工具，角色從「寫程式的人」變成「設定目標、審查品質、判斷方向、管理多個 agent 並行的人」。這不是更輕鬆的工作，是認知負荷更高的工作。你需要理解整個系統的架構才能有效下指令，需要足夠的經驗才能判斷 AI 產出的品質，需要持續的注意力去追蹤多條平行的開發線。

Sebastian 補了一個更根本的觀點：很多人對 AI coding 感到懷疑，「不是因為 LLM 做不到某件事，而是人們不想讓它用這種方式去做。」這涉及控制感、技藝感和專業認同。Lex 說得更直白：「有些時候，對 AI coding 的懷疑其實是人類這邊的 skill issue。就像親密關係裡的溝通問題，你假設 AI 會讀心術，但其實你需要用自然語言清楚描述你要什麼。」

Computer Use 為什麼比 AI 寫程式更難

對談中有一段很有意思的岔路：三個人從 AI coding 聊到了 computer use，也就是讓 AI 直接操控你的電腦螢幕去完成任務。Nathan 的評價很直接：「2025 年多家實驗室都展示了 computer use 的 demo，Claude 可以用你的電腦、OpenAI 有 Kua，但它們都很爛。」

為什麼寫程式可以做得這麼好，操控電腦卻這麼難？Nathan 解釋了結構性的原因。AI 寫程式時是透過 API 在後端直接呼叫工具，但 computer use 需要接管整個螢幕，要和 Google、Amazon、Slack 各自用完全不同於人類的方式互動。而且你不能讓 AI 直接在你的 MacBook 上跑，需要建立一個獨立的環境讓模型作業。這些都是結構性的障礙，不是單純「模型變聰明」就能解決的。

Sebastian 點出了另一個更基本的問題：規格（specification）。讓 AI 幫你寫程式時，你可以描述需求、看到程式碼、給回饋、逐步修正。但讓 AI 幫你訂機票呢？你可以說出最終目標，可是中間出錯了，你要怎麼在 AI 嘗試操作之前就給它足夠的引導？介面設計的問題遠比技術能力的問題更難解。

每月 2000 美元的 AI 寫程式門檻

討論 AI coding 的經濟面時，Nathan 提了一個可能讓很多人不舒服的數字。他認為要真正體驗 AI coding 的完整潛力，所需的推理費用可能是每月 2000 美元，「而這只有科技公司和有錢人負擔得起。」

這不是危言聳聽。Lex Fridman 也承認，他大量使用 Cursor 的原因之一就是它快，而速度背後是成本。Nathan 還提到 Cursor 有一個做法讓他印象深刻：他們的 Composer 模型（一個基於中國大型混合專家模型的微調版本）每 90 分鐘根據使用者的真實回饋更新一次模型權重。這可能是目前最接近「真實世界強化學習」的產品化案例。

如果 AI coding 的完整體驗需要高額投入，那它創造的生產力差距就不只是「會用 vs 不會用」，還有「付得起 vs 付不起」。這對全球開發者社群的影響，可能比工具本身的技術進步更深遠。

最實用的啟示：不要再猶豫了

對臺灣的軟體工程師來說，這場對話有一個不太舒服但必須面對的訊號。AI coding 的能力每幾個月就躍進一次，還在猶豫要不要把 AI 融入工作流的人，和已經把 AI 當成核心開發工具的人之間，生產力差距正在以非線性的速度拉開。

Nathan 在節目裡說了一段話：一年前我們還沒有 Claude Code，也沒有真正的推理模型。一年後的今天，這些工具已經能從零重建一個 Slack。而且目前模型的失敗模式「都是很蠢的錯誤」，從建模的角度來看「是可以修的」。改善的空間還很大，而且是可預見的改善。

問題不是 AI 會不會取代工程師，而是「會用 AI 的工程師」正在跟「不用 AI 的工程師」拉開距離。Sebastian 給了最務實的建議：每天留兩小時離線學習、打好基礎，其餘時間全力搭配 AI 工作。這個方法不性感，但可能是目前最聰明的做法。