Agentic Engineering 是什麼？為什麼 Karpathy 要發明這個詞
這是「Agentic Engineering 實戰手冊」系列的第一篇。完整系列共 16 篇，從基礎認知、工作流到團隊導入，也收錄兩篇實際專案紀錄。
2025 年我們在 Vibe Coding，2026 年呢？
2025 年 2 月 2 日，Andrej Karpathy 在 X 上發了一則貼文，形容自己把工作交給 LLM、幾乎忘了 code 的存在，只憑感覺一路嘗試。他把這叫做 Vibe Coding。
那條推文爆了。整個 tech 圈都在討論。有人覺得這是解放，有人覺得這是墮落。但不管你站哪邊，Vibe Coding 確實描述了一個真實的現象：越來越多人開始「感覺對了就好」地用 AI 寫 code，不太在意細節，反正跑得動就行。
一年後，2026 年 2 月 20 日，同一個 Karpathy 又發了一則貼文。他說自己現在最喜歡用 Agentic Engineering 描述這種工作：大部分時間不再親手敲 code，而是在編排 agent；但要把軟體可靠地做出來，仍然是一門工程。
為什麼？因為過去這一年，整個產業發生了根本性的轉變。AI 不再只是你問它問題然後複製貼上答案的工具。它變成了 agent——能自己讀 code、自己寫 code、自己跑測試、自己修 bug 的自主行動者。而你，變成了管它的人。
這個轉變需要的不是 vibes，是扎扎實實的工程。
作為一個從 2025 年初就開始 100% agent-first coding 的人，我親身經歷了這一年的演化。從一開始覺得「哇這好方便」，到中間覺得「等等，它怎麼又寫錯了」，到現在理解「原來管 agent 是一門學問」——這篇文章想跟你分享的，就是這段旅程。
從 Vibe Coding 到 Agentic Engineering：一年的演化
如果要畫一個光譜，軟體開發的方式正在經歷這樣的演化：
| 階段 | 時期 | 你在做什麼 | AI 在做什麼 |
|---|---|---|---|
| Manual Coding | ~2022 前 | 自己寫每一行 code | 不存在 |
| AI-Assisted | 2022-2024 | 自己寫，AI 幫忙補完 | Tab completion、回答問題 |
| Vibe Coding | 2024-2025 | 描述你要什麼，AI 寫 | 產生大段 code，你複製貼上 |
| Agentic Engineering | 2025-now | 定義目標和限制，管理 agent | 自主讀 code、寫 code、跑測試、修 bug |
關鍵的轉折點在 2025 年中。那時候 Claude Code、Cursor Agent Mode、Codex CLI 這些工具開始成熟，AI 不再只是「給你一段 code 讓你貼」，而是可以直接操作你的 codebase、跑你的 test suite、甚至自己 commit code。
我記得很清楚第一次讓 Claude Code 自己修一個 bug 的感覺。我只說了「這個 API 在特定 payload 下回 500，error log 在這裡，請找到 root cause 並修好它」，然後它就開始自己讀 code、自己找問題、自己寫修復、自己跑測試。
我去倒了杯咖啡回來，bug 修好了。
那一刻，我意識到我的角色不一樣了。我不是在「寫 code」，我是在「管一個會寫 code 的 agent」。
但 Vibe Coding 和 Agentic Engineering 的差別，不在工具，在心態。Vibe Coding 是「反正 AI 會搞定，我不需要太認真」。Agentic Engineering 是「正因為 AI 在搞定，我需要更認真地管理這個過程」。
Agentic Engineering 的定義：不只是「用 AI 寫 code」
Karpathy 解釋這個詞的時候，把它拆成兩半：
Agentic——因為你的預設模式不再是自己寫 code，而是讓 agent 去寫。你從 creator 變成了 orchestrator。
Engineering——因為怎麼編排 agent、怎麼提供 context、怎麼驗證產出、怎麼管理品質，這裡面有系統性的學問。不是 vibes，是工程。
如果把我這一年踩過的坑，連同 Simon Willison 整理的 Agentic Engineering Patterns 放在一起看，大致會落在五個原則：
- Plan before prompting——先寫 spec，再讓 agent 動手
- Direct with precision——給 agent 明確的、有範圍的任務
- Review rigorously——像 review 人類的 PR 一樣 review agent 的產出
- Test relentlessly——測試提供可重複的品質證據，但不能取代 review
- Own the system——維護文件、版本控制、CI/CD，你是最終負責人
Simon 的重點其實很務實：coding agent 之所以特別，不只是能產生程式碼，而是能讀檔、執行工具、跑測試，再根據結果繼續修。這也代表自動測試、lint、文件與 CI 會直接影響它能不能有效自我修正。講白了，好的工程習慣沒有被 AI 淘汰，反而被它放大了。
那它跟其他術語到底差在哪？簡單整理：
| Prompt Engineering | AI-Assisted Coding | Vibe Coding | Agentic Engineering | |
|---|---|---|---|---|
| 核心活動 | 寫好的 prompt | 用 AI 補完 code | 描述需求讓 AI 寫 | 編排 agent 自主完成任務 |
| 品質責任 | 你寫的 code | 你寫的 code | 你不太確定 | 你 review 的 code |
| 工程紀律 | 低 | 中 | 低 | 高 |
| 適用場景 | 問答、文字 | 日常 coding | Prototype、demo | Production-grade 開發 |
Agentic Engineering 不是 Vibe Coding 的「升級版」。它跟 Vibe Coding 的關係，更像是 DevOps 跟「手動部署」的關係——本質上是不同的方法論，要求不同的技能，產出不同品質的結果。
數據說話：AI 很普及，agent 還沒有
JetBrains 在 2026 年 1 月調查了約 11,000 人：90% 的受訪者工作中會用 AI，但真正使用 coding agent 的只有 22%。把「用過 ChatGPT」和「把任務交給 agent」混在一起，會把成熟度看得太樂觀。
另一個常被轉述的數字來自 Anthropic 內部研究：受訪工程師自評約 60% 的工作會碰到 AI，生產力提升約 50%；可是多數人真正完全委派、不介入的工作只占 0–20%。這是單一公司的自陳資料，不宜直接外推到所有開發者，但它至少提醒我們：使用得多，不等於可以不監督。
Benchmark 也要小心讀。SWE-bench Verified 是 500 題、經人工篩選的子集；Scale 在 2025 年 9 月推出 SWE-bench Pro 時，曾出現 Verified 超過 70%、Pro 約 23% 的落差。那是不同資料集與評測環境下的歷史快照，不是可以直接相減的「真實能力差 49%」，更不是今天的即時排行榜。
Gartner 的原始說法也比二手標題更精確：它預測到 2027 年底，超過 40% 的 agentic AI 專案可能因成本、價值不清或風控不足而取消。這談的是專案治理，不是 coding agent 的單一準確率。
這些數據告訴我們什麼？Agent 很強大，但不是魔法。用好它，需要方法論。這就是 Agentic Engineering 存在的意義。
為什麼 Agentic Engineering 比傳統寫 Code 更難
這是 Agentic Engineering 最反直覺的地方：用 AI 幫你寫 code，居然比自己寫還需要更高的工程紀律。
原因藏在 context 裡。傳統寫 code 的時候，你可以在腦子裡 hold 住很多隱性的 context——你知道公司用什麼 tech stack、你知道這個 API 的 quirks、你知道上次那個 bug 是怎麼修的。這些資訊不需要寫下來，因為它在你腦子裡。
Agent 寫 code 的時候，它什麼都不知道。它只知道你告訴它的東西。如果你沒有把 coding conventions 寫在 CLAUDE.md 裡，它就會自己發明一套。如果你沒有寫測試，它就不知道自己寫錯了。如果你沒有 CI/CD pipeline，你就得自己一行一行看它寫的 code。
所以 Osmani 說的 paradox 是真的：
Agent 越自主，你的工程基礎設施就需要越完善。
具體來說：
- 沒有自動測試？ Agent 不知道它寫的 code 是不是對的。你也不知道。
- 沒有 linting/formatting？ Agent 每次寫出來的 code style 都不一樣。
- 沒有清楚的文件？ Agent 會自己猜你的架構意圖，通常猜錯。
- 沒有 CI/CD？ 你得手動驗證每一次 agent 的產出。
在傳統開發裡，團隊有時會靠資深工程師的隱性知識撐住缺口；換成 agent 之後，這些缺口會更快暴露。測試、文件與 CI 本來就重要，只是現在不只人類需要，agent 也得靠它們取得回饋。
但反過來想，這其實是好消息。
如果你是那種一直堅持寫測試、維護文件、設定 CI/CD 的「無聊工程師」，恭喜你——你在 agent 時代突然變成最有價值的人了。因為你的工程基礎設施不只讓人類團隊工作得更順暢，現在還讓 AI agent 工作得更好。
你花在「boring engineering」上的時間，現在多了一個會重複使用它的對象。
這個系列要帶你去哪裡
這是一個 16 篇的系列，分成四個 Part：
Part I：基礎認知（你在這裡）
- Agentic Engineering 是什麼（本篇）
- 從「寫 code 的人」到「管 agent 的人」——工程師角色的重新定義
- 2026 年工具全景圖——Cursor、Claude Code、Codex、Devin 的深度比較
Part II：核心技術
- Context Engineering 深度解析——你餵給 agent 的 context 決定一切
- Spec-Driven Development——寫給 agent 的需求文件
- Agent 產出品質保證——怎麼知道 agent 寫的 code 是對的
- 從 Prompt 到 Production——完整實戰紀錄
- CLAUDE.md 大師班——設定檔系統設計
Part III：系統設計
- MCP 與 A2A 協議實戰——讓 agent 連接更大的世界
- Multi-Agent 編排——多 agent 協作的實務
- Token 經濟學進階——成本控制
- Agent 安全網設計——當 AI 有 sudo 權限
Part IV：組織與未來
- 團隊導入——從個人到團隊的文化轉變
- 未來展望——工程師還需要寫 code 嗎？
- 7 個 subagent 蓋完 TaiwanSalary——分階段編排的完整實錄
- 把工作交給 AI 的四個段位——用四種 loop 設計持續工作流
每一篇都可以獨立閱讀，但它們也是一本書的章節——從「這是什麼」到「怎麼做」到「怎麼做好」到「怎麼帶團隊一起做」。
如果你已經讀過我之前寫的 Agent First 日常，那篇是我個人經歷的描述。這個系列則是方法論的整理——我把一年的經驗，提煉成一套可以複製的框架。
Takeaway
-
Agentic Engineering 不是 Vibe Coding 的升級版，而是一個要求更高工程紀律的新學科。Karpathy 用這個詞取代 Vibe Coding，是因為「靠直覺」的方式在 production 環境裡行不通。
-
使用 AI 和委派給 agent 是兩回事。現有調查顯示 AI 使用率很高，但 coding agent 的採用率與完全委派比例都低得多。這個落差要靠 Context Engineering、Spec-Driven Development 與驗證流程來縮小。
-
好消息是：紮實的工程基礎在 agent 時代比以前更有價值。自動測試、CI/CD、清楚的文件——這些「無聊」的工程實踐，現在不只服務人類團隊，也是 agent 能否正常工作的前提。
