[IND] 7 分鐘閱讀OraCore 編輯部

Vibe Coding 和 Agentic Engineering 開始混在一起

Simon Willison 認為 AI 寫程式工具正在模糊 vibe coding 與 agentic engineering 的界線,連正式軟體開發的審查與信任方式也一起變了。

分享 LinkedIn
Vibe Coding 和 Agentic Engineering 開始混在一起

Simon Willison 認為,AI 寫程式工具正在讓 vibe coding 和 agentic engineering 的界線變得很難分。

說真的,這題不是在聊玩具專案。它是在聊正式上線的軟體。Simon Willison 在 2026 年 5 月 6 日寫下這篇觀察,重點很直接:像 Claude Code 這類工具,已經強到會改變他看 code 的方式。

他不是在講「AI 會不會寫程式」。那題早就過了。現在真正麻煩的是,當 agent 寫出來的 code 看起來夠好,你還要不要一行一行檢查。這件事,才是工程師會卡住的地方。

SignalValueWhy it matters
Post date2026-05-06這是當下評論,不是回頭看
Code output example200 lines/day 到 2,000 lines/day顯示產能假設被改寫
Experience cited25 years說明他有足夠資歷判斷工具差異
Podcast sourceHeavybit High Leverage他從這裡開始談界線變模糊

vibe coding 和正式開發,差在哪

訂閱 AI 趨勢週報

每週精選模型發布、工具應用與深度分析,直送信箱。不定期,不騷擾。

不會寄垃圾信,隨時可取消。

Willison 早就把這兩件事分開講。他在 Not all AI-assisted programming is vibe coding 裡說得很清楚。vibe coding 比較像隨興做東西。你要的是結果。能跑就好。

Vibe Coding 和 Agentic Engineering 開始混在一起

正式工程就不是這樣了。你要想的是安全性、維護性、部署、效能,還有之後誰來接手。講白了,就是你不能只看「有沒有做出來」。你還得看「能不能長期活下來」。

以前這條線很明顯。現在不明顯了。因為工具真的變強了。agent 不只會補幾行 code,還會自己拉 tests、補註解、整理結構。這就讓很多老工程師開始懷疑自己以前的判斷法還準不準。

  • vibe coding 比較像個人試驗。
  • agentic engineering 盯的是正式產品。
  • 工具越強,review 的邊界越模糊。
  • 「看起來像樣」不再代表「真的成熟」。

真正麻煩的是信任

這篇最有意思的地方,不是速度。是信任。當 agent 可以穩定寫出 JSON API、補測試、寫文件,你就很容易少看幾眼。這很正常。人類本來就會偷懶。

Willison 把這件事拿去類比公司內部服務。你不會每次都去讀影像縮放服務的原始碼。你看文件,知道它能用,然後就接著做自己的功能。AI 工具現在也開始像這種「你會先信一下」的元件。

“Claude Code does not have a professional reputation!” — Simon Willison

這句話很重。人有 reputation。模型沒有。人做久了,大家知道誰穩、誰雷。模型不會累積這種社會信用,但它可以一直吐出看起來很完整的 code。這才麻煩。

還有一個風險更陰。那就是 normalisation of deviance。簡單講,就是你一直沒出事,就開始放鬆標準。今天是小功能,明天是核心流程。等你發現時,信任門檻已經被你自己調低了。

為什麼軟體品質更難看了

AI 把很多表面訊號搞弱了。以前你看到一個 GitHub repo,有 100 個 commits、完整 README、測試齊全,通常會覺得這人很認真。現在不一定。半小時內也能做出差不多的外觀。

Vibe Coding 和 Agentic Engineering 開始混在一起

所以判斷軟體品質的方法要換。Willison 說,他現在更看重實際使用。不是看文件漂不漂亮,也不是看首頁多工整。是看這東西有沒有真的被用兩週、兩個月,甚至更久。

這裡很現實。真正有用的東西,通常會留下痕跡。會有 bug report。會有使用者抱怨。會有版本更新紀錄。這些東西比一份漂亮 README 更誠實。

  • 100 個 commits 不再代表很花時間。
  • 測試通過,不代表人真的有細看。
  • 每天在用,比包裝好看更有說服力。
  • 上線歷史,比生成速度更重要。

這也會影響團隊怎麼看內部工具。你如果要別人信任一個 service,就得拿出使用紀錄。不是只丟一個 repo 連結就想過關。現在大家對「成熟」這件事,會更挑。

瓶頸被往前後兩端推了

Willison 提到一個很實在的數字。若工程師一天能從 200 行 code 跳到 2,000 行,整個流程就要重想。設計、測試、review、部署,原本都是配合慢產出的節奏設計的。

他也提到 Anthropic 的設計主管 Jenny Wen。她談過一個很實際的點:以前工程慢,所以做錯的成本高,設計流程也會偏保守。現在 build 變快,設計也可以更敢試。

這件事不只影響寫 code。它也影響產品節奏。你如果 1 天能做完以前 1 週的原型,團隊就會開始期待更多實驗。問題是,review 和測試流程有沒有跟上,常常沒人先想。

對用 Claude Code 這類工具的人來說,重點已經不是「它會不會寫」。它會。重點是你周邊的流程,還是不是在假設 code 很貴、很慢、很難改。

  • 產出變快,review 就不能照舊。
  • 原型變便宜,設計試錯成本也變低。
  • 測試不是選配,會變成主要防線。
  • 部署流程得跟上 agent 的節奏。

Willison 為什麼不怕自己被取代

Willison 的態度很穩。他不覺得自己會因為 AI 會寫 code 就失業。原因很簡單。這些工具會放大既有能力。你本來就懂軟體,速度會更快。你不懂,問題還是在。

他也說得很直接。軟體開發本來就很難。AI 沒把複雜度拿掉。它只是改變了哪一段最花時間。這點我同意。很多人把「會寫 code」想得太簡單了。

他也引用 Matthew Yglesias 的看法。重點不是人人都去 vibe coding。重點是有管理能力的軟體公司,應該把 AI 納入正常流程,做出更好的產品。這比「一個人靠 prompt 做出 SaaS」實際多了。

他還提到一個很務實的選擇。比起一個週末做出的內部 clone,他更想用已經被大企業跑過六個月的 CRM。這很現實,也很工程師。穩定系統的價值,還是沒那麼容易被取代。

這場變化其實是產業習慣在變

這篇文章背後,其實是在講一件更大的事。AI coding 工具不是只改變寫法。它也在改變大家怎麼看「專業」。以前專業感常常來自慢工出細活。現在可能變成「你能不能管好一個很快產生 code 的流程」。

這也會影響團隊分工。以前工程、設計、QA、PM 各自卡自己的節奏。現在 agent 讓某些工作變快,其他工作就得補上。否則你只會得到更多 code,卻沒有更好的產品。

講白了,現在最重要的不是「AI 能不能幫你寫」。而是「你有沒有能力判斷它寫得值不值得上線」。這個差別,會決定團隊是變快,還是變亂。

接下來該怎麼看這件事

我的看法很簡單。vibe coding 和 agentic engineering 之間的界線,接下來只會更模糊。不是因為定義失效,而是因為工具把中間地帶吃掉了。

如果你在帶團隊,我會建議你現在就問一題:什麼證據,才足以讓你信任 AI 產出的 code 進 production。是 tests?是使用紀錄?還是 code review 的深度?這題不先定,之後會很痛。

如果你是開發者,也可以自己做一個小實驗。把一個功能交給 agent,然後刻意記錄你什麼時候開始少看 code。你會很快發現,信任門檻其實比你想像得低。這才是最值得警覺的地方。

延伸閱讀:想看 agentic coding 工作流的具體實作差異?Superpowers vs Everything Claude Code 對比把兩種取向講得很清楚。