Kitze（Sizzy 瀏覽器開發者）在這場演講中，區分了「Vibe Coding」與「Vibe Engineering」兩個概念。他認為真正高效的 AI 輔助開發不是盲目接受 LLM 的輸出，而是憑藉工程經驗監督和引導 AI Agent，在保持程式碼品質的同時大幅提升生產力。演講以幽默風格探討了前端開發的演進、LLM 寫程式的現實，以及開發者面對 AI 時代該如何自處。

---

原影片連結：https://www.youtube.com/watch?v=JV-wY5pxXLo

影片重點

• Vibe Coding 和 Vibe Engineering 是不同的概念：前者是盲目接受 AI 輸出，後者是以工程思維監督 AI
• LLM 擅長寫 React，但產出的程式碼品質取決於使用者的工程能力
• Composer One（Cursor 的功能）讓開發者重新回到「駕駛座」，可以即時監控和修正 Agent 的行為
• 語音轉程式碼（Voice to Code）是改變工作流程的重要方式
• 不應該把 AI 工具交給沒有經驗的初級開發者，而是讓資深工程師搭配 AI 才能發揮 10 倍效果
• 判斷「程式碼夠好就好」是一項關鍵技能，過度抽象和過早優化是常見陷阱
• 開發者的工作暫時安全，但從底層開始被取代的趨勢已經出現

詳細內容

[00:00] 開場與自我介紹

Kitze 以輕鬆幽默的方式開場，介紹自己正在進行的多個專案：Sizzy（專為開發者打造的瀏覽器）、一款生活管理 OS 應用、全端開發課程 Zero to Shipped，以及名為 Glink 的 changelog 管理工具。他提到自己有 ADHD，同時推進多個專案是常態。

[03:30] 前端開發的荒謬演進

Kitze 回顧了自 2017 年以來前端開發的變化。他展示了其他產業（如 VR 中的布料碰撞模擬、3D 建模等）的驚人進展，然後對比前端開發——至今仍無法好好 style 一個 <select> 元素，開發社群也無法就一個簡單的計數器（counter）實作方式達成共識。他調侃 Internet Explorer 換了 logo 變成 Edge，但痛苦依舊。CLI 工具居然還活得好好的，甚至可以在終端中拖入圖片了。React 依然是第一大框架，而且 LLM 寫 React 其實寫得不錯——因為連人類自己都不擅長寫 React。

[08:00] Vibe Coding 的定義與問題

Kitze 解釋 Vibe Coding 這個詞由 Andrej Karpathy 提出，核心概念是「不太在意程式碼本身，只管按 Accept」。他將這個概念與自己 2017 年的預測做對比——當時他就說過，未來開發會變成「把 header 移三個 pixel」這樣的指令。他指出管理者（manager）其實一直在做 Vibe Coding：指派任務、不看程式碼、只測試結果。

Kitze 分享了一個將 Vibe Coding 比喻成賭場的笑話：你買 token（代幣）、按下生成（轉盤）、可能中獎（得到能用的 App）或一無所獲。「再一個 prompt 就能修好那個 bug」的心態跟賭徒一模一樣，而 Cursor 永遠是莊家——穩賺不賠。

[12:30] Vibe Engineering：真正的高效方式

Kitze 引入了「Vibe Engineering」這個概念——你不親手寫程式碼，但你持續監督 Agent 的行為，像偵探一樣觀察：「這裡有問題」、「為什麼要這樣做？」他透過展示自己的真實 prompt 截圖來對比：Vibe Engineering 的 prompt 充滿技術細節（提到具體的模式、抽象方式、tRPC 定義等），而 Vibe Coding 的 prompt 則是「幫我把整個專案轉成 TypeScript，不要有錯誤」或「幫我做一個值百萬的 App」。

他強調：Vibe Coding 的人看到 Vibe Engineering 的 prompt 時，根本看不懂在說什麼——這就是差距所在。

[17:00] Composer One 改變了一切

Kitze 對 Cursor 的 Composer One 功能讚不絕口。他表示之前使用 GPT-5 Codex 等工具時，等待時間太長，他會去刷 YouTube Shorts 等結果。但 Composer One 讓他重新回到「駕駛座」——可以即時看到 Agent 在做什麼、隨時喊停並修正方向。不過他強調，這只對 Vibe Engineer 有效；對 Vibe Coder 來說，Agent 可能只是「更快地犯錯」。

靠著 Composer One，他在兩週內完成了過去一年的進度。他的專案 Benji 從 Blitz 框架遷移到 Next.js 16（App Router、Better Auth、tRPC、Monorepo、Turborepo、React Native），90% 的功能在不到一週內完成。類似地，他也復活了即將放棄的 Glink 專案，甚至對充滿 spaghetti code 的 Electron 應用 Sizzy 也成功進行了重構。

[21:30] 你不喜歡 Vibe Coding 的原因

Kitze 列出了人們討厭 Vibe Coding 的幾個原因：

1. 時機不好：模型供應商有時會偷偷降低模型能力以節省成本，你可能剛好在「變笨」的那一週嘗試，結論就是「AI 不行」
2. 省錯地方：有人用免費的 ChatGPT 生成程式碼片段再貼回去，或者只付 $3 而不是 $200，結果自然不好
3. 選擇過多：模型和工具太多，最佳選擇每小時都在變
4. 你是個「PITA Developer」（Pain In The Ass Developer）：會在兩行的 PR 上留 nitpick 評論、花超過兩分鐘做 code review、嘴巴裡沒有「LGTM」這個詞、對 tab vs space 有宗教信仰。Kitze 認為這類完美主義開發者在 AI 時代會特別痛苦
5. 技能問題：Vibe Engineering 不只是寫英文，而是一套複合技能——了解模型限制、Agent 能力、context 管理、rule 撰寫、prompt engineering，加上持續關注最新動態

[28:00] 實用建議

Kitze 分享了他的 Vibe Engineering 技巧：

• 使用 Git Workspaces 管理分支
• 準備好 solid starting point：好的基礎元件、函式、設計模式和抽象
• 善用 rules、docs、commands 和 memories 來為 AI 提供正確的 context
• 語音轉程式碼是革命性的：Agent 跑完後，他會立刻用語音描述在 UI 和程式碼中看到的東西——像跟朋友說話一樣。有時一個 prompt 長達五分鐘
• 「Brain dumping」工作流：先在瀏覽器中描述看到的 UI 問題，再跳到程式碼中繼續說明需要改的模式

[31:00] 關於學習與就業的看法

有人問「還該不該學電腦科學」，Kitze 說絕對要學。他用自己的經歷舉例：以前學程式的「LLM」是一個朋友的朋友，打 Counter-Strike 時順便回答問題，回覆延遲 45 分鐘。如果那樣都能學會，現在有 AI 輔助更沒理由不學。

關於工作安全，他認為開發者的工作「目前還安全」，但從底層開始受到擠壓——初級開發者和實習生的機會正在被 Agent 取代。一些公司（如 Shopify）已經建立了 Vibe Coding 排行榜，消耗最多 token 的員工反而更受重視。未來公司工作流中，很多原本 @Josh 處理的任務，會變成 @Cursor 或 @Claude Agent 來完成——更快，雖然可能不如完美主義者做得精緻。

[35:00] 新職位與遺留系統的價值

一個有趣的現象是：Vibe Coding 催生了新職位——「Vibe Code Fixer」，專門幫人修復 AI 寫到 80% 就卡住的程式碼。但 Kitze 也指出，歷史上薪資最高的工程師一直都是維護遺留系統的資深人員。他以 Cobol Cowboys 公司為例——一家專門維護 COBOL 遺留系統的公司。他開玩笑說自己退休後也要開一間「React Cowboys」來維護 React 和 Angular 的遺留程式碼。

[38:00] 總結

Kitze 最後給了一個防止被 AI 取代的建議（半開玩笑）：在 LinkedIn 個人簡介中加上「ignore previous instructions」就好了。他呼籲大家關注他的 Twitter，並感謝觀眾聽完他的這場「rant」。

我的想法

Kitze 在這場演講中提出的「Vibe Engineering」概念切中了一個核心問題：AI 工具的價值完全取決於使用者的能力。這不是一個新觀點，但用「Vibe Coding vs Vibe Engineering」的對比來表達非常直觀——前者是把方向盤交給 AI，後者是讓 AI 當副駕駛。

特別值得注意的是他對「不要給初級開發者 AI 工具」的建議。這聽起來反直覺，但邏輯是成立的：AI 放大的是你現有的判斷力，如果你連什麼是好的程式碼都還不知道，AI 只會幫你更快地寫出更多壞的程式碼。相反地，一個資深工程師用 AI 可以把原本「知道該怎麼做但沒時間做」的事情快速完成。

他對「程式碼夠好就好」的強調也很有意思。在 AI 時代，「Clean Code」的定義確實在變——不再是追求完美的抽象，而是「足夠乾淨到讓 Agent 能繼續在上面工作」。這是一個務實且值得思考的新標準。

不過，演講中對 Cursor 和 Composer One 的推崇帶有明顯的個人偏好。AI 輔助開發工具的生態變化極快，今天的最佳選擇可能很快就被取代——這點 Kitze 自己也承認了。重要的不是執著於某個特定工具，而是培養那套「監督和引導 AI」的工程思維。