想法一直是對的，問題在於不划算

軟體工程裡有很多方法，你一讀就會覺得「這本來就該這樣做」。

當然應該用 contracts 明確 function 能接收什麼、必須回傳什麼。當然 tests 不該只寫幾個人工挑選的例子，而應該驗證 properties。當然團隊不該把 coverage 當成品質代理，而應該真的去判斷 tests 能不能抓到 faults。也當然，架構決策應該和程式碼保持同步，而不是寫完就爛在文件目錄裡。

這些想法本身從來不荒謬。問題一直是經濟性。它們貴的不是 compute，也不是工具授權，而是最難擴張的資源: 持續性的 specialist attention。

過去很多強工程策略都死在同一個循環裡。團隊很有熱情地引入，品質也真的提升了，然後維護成本開始出現。contracts 開始 drift，property tests 跟不上 schema 變化，surviving mutants 越積越多卻沒人 triage，架構文件逐漸變成 fiction。它們不是因為「理論錯了」才失敗，而是因為它們要求的持續 expertise 遠超多數產品團隊能穩定投入的程度。

這才是目前 AI 時刻真正重要的地方。關鍵變化不只是模型能更快寫 code，而是模型開始能接住過去最昂貴的 specification 與 verification 勞動。

真正把這些策略困在小眾裡的是什麼

不是 compute。便宜 compute 很早就有了。

也不只是 tooling。不少方法早就有成熟工具，但工具仍然預設有人知道該怎麼寫 invariants、generators、contracts、boundary rules。

真正的 bottleneck 是一種很難並行化的 expertise。

  • Design by contract 需要有人能寫出在 refactor 之後仍然有意義的 preconditions、postconditions、invariants。
  • Property-based testing 需要有人看到一個 function 時，會自然想到 round trip、idempotence、error behavior、algebraic properties，而不只是幾個 examples。
  • Mutation testing 需要有人能 triage survivors，判斷它們暴露的是真空缺還是 harmless equivalent mutants。
  • Type-level correctness 需要團隊理解 branded types、phantom types、typestates，甚至 formal verification tooling。
  • Living specifications 需要持續把人的決策翻譯成可執行的 architecture rules。

每一種策略都有自己的 maintenance tax。把它們組合起來會更貴，因為你還得寫中間那層 glue。

所以很多「good on paper」的方法最後只留在 aerospace、finance、formal methods research，或極度自律的 infrastructure teams 裡。方法有效，staffing model 不成立。

AI 改變了什麼

AI 不是拿走 engineering judgment，而是改變 judgment 花在哪裡。

以前 senior engineer 得手寫大部分 scaffolding。現在模型可以先起草 contract、建議 properties、搭出 schema、把自然語言決策轉成 architecture rule，甚至順手為 surviving mutant 寫一個 regression test 初稿。人類工程師不再從空白頁開始，而是把精力放在 domain correctness review 上。

這個變化比表面看起來大得多。

舊工作流是 author-heavy，新工作流變成 review-heavy。

這意味著:

  • contracts 的導入成本下降了
  • property-based testing 變得更現實了
  • mutation testing 終於更可營運了
  • architecture constraints 更容易真正落地到 CI

真正的經濟性突破就在這裡。不是「用模型取代工程師」，而是讓過去需要 specialist authorship 的策略，變成一般產品團隊也能承受的東西。

更關鍵的一點: 這些策略組合起來才更強

最有價值的變化，不是某一個技術單點變便宜了。

真正有意思的是，AI 讓整套 stack 的組合成本下降了。

一個 contract 可以變成 property test 的來源。一個 property test 可以再交給 mutation testing 去衡量強度。一個 schema 可以定義 runtime boundary。一個 ADR 可以變成 architecture rule。一個 branded type 可以在 runtime checks 之前先收緊 surface area。價值不只在每一層本身，更在這些層之間的 glue。

在 AI 之前，多數團隊連其中一個策略都很難 justify。AI 之後，同時組合幾層開始變得現實，而且不必把 reliability work 做成全職 specialist program。

這不是魔法

當然也有錯誤做法。

如果你只是讓 AI 生成 code、contracts、tests，卻沒有 deterministic enforcement，那你得到的只是一大堆看起來很像那麼回事的文字。目標不是讓模型「批准」你的 codebase。目標是讓模型幫助你產出可以被低成本、重複驗證的 artifacts。

所以真正有效的模式依然很樸素:

  • 用 AI 生成
  • 用 deterministic tools 驗證
  • 在 specification level 做 review
  • 一旦規則被破壞，就讓 CI 立即失敗

AI 在這裡的價值，是補上 expertise gap，而不是充當最終裁判。

為什麼現在尤其重要

今天很多團隊已經在用 AI 壓縮 implementation time。真正的風險是，delivery speed 的成長速度，超過 verification depth 的成長速度。

如果發生這種失衡，你得到的不會是一個更高效的工程組織，而只是一條更快滑向 fragile systems 的路徑。

真正的機會，是用同樣加速生成的模型，把過去太貴而無法持續的 reliability practices 重新帶回來。這樣，速度才不會直接變成 operational debt。

未來幾年，真正佔優的會是那些很早意識到這一點的團隊。AI-assisted coding 本身不是策略。AI-assisted verification and enforcement 才是。

這也是為什麼那麼多老工程策略突然重新重要起來: 不是因為它們突然變得更正確，而是因為它們終於變得在經濟上可行了。