AI 編程明星開發者：生產力狂飆，債務滿天飛

> Nerf Watch

我認為 AI 工具正在大量製造「明星開發者」，但這些開發者留下的技術債務，會讓整個產業付出比想像中更高的代價。

當 ChatGPT、Cursor、GitHub Copilot 這些工具讓個人產出暴增，我們確實看到了「10x 工程師」的崛起。但就像當年那些用最新框架重寫整個系統，然後跳槽的技術大神一樣，AI 加持的明星開發者也在留下同樣的爛攤子—只是規模更大、清理更困難。

現象：AI 讓每個人都能當明星開發者

過去幾年，我觀察到一個明顯的現象：團隊裡開始出現「AI 原生」的開發者，他們的產出速度讓其他人望塵莫及。

這些開發者有幾個共同特徵：用 Cursor 或 GitHub Copilot 快速生成大量程式碼，一天能產出過去一週的代碼量；引入各種新潮的架構和工具，因為 AI 告訴他們這是「最佳實務」；對於程式碼審查（code review）要求很高，但自己的程式碼卻很難被其他人理解。

最關鍵的是，這些開發者離職後，留下的系統往往讓團隊陷入困境。就像原始文章中描述的情況：「半的程式碼是用你不懂的語言寫的，另一半用的是你沒聽過的套件」。現在這個問題被 AI 放大了—因為 AI 可以在幾分鐘內生成數萬行程式碼，複雜度呈指數級增長。

根據 Stack Overflow 2024 年的調查，超過 70% 的開發者已經在使用某種 AI 編程工具，但同時技術債務相關的問題討論也增長了 40%（來源：Stack Overflow Developer Survey 2024）。這不是巧合。

分析：為什麼 AI 會製造更多技術債務

這個現象背後有三個深層原因。

技術面：AI 不理解 context

AI 工具最大的問題是缺乏 context。它不知道你昨天寫了什麼，不知道整個系統的架構演進，也不知道團隊的技術債務狀況。當開發者問 AI「怎麼實作這個功能」，AI 會給出它認為最「完美」的方案—通常是過度工程化的。

我最近看到一個案例：一個原本只需要 useState 就能解決的簡單表單，被 AI 建議用上了 Redux Toolkit + RTK Query + React Hook Form + Zod 驗證。技術上沒錯，但對於一個只有 5 個欄位的表單來說，完全是殺雞用牛刀。

商業面：快就是正義的迷思

現在的商業環境鼓勵快速交付，AI 工具恰好符合這個需求。當 CEO 看到工程師用 AI 在一週內完成過去一個月的工作量，他們會覺得找到了提升效率的銀彈。

但這讓我想到 2000 年代的外包熱潮。當時大家也覺得找到了降低成本的方法，結果後來花在溝通和重構上的成本，往往比原本的開發成本還高。AI 編程也有類似的問題—快速產出的程式碼，後續維護成本可能是數倍。

人才面：技能被 AI 掏空

更危險的是，過度依賴 AI 的開發者，本身的基礎能力可能正在退化。他們會用 AI 生成複雜的演算法，但不一定理解這些演算法的效能特性；會讓 AI 選擇技術方案，但不知道為什麼要這樣選。

當系統出現問題時，這些開發者往往只能再問 AI「這個錯誤怎麼修」，而不是從根本上理解問題。這形成了一個惡性循環：系統越來越複雜，開發者越來越依賴 AI，技術債務越來越多。

Meta 判讀：Nerf Watch — AI 工具的負面效應開始顯現

我把這個趨勢歸類為 Nerf Watch—AI 編程工具的負面效應正在顯現，整個產業可能需要重新校正對 AI 的期待。

這不是說 AI 工具本身有問題，而是我們使用它們的方式有問題。當前的 AI 編程工具更像是「程式碼生成器」而不是「程式設計助手」。它們擅長快速產出，但不擅長思考架構、權衡技術債務、或是考慮團隊協作。

從投資者角度來看，那些主打「AI 讓開發者效率提升 10 倍」的公司，可能需要重新評估他們的價值主張。真正的價值不是讓開發者寫更多程式碼，而是寫更好的程式碼。

未來 AI 編程工具的發展方向，應該是朝向更好的 context understanding 和團隊協作支援。那些能解決技術債務問題，而不是製造更多技術債務的工具，才會是真正的贏家。

我的建議：如何避免成為 AI 明星開發者

如果你正在使用 AI 編程工具，這裡有幾個建議：

不要讓 AI 替你做架構決策。AI 可以幫你寫 implementation，但系統設計還是要靠人腦。花時間理解你的 codebase，理解團隊的技術現狀，再決定要引入什麼新技術。

把 AI 當作 junior developer。你會讓新人直接設計核心架構嗎？應該不會。對 AI 也是一樣—它可以幫你寫一些重複性的程式碼，但關鍵決策還是要自己做。

重視 code review 和文件。AI 生成的程式碼往往缺乏註解和文件，這會讓未來的維護變得困難。花時間加上適當的註解，讓團隊其他人能理解你的程式碼。

定期重構和清理。不要因為 AI 讓你寫程式碼很快，就忽略了重構的重要性。好的程式碼不是寫得快，而是改得容易。

最重要的是，記住你不是在為 AI 寫程式碼，你是在為團隊、為未來的自己寫程式碼。AI 工具很強大，但如何使用它們，還是要靠人的判斷。