最危險的時刻，常常發生在 AI 幫你做的東西成功之後。
尤其是有人看完 demo，想把它拿去真的用。
想像一位診所醫師，晚上十一點半還坐在電腦前。她不是工程師，只是受夠了每個月排班：護理師不能連太多夜班、假日班要公平、新人不能單獨顧尖峰、臨時請假又會把整張表打亂。
以前她只能用 Excel 硬撐。這次，她打開 AI coding 工具，直接說：「幫我做一個診所排班工具。輸入人員、可上班時段、不能連班規則，最後產生週班表。」
幾個小時後，畫面真的跑起來了。有表單，有按鈕，有班表。醜一點，慢一點，規則也還不完整，但它可以點、可以改、可以拿給同事看。
第二天，同事看到後說：「這個下個月可以直接用嗎？」
麻煩從這一秒開始。
Vibe coding 最迷人的地方，是它讓想法第一次有形狀。醫師可以做排班系統，音樂老師可以做五線譜練習 app，社區總幹事可以做住戶報修表單。過去被工程門檻擋在外面的人，突然有能力把腦中的東西端上桌。
但試吃攤不等於餐廳。
你可以在夜市擺一張桌子，做出一碗讓路人驚艷的牛肉麵。這證明配方有機會，卻不代表你明天能供應三百桌婚宴。開店後，你要面對採購、庫存、出餐線、客訴、排班、財務，以及那個最殘酷的問題：老闆不在的時候，它還能不能正常運作？
Vibe coding 是試吃攤。
Agentic engineering 是中央廚房。
前者回答：「這個想法能不能被看見？」後者回答：「這個系統能不能被信任？」
AI agent 時代的差距，會出現在 demo 之後：誰能把一個漂亮原型，接成多人長期使用、出錯可追、責任可分的工作系統。
這個分法有社群脈絡。2025 年，Andrej Karpathy 在 X 上提出「vibe coding」，這個詞很快變成社群語言；到了 2026 年，Simon Willison 開始整理 Agentic Engineering Patterns，把重點放在能產生、執行、測試、迭代的 coding agents。Addy Osmani 在 Agentic Engineering 裡講得更直：這不是更簡單的工程，而是另一種困難，從打字時間轉成 review time，從 implementation effort 轉成 orchestration skill。
所以這篇文章先不替流行詞下定義。我更想問另一件事：當 AI 讓「做出一個東西」變便宜，什麼東西反而變貴？
Vibe coding 讓問題擁有者拿回原型權
很多人一聽到 vibe coding，就急著問：「那工程師還重要嗎？」
這個問題太快了。
Vibe coding 先改變的，是非工程師的發言權。
以前，一個現場工作者就算知道問題在哪裡，也很難把問題做成工具。醫師知道排班痛點，音樂老師知道學生卡在哪個節奏，客服主管知道新人回覆客訴時會漏掉哪些訊號，法務知道哪些合約字句看起來普通、實際上會讓公司承擔風險。
但他們要把想法變成軟體，得先通過一條漫長翻譯鏈：找人理解需求，寫規格，排工程資源，等設計，等開發，等測試。很多想法還沒被否定，就先被流程消耗掉了。
Vibe coding 把距離縮短了。
它讓問題擁有者第一次可以說：「不要只聽我描述，我做給你看。」一張可以操作的原型，比十頁需求文件更有力量。
Vibe coding 最有用的地方，是把原型權交還給懂現場的人。
Vibe coding 最有價值的地方，是讓懂現場的人第一次能把問題做成東西。
但原型權不等於營運權。
你可以做出五線譜練習 app，不代表它可以承載一千個學生帳號、付款紀錄、課程進度和家長通知。你可以做出合約摘要工具，不代表業務可以拿它直接對客戶承諾。你可以做出排班工具，不代表診所明天就能把全院班表交給它。
當一個工具從「我自己試試看」走向「大家真的要用」，故事就換了。
Demo 之後，問題才開始變硬
在 vibe coding 階段，大家問的是：「能不能做出來？」
AI 越來越常回答：可以。
但正式上線前，問題會變成另一組。
誰可以登入？資料存在誰那裡？同事改了規則，舊班表會不會壞掉？員工離職後帳號怎麼關？AI 排出違反勞基法的班，誰負責？系統半夜當機，明天門診誰上班？
這些問題沒有 demo 迷人。
但這些才是工程。
把場景放到企業裡會更清楚。
客服團隊可以 vibe code 一個 ticket 摘要工具。把客訴貼進去，AI 整理三點、判斷情緒、建議回覆。第一眼看起來很有感，因為它真的省時間。
可是主管只要說：「那我們下週把它接進正式客服流程吧。」問題馬上變成：
它能不能讀 Zendesk 或 Intercom？能不能知道這個客戶是不是 enterprise plan？能不能查 CRM 裡的續約日期？能不能看產品 bug tracker？哪些客訴不能自動回？客服覆寫 AI 建議時，理由會不會留下？
業務也是一樣。
做一個 CRM follow-up 產生器很容易：輸入客戶名稱、上次會議紀錄、下一步目標，AI 產生一封信。
但正式使用時，公司會問：CRM 資料是不是最新？折扣權限能不能限制？付款條件能不能從合約系統讀？AI 寫出不該承諾的交期時，誰批准？寄出前要不要主管 review？寄出後要不要回寫客戶紀錄？
合約工具更敏感。
你可以 vibe code 一個「合約風險標註器」，讓 AI 抓付款、保密、責任上限、終止條款。概念展示會很漂亮。
但法務真的要用，問題會變成：舊版合約要不要排除？不同國家條款規則是否不同？業務能不能看到所有合約？AI 標錯風險時，律師怎麼覆寫？下次同類條款出現，系統會不會記得？
程式寫完，這些問題才剛浮上來。
Agentic engineering 管的就是這一層：agent 怎麼讀資料、動工具、守權限、被審核，錯了還留得下線索。
實作變便宜之後，貴的不是按鈕，而是按鈕背後的責任。
Agentic engineering 管的是出餐線
如果 vibe coding 是試吃攤，agentic engineering 就是中央廚房。
你要設計的已經從菜色變成整條出餐線：食材從哪裡來，誰驗收，庫存怎麼扣，尖峰時段誰先出，客人過敏怎麼標，外送平台改單時後廚怎麼知道，少放滷蛋時要不要退費，同樣錯誤一週發生三次時，該查新人、貼紙，還是流程本身？
在 AI agent 裡，這條出餐線會變成一連串很瑣碎、但避不開的設計。
任務到底從哪裡進來？一張工單誰先看，哪些可以自動分類，哪些一定要升級，哪些只允許 AI 起草？AI 要讀哪些客戶資料、歷史紀錄、合約條款、產品狀態和公司政策？資料過期了怎麼辦，敏感資料又該擋在哪裡？
工具和權限也不能混在一起。Agent 可以查 CRM，未必能改 CRM；可以草擬 email，未必能直接寄出；可以標註合約風險，最後判斷仍然要留給法務。
越接近金流、法律、醫療、人事，系統越要懂得停下來等人。AI 做錯不可怕，可怕的是錯完沒有痕跡。客服主管把某張工單從高風險改成低風險，法務把某個條款從風險清單移除，如果這些修正只留在 Slack，下次系統還是會犯同樣的錯。
這也是為什麼 LangChain/Cisco 在談 agentic engineering 時，會把重點放在 shared memory、observability、traceability，而不只說「AI 寫 code 更快」。進入組織後，agent 會成為流程裡的一個節點；節點越多，越需要上下文、權限、紀錄和責任。
AI 會寫程式，沒有讓工程消失，只是把工程師的時間從打字推到判斷：問題怎麼定義、流程怎麼接、權限怎麼收、錯誤怎麼救。
Code 變便宜後，稀缺的東西會往上游移動：產品判斷、流程建模、權限設計、風險控制、可維護性。
Code 會變便宜，但清楚知道該做什麼、為什麼做、做到哪裡停，會變得更貴。
以前，很多人以為工程的核心是「把東西做出來」。現在，做出來越來越容易，工程的核心會變成：「這個東西應不應該被這樣做？放進哪條流程？誰能用？誰批准？錯了怎麼救？下次怎麼改？」
三個字判斷：玩具、工具、系統
判斷一個 AI 做出來的東西站在哪裡，不要先問它用了什麼模型。
先問它是玩具、工具，還是系統。
玩具階段，重點是展示。它能讓人理解概念、看見可能性、願意繼續討論。醫師排班 demo、音樂老師五線譜練習器、創業者的互動原型，都在這裡。這個階段要快，要有畫面，要讓人說：「原來可以這樣。」
工具階段，重點是穩定幫一個人或一小群人省時間。排班工具能處理常見規則，客服摘要工具每天能用，CRM follow-up 產生器能讓業務少花半小時。這時開始需要資料格式、錯誤處理、基本權限和使用習慣。
系統階段，重點是進入組織正式流程。它要多人協作、權限分層、資料同步、審核紀錄、異常處理、版本管理、指標追蹤。這個階段需要 agentic engineering。
你可以用四個問題判斷它站在哪裡。
它今天出錯，誰會受到影響？它需要讀取或寫回哪些正式系統？人類不同意 AI 的判斷時，修正會不會留下？使用人數從 1 個變成 100 個時，問題是變多一點，還是整個爆炸？
如果答案都很輕，vibe coding 可能就夠了。做概念、做展示、做個人效率工具，它非常適合。
如果答案開始涉及客戶、合約、權限、金流、個資，那就不要再把它當成單純 coding 問題。
你已經從試吃攤走向中央廚房。
想法值錢，前提是它帶著現場
很多人會說：「以後實作變便宜，想法最重要。」
這句話對，也危險。
它對，因為 AI 讓更多人可以把想法做出來。它也危險，因為「有想法」本身從來不夠。值錢的不是一句靈感，是你到底看過多少現場細節，知道哪些限制不能碰。
「我要做一個 AI 客服」太大、太空、太像公告。「Enterprise 客戶在續約前 30 天如果連續出現兩張權限相關工單，客服應該自動升級給 CSM，而且 AI 不能直接回覆，只能產生草稿與風險提示」才是有價值的想法。
「我要做一個合約 AI」也太粗。「業務上傳客戶紅線版合約時，系統先比對公司標準條款，標出責任上限、付款條件、資料使用權三類風險；法務覆寫後，理由要回寫成下一輪審查規則」才接近能落地的設計。
AI 時代不會讓所有想法都等值。它會讓模糊想法更快露出破綻，也讓懂現場的人更快把判斷變成工具。
想法要值錢，得帶著場景、限制和後果一起出現。
Vibe coding 先把第一碗麵端出來；agentic engineering 再決定這道菜能不能進菜單，廚房、品管、客訴和成本要怎麼接。
一邊讓更多人可以說：「我做給你看。」另一邊讓組織可以回答：「我們敢每天用。」
不要把試吃攤誤認成中央廚房
Vibe coding 會繼續擴散，這是好事。它會讓很多原本沒有機會被做出來的小工具、小流程、小產品，第一次被看見。
但我們也要誠實：原型和系統中間，隔著營運；跑得動和交得出去中間，隔著責任；自己用很順和全公司都能用中間，隔著權限、紀錄和救援流程。
AI agent 時代，實作會越來越便宜。很多人可以用幾個晚上做出過去要一個小團隊才做得出的東西。
可是當那個東西開始碰到客服、CRM、工單、合約、權限、個資、金流、責任和錯誤追蹤，工程就會換一種形式回來。
它不一定長得像以前那種從零手寫每一行 code 的工程。它更像是在營運中的廚房裡重新設計出餐線：哪裡可以自動化，哪裡必須人工確認，哪裡要留下紀錄，哪裡一出錯就要停下來。
所以先別急著問 vibe coding 和 agentic engineering 哪個才是真的。
更好的問法是：
你現在是在做一碗讓人驚艷的試吃麵，還是在設計一間每天都要開門的餐廳？
如果只是要讓想法被看見，vibe coding 是一把很好的鑰匙。如果要讓想法進入真實世界，服務真實的人，承擔真實的錯誤，累積真實的改進，就需要 agentic engineering。
寫程式變便宜後，工程沒有退場。它只是搬到更難外包的地方：判斷什麼值得做，怎麼放進流程，出了錯誰接，怎麼讓下一次少錯。