為什麼 AI coding agents 需要 architecture co…

AI coding agents 需要能強制結構的 architecture compiler，而不只是 tests 和 lint。

Atomadic Forge 的方向是對的：AI 寫碼最大的問題不是寫不出能跑的程式，而是把系統形狀悄悄寫壞。程式能執行，不代表架構還能維護；當 agent 一次產出大量程式碼時，真正的風險是依賴方向、層次邊界和模組責任開始漂移。Forge 把架構變成可量化、可驗證、可自動修復的東西，這才是面對 AI code sprawl 的正解。

第一個論點

tests 和 lint 只能抓局部錯誤，抓不到架構破壞。你可以有全綠的測試，也可以有乾淨的型別檢查，但同時讓 utility module 去依賴 feature module，或讓 CLI entry point 慢慢吞進商業邏輯。這類問題不是語法錯誤，而是結構錯誤；一旦 agent 以速度為優先，這種錯最容易被放過，最後變成整個 repo 的技術債。

Forge 的五層 composition law 正是把這件事變成硬規則：a0 放常數與純資料，a1 放純函式，a2 放有狀態的 class 與 client，a3 組裝功能，a4 負責 orchestration 與 entry point，而且只能向上依賴。這不是美學偏好，而是可執行的邊界。當規則寫成機器能檢查的約束，AI agent 才不會把「看似合理」的實作，默默變成結構災難。

第二個論點

架構若不能被量化，就只能靠感覺治理，而感覺在 AI 時代不夠用。Forge 的 0 到 100 certification score 直接把討論從「這個 repo 看起來乾淨嗎」變成「它現在是幾分、哪裡違規、修完後有沒有變好」。在公開案例裡，分數從 47 拉到 91，violations 從 34 降到 3，還自動修掉 31 個問題。這種結果說明它不是只會報警，而是真的在改善結構。

更重要的是，它把架構審查變成可追溯的工件。SHA-256 receipt 的價值不在於炫技，而在於可驗證：團隊可以 gate merge、比對快照、證明某個時間點的 codebase 符合結構標準。對 AI-assisted workflow 來說，這比「我覺得應該沒問題」可靠太多，因為 agent 可能來自不同 editor、不同 prompt、不同人手上，沒有一個可稽核的結構憑證，架構就只是口頭承諾。

反方可能怎麼說

最強的反對意見是：架構不是 compiler 能完全定義的。真實系統有 legacy、例外、domain-specific tradeoff，也有產品節奏和交付壓力。若把五層規則當成鐵律，工具很容易變成教條，最後不是幫助團隊，而是拖慢團隊。從這個角度看，最好的架構工具應該少管事，別把所有專案都塞進同一種模型。

這個批評有道理，但只成立到一半。沒有人該要求一個工具定義所有系統的完美架構；Forge 真正該被要求的，是在 AI 最容易製造結構債的地方，提供明確、可執行、可驗證的依賴約束。它不是在宣稱宇宙級的架構真理，而是在把常見且昂貴的違規先攔下來。對多數團隊而言，這已經足夠有價值，因為真正拖垮速度的，往往不是少數例外，而是大量被放過的結構失守。

你能做什麼

如果你是工程師，別再把 AI 產出的程式碼當成只要測試過就算完成。把 dependency direction、layer boundary、cycle detection 納入 definition of done，並把架構檢查放進 agent 寫碼的同一個流程裡，而不是事後清理。如果你是 PM 或創辦人，要求的不只是 CI 綠燈，而是結構分數和違規趨勢。能跑的程式只是底線，能長期維護的系統才是產品；在 AI-heavy 開發裡，忽略架構的人會先拿到速度，最後付出重構、故障和停滯的代價。