”為什麼我開始反對 Vibe Coding?“

👦🏻 作者: Mario Zechner

🧑‍🎨 翻譯/排版: Zeoooo

Mario Zechner 居然寫咗篇文嚟痛批 vibe coding。

佢係邊個？PI 框架嘅作者——同時亦係 libGDX 呢個跨平台遊戲框架嘅創造者。PI 係 OpenClaw 嘅底層 agent 框架，而 OpenClaw 係喺唔夠三個月內，由零升到 25 萬 GitHub stars 嘅項目。

但係 Mario 寫咗呢篇文，話：

呢篇係我哋最近讀到關於 AI coding 好特別嘅一篇文章，亦都幾乎係唯一嘅反對聲音。Mario 唔係喺度吹捧「AI 會取代工程師」，亦都唔係直接否定「AI Coding 根本冇用」，而係話：

文章最後一句話，甚至值得印出嚟貼喺牆上面——

距離嗰一代真正可以幫你由零開始搭起成個項目嘅 coding agents 出現，已經差唔多一年。之前雖然有 Aider 同早期嘅 Cursor 呢啲先驅，但佢哋比較似助手，而唔係真正嘅 agent。新一代工具令人好着迷，我哋好多人都花咗大量業餘時間，用佢哋將嗰啲一直想做但冇時間做嘅項目整晒出嚟。

我覺得呢樣嘢冇乜問題。將業餘時間用嚟整嘢係好享受嘅，大多數時候你根本唔需要理啲 code 嘅質量同可維護性。如果你想學新嘅 tech stack，呢個亦都係一個好機會。

聖誕假期期間，Anthropic 同 OpenAI 都發咗啲福利，令人沉迷喺佢哋部「老虎機」度。對好多人嚟講，呢個係佢哋第一次體驗到 agentic coding 嘅魔力。入坑嘅人越嚟越多。

而家，coding agents 亦都開始被引入去生產環境嘅代碼庫（production codebase）入面。經過咗 12 個月，我哋開始見到呢啲「進步」所帶嚟嘅後果。

以下係我目前嘅睇法。

雖然呢啲都係聽返嚟嘅，但軟件確實感覺變成咗一團脆弱嘅亂麻——得返 98% 嘅 uptime（正常運行時間）正喺度變成常態而唔係例外，就算係大型服務都唔例外。而 UI 出現嗰啲奇葩 bug，求其一個 QA 團隊都應該會發現到。當然，呢個問題早喺 agents 出現之前就已經存在。

但係我哋似乎正喺度加速。

我哋根本無辦法知公司內部發生咩事。但間唔中都會有啲消息流出嚟，俾記者爆俾媒體知。例如呢單據聞係 AI 搞到 AWS 故障嘅事件^[1]，AWS 隨即「澄清」^[2]，之後內部又跟進咗一個 90 日重置計劃^[3]。

微軟 CEO Satya Nadella 一直喺度吹噓緊微軟而家有幾多 code 係由 AI 寫嘅^[4]。雖然我哋無直接證據，但 Windows 感覺上真係行緊下坡。微軟自己似乎都認同呢一點，睇下呢篇 blog post^[5] 就知。

嗰啲聲稱產品 100% code 由 AI 寫嘅公司，持續產出緊你想像得到最垃圾嘅廢物。幾個 GB 嘅 memory leak、UI 亂晒龍、功能殘缺、成日 crash——呢啲絕對唔係佢哋以為嘅質量保證，更加唔係「等 agent 幫你搞掂晒所有嘢」行得通嘅廣告。

透過啲小道消息，你越嚟越多聽到嚟自大大小小 software 公司嘅人講，佢哋用 agentic coding 將自己迫入咗死角。無 code review，架構決策全權交晒俾 agent，最後堆咗一堆無人要嘅功能出嚟。

呢個就係結果。

我哋基本上已經放棄晒所有紀律同自主性，換嚟一種上癮——你最高嘅追求就係喺最短時間內產出最多嘅 code。後果？理得佢啦。

你喺度搭緊一個編排層嚟指揮一支自主 agent 大軍。你裝咗 Beads，完全無意識到佢基本上係一隻無辦法卸載嘅惡意軟件。

你睇下，Anthropic 用 agent cluster 搭咗個 C compiler——雖然有啲殘，但下一代 LLM 肯定搞得掂。天呀，Cursor 用一隊 agent 大軍搭咗個 browser。係，確實係唔多行得通，中間仲要人類時不時幫手撥下個輪。但下一代 LLM 肯定搞得掂，保證！分佈式、分而治之、自主性、黑燈工廠，software 嘅問題喺六個月內會徹底解決。SaaS 已死，我阿嫲啱啱叫佢個 Claude 幫佢搭咗個自己嘅 Shopify！

再講一次，呢啲嘢對於幾乎無人用（包括你自己）嘅 side project 嚟講或者行得通。或者真係有人可以令呢套嘢喺一款唔係垃圾、仲有真實用戶認真用緊嘅 software 產品上面跑得通。如果你做到，咁真係犀利。

但起碼喺我身邊嘅同行圈子入面，我仲未搵到任何證據證明呢套嘢有效。或者我哋全部人都有技術問題。

agents 嘅問題在於佢哋會犯錯。呢樣無問題，人類都會犯錯。或者只係一啲正確性錯誤，容易發現同修復，順手加個 regression test，加分。亦可能係 linter 捉唔到嘅 code smell——一個無用嘅 method、一個唔合理嘅 type、嗰邊一段重複嘅 code。單獨睇，呢啲都無傷大雅。人類都會犯呢種 booboo。

但機械人唔係人類。人類會將同一個錯誤犯幾次，但最終會學識唔再犯——一係因為有人對佢大嗌大叫，一係因為佢真係成長咗。Agent 無呢種學習能力，起碼唔係一開箱就有。佢會反覆犯同樣嘅錯誤，視乎訓練數據，佢甚至可能好有創意咁將各種錯誤混搭出新花樣。

你當然可以試下訓練你個 agent。喺 AGENTS.md^[6] 入面話俾佢知唔好再犯嗰個 booboo，設計最複雜嘅記憶系統，等佢查閱返以前嘅錯誤同 best practice。呢樣嘢對特定類型嘅錯誤係有效嘅。但前提係你真係有留意到 agent 犯咗嗰個錯誤。

機械人同人類之間仲有一個更重要嘅分別：人類係瓶頸。

人類係冇可能喺幾個鐘頭內寫到 2 萬行 code。就算人類成日寫錯嘢（booboo），每日可以塞入 codebase 嘅 booboo 數量都係有限。呢啲 booboo 會以極慢嘅速度複利式咁積累。通常，當 booboo 帶嚟嘅痛苦大到某個程度，怕麻煩嘅人類就會花時間去執返好佢哋。一係就嗰個人俾人炒咗，由其他人嚟執。所以痛苦係會消退嘅。

但當你有一隊編排好嘅 agent 大軍，樽頸位就消失咗，亦都冇咗人類嗰種痛覺。嗰啲微細、無傷大雅嘅 booboo 突然間以一種維持唔到落去嘅速度複利增長。你將自己抽離咗個循環，所以你根本唔知嗰啲無辜嘅 booboo 已經合體成一隻 codebase 怪獸。你只會喺太遲嘅時候先感受到痛苦。

某一日你回頭睇返，想加個新功能。但個架構——呢個時候基本上就係一堆 booboo——根本唔容許你隊 agent 大軍用正常運作嘅方式去改。又或者你啲 user 喺度對住你大嗌，因為最新版本有啲嘢崩潰咗，仲要刪埋 user 啲數據。

恭喜晒，你搞到自己（同埋你間公司）一身蟻！

你對發生咗咩事完全冇頭緒，因為你將所有自主權都交晒俾你啲 agents。你由得佢哋周圍走，而佢哋係複雜度嘅販賣者。佢哋喺 training data 入面見過太多垃圾架構決策，亦都經歷過 RL 訓練。你叫佢哋幫你設計 app 嘅架構。結果你估下點？

無窮無盡嘅複雜度，係各種垃圾「行業最佳實踐」貨物崇拜（cargo culting）嘅大雜燴——而你喺件事去到冇得救之前都冇管住佢。但仲未完。

你啲 agents 彼此睇唔到對方點樣 run，睇唔到你成個 codebase，亦都睇唔到喺佢哋改 code 之前，你或者其他 agents 做過嘅所有決定。所以，agent 嘅決策永遠都係局部嘅，呢樣正正就係導致上面提到嗰啲 booboo 嘅根本原因。大量嘅 code 重複，為咗抽象而抽象。

呢一切加埋就變成一團救唔返嘅複雜度亂麻。同你喺人手寫嘅企業級 codebase 入面見到嗰種爛攤子一模一樣。嗰種爛攤子之所以形成，係因為痛苦分散咗喺好多人身上——每個人嘅痛苦仲未到「我要執返好佢」嘅門檻，個人可能根本冇能力去執，而組織對痛苦嘅耐受力極高。但人手寫嘅企業級 codebase 要幾年時間先會爛到嗰種程度，組織會隨住複雜度以一種病態嘅協同緩慢演化，並學識點樣應對佢。

而家有咗 agents 同一個兩人團隊，你喺幾個禮拜之內就可以去到嗰種複雜度。

而家你希望你啲 agents 可以搞掂呢團亂麻，重構佢，等佢變返乾淨。但你啲 agents 都已經無能為力。因為 codebase 同複雜度太大，佢哋只可以見到呢團亂麻嘅局部視圖。

我講嘅唔單止係 context window 大細或者長 context 注意力機制喺面對百萬行 code 嘅巨獸時失效——呢啲係顯而易見嘅技術局限。呢件事其實仲陰濕。

喺你個 agent 嘗試幫你執返好啲亂麻之前，佢需要搵到所有需要改嘅 code，同埋所有可以 reuse 嘅現成 code。我哋稱之為 agentic search。agent 點樣做到呢點，取決於佢有咩工具。你可以俾個 Bash 工具佢，等佢用 ripgrep 摷勻成個 codebase；你可以俾個可查詢嘅 codebase 索引、一個 LSP server、一個 vector database 佢。最終分別唔大。codebase 越大，召回率（recall）就越低。低召回率代表你個 agent 實際上搵唔到佢做好份工所需嘅全部 code。

我哋點樣可以避免呢一切？

Coding agents 係塞壬（Siren），用佢哋寫 code 嘅速度同埋時好時壞嘅智能嚟誘惑你，通常可以極速高質量咁完成一個簡單任務。當你開始諗「嘩死喇，呢件嘢真係正，電腦，幫我搞掂佢！」嘅時候，件事就開始崩壞喇。

將啲任務交畀 agents 做當然冇問題。好嘅 agent 任務通常有幾個共通點：

如果以上任何一點中咗，你就搵到 agent 嘅完美任務喇——前提係你呢個人類要係最後把關嗰個。

Karpathy 嗰套^[7] auto-research^[8] 用嚟加速你個 app 嘅啟動時間^[9]？幾好呀！只要你明白佢嘔出嚟嘅 code 根本未去到 production-ready 嘅程度。Auto-research 之所以有效，係因為你畀咗個 evaluation function 佢，等 agent 可以用某啲指標（例如啟動時間或者 loss）嚟衡量自己做成點。但係嗰個評估函數只係捕捉到一個好窄嘅指標。至於評估函數捕捉唔到嘅嘢——例如 code quality、複雜度，或者當你個評估函數本身有問題嗰陣嘅正確性——agent 會完全當睇唔到，直接 ignore 咗佢。

重點係：等 agent 做啲無聊嘢，做啲唔會令你學到新嘢嘅嘢，或者幫你試一啲你平時根本冇時間試嘅方案。然後你再去評估佢畀出嚟嘅結果，將真正合理同埋正確嘅諗法攞出嚟，再親自完成最後嘅實作。係，當然，你最後嗰步都可以用 agent 幫手。

因為「焗住要親手寫出嚟」或者「一步步睇住佢起出嚟」呢個簡單嘅行為，會製造一啲摩擦力，令你更加理解你想起啲乜，同埋成個系統嘅「手感」。呢啲就係你嘅經驗同品味所在，而呢樣嘢正正係目前 SOTA 模型仲未取代到嘅。

最終嘅結果，係嗰啲可以持續維護嘅系統同 codebase——起碼同 agents 出現之前我哋嗰啲舊系統一樣咁易維護。係，嗰啲都唔係完美。你嘅用戶會多謝你，因為你個產品而家係令人用得舒服，而唔係一坨求其整出嚟嘅垃圾。你會做少咗功能，但做親都係啱嘅功能。學識講「唔好」，本身就係一個功能。

你可以安穩咁瞓覺，因為你清清楚楚知道發生緊咩事，你掌握住主動權。你嘅理解能力解決咗 agentic search 嘅 recall 問題，帶嚟更好嘅 robot 輸出，需要改嘅地方都少啲。如果出咗事，你有能力介入去 fix 佢。如果你最初個 design 唔夠理想，你都理解到點解唔理想，同埋點樣將佢 refactor 做更好嘅嘢。有冇 agent 輔助，其實都冇所謂。

呢一切都需要紀律同埋自主性。

呢一切都需要人類。

👦🏻 作者: Mario Zechner

🧑‍🎨 翻譯/排版: Zeoooo

Mario Zechner 居然寫了一篇來痛批 vibe coding。

他是誰？PI 框架的作者——同時也是 libGDX 這個跨平台遊戲框架的創造者。PI 是 OpenClaw 的底層 agent 框架，而 OpenClaw 是不到三個月內從零漲到 25 萬 GitHub stars 的項目。

然而 Mario 寫了這篇文章，說：

這是我們最近讀到的關於 AI coding 很特別的一篇文章，也幾乎是唯一的反對聲音。Mario 沒有鼓吹「AI 要取代程序員」，也不是在直接否定「AI Coding 根本沒用」，而是在說：

文章最後一句話，甚至值得打印出來貼在牆上——

距離那一代真正能幫你從零搭建完整項目的 coding agents 出現，已經差不多一年了。之前也有 Aider 和早期 Cursor 這樣的先驅，但它們更像助手，而不是真正的 agent。新一代工具令人着迷，我們很多人花了大量業餘時間，用它們把那些一直想做卻沒時間做的項目都做了出來。

我覺得這沒什麼問題。把業餘時間用來做東西非常享受，大多數時候你根本不需要在意代碼質量和可維護性。如果你想學新技術棧，這也是個好機會。

聖誕假期期間，Anthropic 和 OpenAI 都發了些福利，讓人們沉迷於他們的老虎機。對很多人來說，這是他們第一次體驗到 agentic coding 的魔力。入坑的人越來越多。

現在，coding agents 也開始被引入到生產代碼庫中。經過 12 個月，我們開始看到這些「進步」所帶來的後果。

以下是我目前的看法。

雖然這些都是道聽途說，但軟件確實感覺變成了一團脆弱的亂麻——僅僅 98% 的 uptime 正在成為常態而非例外，就連大型服務也不例外。而用戶界面出現的那些奇葩 bug，任何一個 QA 團隊都應該能發現。當然，這個問題比 agents 的出現早得多。

但我們似乎正在加速。

我們無法瞭解公司內部的情況。但偶爾會有一些消息溜出來被記者捅到媒體上。比如這起據說是 AI 導致的 AWS 故障^[1]，AWS 隨即「闢謠」^[2]，然後又內部跟進了一個 90 天重置計劃^[3]。

微軟 CEO Satya Nadella 一直在鼓吹微軟有多少代碼現在是由 AI 編寫的^[4]。雖然我們沒有直接證據，但 Windows 感覺正在走下坡路。微軟自己似乎也認同這一點，看看這篇博文^[5]就知道了。

那些聲稱產品 100% 代碼由 AI 編寫的公司，持續產出你能想象到的最差勁的垃圾。幾個 GB 的內存泄漏、UI 錯亂、功能殘缺、頻繁崩潰——這可不是他們以為的質量認證，也絕對不是「讓 agent 替你幹所有活兒」可行的廣告。

通過小道消息，你越來越多地聽到來自大大小小軟件公司的人說，他們用 agentic coding 把自己逼進了死角。沒有代碼 review，架構決策全權委託給 agent，堆出了一堆沒人要的功能。

這就是結果。

我們基本上已經放棄了所有的紀律和自主性，換來了一種上癮——你最高的追求就是在最短時間內產出最多的代碼。後果？管它呢。

你在搭一個編排層來指揮一支自主 agent 大軍。你裝了 Beads，完全沒意識到它基本上是無法卸載的惡意軟件。

你看，Anthropic 用 agent 集羣搭了個 C 編譯器——有點殘，但下一代 LLM 肯定能修好的。天啊，Cursor 用一個 agent 大隊搭了個瀏覽器。是的，確實沒怎麼跑通，中間還需要人類時不時撥一下輪子。但下一代 LLM 肯定能修好的，保證！分佈式、分而治之、自主性、黑暗工廠，軟件問題再六個月內徹底解決。SaaS 已死，我奶奶剛讓她的 Claw 給她搭了個自己的 Shopify！

再說一遍，這對於幾乎沒人用（包括你自己）的副業項目來說也許可行。也許有人真的能讓這套東西在一款不是一坨熱氣騰騰的垃圾、還有真實用戶在認真使用的軟件產品上跑通。如果你做到了，那真的厲害。

但至少在我身邊的同行圈子裏，我還沒找到任何證據表明這套東西有效。也許我們都有技術問題。

agents 的問題在於它們會犯錯。這沒關係，人類也會犯錯。也許只是些正確性錯誤，容易發現和修復，順手加一個迴歸測試，加分項。也可能是 linter 捕捉不到的代碼壞味道——一個沒用的方法、一個說不通的類型、那邊一段重複代碼。單獨來看，這些都無傷大雅。人類也會犯這種 booboo。

但機器人不是人類。人類會把同一個錯誤犯幾次，最終會學會不再犯——要麼是因為有人對他大喊大叫，要麼是因為他在真正成長。Agent 沒有這種學習能力，至少不是開箱即用的。它會反覆犯同樣的錯誤，取決於訓練數據，它甚至可能創造性地把各種錯誤混搭出新花樣。

你當然可以試着訓練你的 agent。在 AGENTS.md^[6] 裏告訴它別再犯那個 booboo，設計最複雜的記憶系統，讓它查閲以往的錯誤和最佳實踐。這對特定類型的錯誤可以有效。但前提是你真的有觀察到 agent 犯了那個錯誤。

機器人和人類之間還有一個更重要的區別：人類是瓶頸。

人類不可能在幾小時內堆出 2 萬行代碼。就算人類以很高的頻率製造 booboo，每天能往 codebase 裏引入的 booboo 數量也是有限的。booboo 會以極慢的速度複利積累。通常，當 booboo 的痛苦大到一定程度，厭惡痛苦的人類會花時間去清理它們。或者這個人被炒了，別人來清理。所以痛苦會消退。

有了一支編排好的 agent 大軍，瓶頸消失了，也沒有人類的痛感。那些微小的、無害的 booboo 突然以不可持續的速度複利。你把自己從循環裏移出去了，所以你根本不知道那些無辜的 booboo 已經合體成了一隻 codebase 怪獸。你只會在為時已晚的時候才感受到痛苦。

某天你回過頭，想加一個新功能。但架構——此時基本上就是一堆 booboo——不允許你的 agent 大軍以正常運作的方式完成修改。或者你的用戶在衝你大喊大叫，因為最新版本的某個東西崩了，還刪掉了一些用戶數據。

恭喜，你把自己（和你的公司）給坑了！

你對發生了什麼毫無頭緒，因為你把所有的自主權都委託給了你的 agents。你讓它們自由馳騁，而它們是複雜度的販子。它們在訓練數據中見過太多糟糕的架構決策，也經歷了 RL 訓練。你讓它們來架構你的應用。結果你猜怎樣？

無窮無盡的複雜度，是各種糟糕的「行業最佳實踐」貨物崇拜的大雜燴——而你在事情無法挽回之前沒有管住它。但還不止這些。

你的 agents 彼此看不到對方的運行，看不到你完整的 codebase，看不到在它們做出改動之前你或其他 agents 做過的所有決定。因此，agent 的決策永遠是局部的，這正是導致上述 booboo 的根本原因。大量的代碼重複，為抽象而抽象。

這一切複合成一團無法挽救的複雜度亂麻。和你在人工編寫的企業級 codebase 裏見到的那種爛攤子一模一樣。那種爛攤子之所以形成，是因為痛苦分散在大量的人身上——個體的痛苦還沒到「我需要修這個」的閾值，個體可能根本沒有能力去修，而組織的疼痛耐受力極高。但人工編寫的企業級 codebase 需要數年才能爛到那種程度，組織會隨着複雜度以一種病態的協同緩慢演化，並學會如何應對它。

而有了 agents 和一個兩人團隊，你可以在幾周內就到達那種複雜度。

現在你希望你的 agents 能修復這團亂麻，重構它，讓它重煥清爽。但你的 agents 也已經無力應對了。因為 codebase 和複雜度太大，它們只能看到這團亂麻的局部視圖。

我說的不只是上下文窗口大小或長上下文注意力機制在面對百萬行代碼龐然大物時的失效——這些是顯而易見的技術侷限。這件事更狡猾。

在你的 agent 嘗試幫你修復亂麻之前，它需要找到所有需要改動的代碼，以及所有可以複用的現有代碼。我們稱之為 agentic search。agent 怎麼做到這一點，取決於它擁有什麼工具。你可以給它一個 Bash 工具，讓它用 ripgrep 翻遍整個 codebase；你可以給它一個可查詢的 codebase 索引、一個 LSP server、一個 vector database。最終差別不大。codebase 越大，召回率越低。低召回率意味着你的 agent 實際上找不到它做好工作所需的全部代碼。

我們怎麼避免這一切？

Coding agents 是塞壬，用它們的代碼生成速度和參差不齊的智能誘惑你，經常以極快的速度高質量地完成一個簡單任務。當你開始想「哦天哪，這東西真棒，電腦，幫我幹活！」的時候，事情就開始崩壞了。

把任務委託給 agents 當然沒問題。好的 agent 任務有一些共同特徵：

如果以上任何一點適用，你就找到了 agent 的完美任務——前提是你這個人類是最終的質量關口。

Karpathy 的^[7] auto-research^[8] 用於加速你的應用啓動時間^[9]？很好！只要你明白它吐出來的代碼根本沒有生產就緒。Auto-research 之所以有效，是因為你給了它一個評估函數，讓 agent 可以用某個指標（比如啓動時間或 loss）來衡量自己的工作。但那個評估函數只捕捉了一個非常狹窄的指標。對於評估函數沒有捕捉到的指標——比如代碼質量、複雜度，或者在你的評估函數本身就有問題時的正確性——agent 會毫不在意地忽略掉。

重點是：讓 agent 做無聊的事，那些不會讓你學到新東西的事，或者嘗試你否則沒時間嘗試的各種方案。然後你評估它給出的結果，把真正合理且正確的想法取出來，並完成最終實現。是的，當然，你也可以用 agent 來做這最後一步。

因為不得不親手寫出東西、或者一步步看着它被構建出來這個簡單的行為，會引入摩擦，讓你更好地理解你想構建什麼，以及這個系統的「手感」。這就是你的經驗和品味所在，而這恰恰是當前 SOTA 模型尚無法取代的。

最終的結果，是那些持續可維護的系統和 codebase——至少和 agents 出現之前我們的老系統一樣可維護。是的，那些也不完美。你的用戶會感謝你，因為你的產品現在令人愉悦而不是一坨糊弄。你會做更少的功能，但都是對的功能。學會說不，本身就是一個功能。

你可以安然入睡，因為你清楚地知道發生了什麼，你掌握着主動權。你的理解能力解決了 agentic search 的召回問題，帶來更好的機器人輸出，需要更少的修改。如果事情出了岔子，你有能力介入並修復它。如果你最初的設計不夠理想，你能理解為什麼它不夠理想，以及如何將它重構成更好的東西。有沒有 agent 輔助，都無所謂。

這一切都需要紀律和自主性。

這一切都需要人類。