展示永遠能成功

每個 AI 程式開發的展示都遵循相同的弧線。有人對模型下達提示。一個能運作的應用程式就這樣出現了。觀眾印象深刻。

他們確實該如此。速度是真的。能力是真的。有 AI 參與時，第一版確實交付得更快。

問題是，第一版從來都不是困難的部分。

成本真正集中在哪裡

軟體工程的成本不集中在初始創建。它集中在第四、第五、第六次迭代：

  • 驗證供應商需要更換，因為定價改變了。
  • 分析工具需要遷移，因為廠商被收購了。
  • 需要新增一個功能，涉及三個原始生成從未預想到的畫面。
  • 樣式系統需要替換，因為設計師改變了方向。
  • 支付整合需要置換，因為產品擴展到新市場。

這些都不是初始生成的失敗。它們都是正常的產品開發。問題是 codebase 讓這些變更是便宜還是昂貴的。

變更壓力下的 AI 生成 Codebase

大多數 AI 生成的 codebase 能應付第一次變更。第二次變更就不太舒服了。到了第四次變更，團隊開始回報相同的症狀：

  • 「我們要求 AI 置換驗證供應商，但它動了 14 個檔案。」
  • 「refactor 破壞了本應無關的 module 中的測試。」
  • 「我們無法判斷系統的哪些部分依賴分析 SDK。」
  • 「每次變更都需要重新理解整個 codebase。」

這些症狀不是模型失敗。它們是架構失敗。模型生成了一個沒有 boundary 的系統，現在每次變更都有不可預測的爆炸半徑。

為什麼 AI Codebase 退化得更快

傳統的 codebase 也會退化。但 AI 生成的 codebase 退化得更快，原因很具體：

沒有共享的心智模型。 人類團隊在數月間建立結構直覺。AI 生成程式碼時沒有記憶為何做出先前的決策。

為即時提示最佳化。 模型解決當前的請求。它們不為接下來五個請求最佳化。每次生成做出局部正確但全域不一致的決策。

數量放大耦合。 AI 更快生成更多程式碼。更多缺乏 boundary 的程式碼意味著更快的耦合。速度優勢變成退化加速器。

Refactor 需要全域上下文。 模型難以處理跨越整個 codebase 的 refactor，因為上下文窗口有限且架構意圖是隱含的。

真正的工程挑戰

AI-native 開發中真正的工程挑戰不是「如何生成更好的程式碼？」

而是「如何建構系統，使 AI 生成的部分可以獨立變更？」

這意味著：

  • 讓爆炸半徑可預測的 boundary。
  • 將變動與穩定解耦的 interface。
  • 讓依賴圖顯式化的 composition root。
  • 無需完整系統即可驗證整合的 contract tests。
  • 能夠刪除並重新生成任何 module 而不產生連鎖故障的能力。

長期維護是結構問題

再好的提示也無法修復一個每個 module 都深入其他 module 的 codebase。你無法靠提示來擺脫架構耦合。

長期 AI codebase 維護需要一直以來都需要的同樣紀律：boundary、contracts 和隔離。不同的是，AI 的速度讓缺乏這些紀律的後果更快顯現。一個原本需要兩年才能創建出不可維護單體應用的團隊，現在兩個月就能做到。

速度既是禮物也是陷阱。沒有結構，它只意味著你更早抵達維護危機。

與 AI-Native 架構的關聯

這是我在 Stanford CS146S 對 AI 程式開發的見解是對的——缺少的科目是架構 中提出的核心論點：缺乏架構紀律的工具熟練度，產出的 codebase 創建快速但維護昂貴。

現代軟體開發者兩者都需要。用 AI 工具快速交付的能力，以及在第一版之後仍能持續快速交付的架構紀律。

第一版從來都不是問題。問題是第五版是否仍然便宜。

常見問題

為什麼 AI 生成的 codebase 會變得難以維護？

AI 模型為即時提示最佳化，而非為未來的變更最佳化。這產生能運作但缺乏獨立修改所需 boundary 的程式碼。沒有明確的架構限制，耦合比手寫 codebase 累積得更快，因為 AI 更快生成更多程式碼。

如何防止 AI codebase 隨時間退化？

三個結構性做法：用應用程式擁有的 interface 來 enforce module boundary、在 composition root 集中依賴連接、執行獨立驗證整合點的 contract tests。這些讓變更成本可預測，無論程式碼是如何生成的。

AI 生成的程式碼比人類撰寫的程式碼更難 refactor 嗎？

本質上不是。但 AI 生成的程式碼更可能缺乏讓 refactor 安全的結構性 boundary，因為模型不會自發地為未來變更最佳化。解決方法是在生成之前施加這些 boundary，而非期望模型自己產出它們。

AI 程式開發對長期專案的最大風險是什麼？

最大的風險是速度陷阱：在早期階段交付得太快，以致架構債務在團隊注意到之前就已累積。等到維護變得昂貴時，codebase 已經耦合到無法漸進式修復的程度。