Karpathy：Vibe Coding 只是入門票，真正的專業叫「Agentic Engineering」

本文整理自 Sequoia Capital《AI Ascent 2026》2026 年 4 月播出的單集。

{{< youtube 96jN2OCOfLs >}}

{{< apple-podcast "tw/podcast/andrej-karpathy-at-sequoia-ai-ascent-2026-from-vibe/id1799918505?i=1000765806763" >}}

---

當你的 Agent 用 Email 配對付款帳戶

OpenAI 共同創辦人、前 Tesla AI 總監 Andrej Karpathy 做了一個叫 MenuGen 的副專案：拍一張餐廳菜單的照片，AI 自動辨識菜名並生成每道菜的圖片。這個 app 是他用 vibe coding 的方式打造的，部署在 Vercel 上，功能完整，一切看起來很美好。

直到他發現了一個荒謬的 bug。MenuGen 的使用者用 Google 帳號登入，但購買點數時走的是 Stripe 付款。兩邊都有 email 地址，而他的 AI agent 在實作時，居然用 email 去交叉比對兩個系統的使用者身份。問題是，你的 Google 帳號和 Stripe 帳號完全可以用不同的 email。結果就是：有人付了錢，系統卻沒把點數加到他的帳號上。Karpathy 在 Sequoia Capital 的 AI Ascent 2026 活動上分享這個故事時，語氣帶著苦笑。任何有經驗的工程師都知道應該用唯一的 user ID 來串接不同服務，但 agent 就是做出了這種決定。

這個故事完美說明了一件事：AI agent 已經強大到能幫你從零建出一個完整的 app，但它在高階設計決策上仍然會犯低級錯誤。而這正是 Karpathy 要區分 vibe coding 和 agentic engineering 的原因。

地板和天花板：兩種完全不同的事

Karpathy 給出了一個簡潔的框架。Vibe coding 關注的是「拉高地板」：讓原本不會寫程式的人也能打造軟體，讓進入門檻大幅降低。這件事已經在發生，而且效果驚人。但 agentic engineering 關注的是「維持天花板」：你的軟體品質不能因為用了 AI 就打折。你不能因為 vibe coding 方便就引入安全漏洞，你仍然要對你的程式碼負全部責任，就跟以前一模一樣。

他把 agentic engineering 定義為一種工程紀律。你手上有這些 agent，它們非常強大，但本質上是「帶刺的」（spiky）實體：有點不可靠、有點隨機、偶爾會做出莫名其妙的事。如何協調這些 agent 來加快開發速度，同時不犧牲品質，就是 agentic engineering 的核心挑戰。Karpathy 認為這不只是一組技巧，而是一門新的工程學科，就像過去的系統工程或軟體工程一樣，會有自己的原則和最佳實踐。

過去業界常說「10 倍工程師」（10x engineer），形容那些產出遠超同儕的頂尖開發者。Karpathy 觀察到，在 agentic engineering 的框架下，10 倍已經不是正確的衡量尺度了。那些真正擅長這套工作流的人，產出的提升遠遠超過 10 倍。差距不在手速，在於你能不能有效地指揮和監督多個 agent 同時運作，在於你能不能設計出讓 agent 高效運轉的任務架構。

人類還剩下什麼？品味、架構、和那些 Agent 不在乎的事

Karpathy 的答案很明確：人類負責品味、判斷和高階設計，agent 負責執行細節。他用自己的工作經驗舉例。以前寫 PyTorch 或 NumPy 的時候，你得記住一堆 API 細節，像是到底是 keepdims 還是 keepdim，參數叫 dim 還是 axis，要用 reshape 還是 permute 還是 transpose。他說他現在完全不記得這些了，因為不需要了。Agent 在這種細節上的記憶力比人類強得多，交給它就好。

但你不能不知道的是底層原理。比如，tensor 在記憶體中怎麼存放，view 和 storage 的關係是什麼，什麼操作會觸發不必要的記憶體複製。如果你連這些基礎概念都不懂，你就沒辦法判斷 agent 給你的程式碼是否高效，甚至不知道該問什麼問題。Karpathy 形容這種關係像是一個主管帶著能力很強但缺乏全局觀的實習生：你得負責 spec、架構、以及確保整體系統合理，實習生則負責填入細節。

還有一個 AI 目前做不好的事：簡化。Karpathy 提到他有一個叫 MicroGPT 的專案，目標是把 LLM 訓練的程式碼精簡到極致。他反覆要求 AI 幫他簡化，但 AI 就是做不到。他形容那種感覺像是「明顯跑出了 RL 的電路之外」，因為簡化程式碼這件事不在模型的獎勵函數裡。模型被訓練成能寫出「正確且能運作」的程式碼，但不擅長寫出「優雅且精簡」的程式碼。他甚至有點被 agent 寫出來的東西嚇到：能跑，但很臃腫，到處是複製貼上，抽象層設計很脆弱。程式碼的美學標準，目前仍然是人類的領地。

招募方式也該改了

如果 agentic engineering 是一門新的工程學科，那招人的方式也得跟著變。Karpathy 直言，多數公司的面試流程還停留在舊時代：出一道演算法題，看你在白板上怎麼解。這在 AI agent 已經能輕鬆解決大部分程式題的時代，已經不太能測出真正重要的能力了。

他提出了一個新的面試思路：給候選人一個大型專案，比如「用 agent 打造一個 Twitter 的克隆版，然後把它部署上線，做到真正安全」。接著，用十幾個 Codex agent 去嘗試攻破這個網站。如果你部署的服務能扛住這些 agent 的攻擊，那你就展現了真正的 agentic engineering 能力。這個測試衡量的不是你能不能手寫某個演算法，而是你能不能架構一個完整的系統、利用 agent 高效開發、同時確保安全性和可靠性。

Karpathy 觀察到的現實是，大部分組織還沒做這個轉變。他們仍然在用解小題目的方式來篩選人才，而真正的 agentic engineering 高手可能在這種面試中表現平平，因為他們的優勢在於統籌和系統設計，不在於手寫快排。這是一個整個產業都需要面對的結構性錯配。

不能外包的那件事

在訪談的最後，Karpathy 引用了一句讓他反覆思考的話：「你可以外包你的思考，但不能外包你的理解。」這句話精準地劃出了人機協作的邊界。AI agent 可以幫你執行、幫你查資料、幫你寫程式碼、幫你跑測試。但如果你自己不理解系統的基本原理，不理解你要解決的問題的本質，你就沒辦法有效地指揮這些 agent。

Karpathy 說他現在花很多時間用 LLM 來建構自己的知識庫。每讀一篇文章，他就把它加進自己的 wiki，然後從不同角度去提問、去探索。每一次對資訊的「重新投影」，都讓他產生新的洞見。但他也坦言，真正的瓶頸還是自己的理解力。LLM 可以無限地產出資訊，但人類消化和綜合資訊的頻寬是有限的。

這或許是對 agentic engineering 最根本的定義：它不是學會用哪些工具，而是在 agent 越來越強大的時代，持續深化自己對技術和問題的理解。工具會換，框架會變，但理解力是你唯一帶得走的東西。最終，好的 agentic engineer 不靠工具取勝，靠的是真正理解自己在建造什麼、以及為什麼要建造。