AI 寫碼不是越多越好：真正該看的是少製造多少負債

AI 寫碼工具正在把「產生程式碼」這件事變得非常便宜。

以前工程師可能花半天拆需求、找檔案、補邏輯、跑測試。現在一個 coding agent 可以在幾分鐘內產出一整包修改：多個檔案、新的 helper、測試案例、文件註解，甚至連 commit message 都一起準備好。

這看起來像效率暴增。

但工程品質從來不只看「有沒有寫出來」。真正麻煩的是：那些被快速產出的 code，未來是不是有人看得懂、改得動、測得出問題、願意接手維護？

程式碼不是資產，常常是負債

軟體團隊很容易把「新增行數」誤認為進度。AI 讓這個錯覺變得更強，因為它產出的速度太快了。

但在成熟專案裡，多一行 code 代表多一個未來要理解的地方。多一層抽象代表多一個要追的路徑。多一份複製貼上代表同一個 bug 可能分散到更多地方。

所以 AI 寫碼真正該看的，不是它一天能寫多少，而是它有沒有減少未來維護成本。

研究已經看到維護訊號

GitClear 針對大量 code change 的研究指出，AI coding 普及後，code churn、重複碼與 copy/paste 類型的變化值得注意。2025 研究分析 2020 到 2024 年共 2.11 億 changed lines，觀察到 duplicate code blocks 與 short-term churn 增加，refactoring / moved lines 下降。

這不代表 AI 寫出來的 code 一定比較差。

比較準確的說法是：當工具讓「新增」變得太容易，團隊就更需要刻意保護「刪減、重用、重構、驗證」這些不那麼炫、但更影響長期品質的動作。

測試全過只是起點

很多 AI coding flow 會讓人很安心：功能寫了、測試也補了、全部綠燈。

但測試全過不等於風險結束。

你還要知道：

• 測試覆蓋的是主要流程，還是只覆蓋最容易通過的路徑？
• 邊界情境有沒有被想過？
• 新增的抽象層是不是必要？
• 這次改動有沒有沿用既有設計？
• 如果下個月要改同一個功能，維護者會更輕鬆，還是更痛苦？

Addy Osmani 在談 AI 與 code review 時也提醒，AI 沒有消滅 review，而是讓「證明這段 code 真的能用」變得更重要。沒有驗證證據的 PR，看起來像是更快交付，實際上可能只是把工作往下游推。

真正的 AI 寫碼能力，是少做錯的事

未來好的 AI coding workflow，可能不是讓模型一次吐出最多 code，而是讓它更懂得克制。

例如：

• 能用既有結構解決，就不要長出新架構。
• 能刪掉重複邏輯，就不要複製一份新版本。
• 能小範圍改動，就不要把十個檔案一起打開。
• 能補驗證證據，就不要只交一段「看起來會動」的實作。

這代表工程師的角色也會變。

以前你要花很多時間把 code 寫出來；現在你更常需要判斷：這段 code 該不該存在？這個抽象是不是太早？這個測試是不是真的證明了風險？這次改動是不是把未來維護成本往後丟？

三個簡單檢查

看 AI 產出的 code，可以先問三件事。

第一，它是不是改太多？

如果一個小需求長出很多新檔案、新 helper、新設定層，要先懷疑是不是過度工程。

第二，它是不是重複太多？

重複碼短期很方便，但當規則改變時，每個複製點都可能變成漏改點。

第三，它有沒有證據？

測試、手動驗證、風險說明、未覆蓋項目，這些比「我覺得可以」更重要。

結論

AI 寫碼會繼續變快。

但速度越快，越不能只看產出量。

真正成熟的 AI coding，不是讓專案長出更多 code，而是讓改動更小、證據更清楚、維護成本更低。

未來厲害的工程師，也不只是會叫 AI 寫程式的人。

而是能判斷哪些 code 不該被寫出來的人。

回文章列表