清理 AI Rockstar 開發者的爛攤子

AI Rockstar 的崛起與「Slopocalypse」

AI 輔助開發正在催生新一代的「rockstar」開發者，他們能以空前的速度交付功能，但往往是以犧牲可維護性和架構完整性為代價。這種現象正導致一場「slopocalypse」（垃圾末日）——在這種未來，成千上萬透過「vibe-coding」（依賴 LLM 輸出而非深入理解）編寫的應用程式，將需要大規模且昂貴的清理工作。

雖然 AI 可以加速通往可行原型（prototype）的初始路徑，但它往往在開發者尚未解決設計階段的問題之前，就催促他們進入執行階段（runtime）。正如一位貢獻者所指出的：「在執行階段修復代碼比在編譯階段更貴，而編譯階段又比設計階段更貴。不幸的是，AI 會盡可能快地把人推向執行階段。」

Vibe-Coding 的技術債

在缺乏嚴格人工監督的情況下，由 LLM 生成的代碼經常表現出系統性不穩定和設計不良的模式。這種「AI slop」的現實案例包括：

• 資源效率低下： 由於依賴項臃腫且結構未經優化，導致應用程式需要過多的記憶體（例如，編譯時需要 10GB）。
• 模糊不清的數據流： 邏輯極其難以追蹤，簡直像是「掩蓋謀殺案」，使得逆向工程設計意圖變得幾乎不可能。
• 維護僵局： 一種依賴關係，開發者變得依賴於寫出那份爛代碼的同一個 AI 來維護它，因為原始邏輯對人類來說太過複雜或特立獨行，難以解析。
• 營運雜訊： Git repositories 充斥著開發日誌和數千個 lint errors，顯示出缺乏基本的工程紀律。

「Rockstar」的謬誤：速度 vs. 生產力

感知速度（功能交付的速度）與實際生產力（代碼的長期價值與穩定性）之間存在關鍵區別。

對團隊動態的影響

忽視架構標準的高速開發者往往會為其隊友帶來負面的乘數效應。一位前「rockstar」開發者對此反思道：

「我意識到這並不是因為我比一般人高出 10 倍的生產力；而是因為我的工作方式讓身邊的普通人生產力降低到了 1/10。」

履歷驅動開發

有人認為，「rockstar」形象往往是「履歷驅動開發」（resume-driven development）的面具，工程師為了提升自己的資歷，而非有效解決業務問題，而實作了艱澀的框架、半成品的抽象化或複雜的微服務。這導致當原始作者離開公司時發生「維護失敗」，留下一個需要耗費數年時間和數百個 pull requests 才能淨化的代碼庫。

緩解 AI 生成技術債的策略

為了防止不可維護的 AI 代碼堆積，資深工程師建議了幾種架構與流程導向的防護措施：

模組化架構與嚴格的介面

採用模組化、類似微服務的模型，並定義清晰的介面，可以防止 AI 生成的「義大利麵條代碼」（spaghetti code）變成一個統一、單體式的混亂不穩定球體。透過將爛代碼但功能正常的代碼進行「防火牆化」（firewalling），團隊可以隔離風險，並在不重寫整個系統的情況下更換有問題的模組。

人機協作審查（Human-in-the-Loop Review）

與其將 AI 當作開發者的替代品，不如將其視為一個需要嚴格審查的工具。有些開發者使用專用的 AI agents 來維持合理的數據模型，這些 agents 會在預先規劃以及代碼審查期間再次進行審查，最後再由人類進行最終簽核。

重視工藝精神而非數量

人們越來越擔心軟體正被視為「拋棄式」的，就像快時尚一樣。然而，支持長期業務流程的軟體是不能拋棄的。產業必須從重視「噴出」的代碼行數，轉向重視可維護、值得信賴且優雅的結構。

清理工作的經濟機會

矛盾的是，AI 生成技術債的激增正在為專門的清理專家創造一個利潤豐厚的市場。因為 vibe-coded 工具往往是「如果你不知道自己在做什麼，就無法修復」，由於資深工程師發現了在「去垃圾化」（unsloppifying）代碼庫中的高價值機會——本質上是收取高額費用來解決 AI rockstars 所造成的混亂。