最近讀到兩篇談 AI 寫程式的文章，乍看好像在吵架，細看才發現實在是同一件事的兩面，頗具參考性：
核心互補性
Jason Gorman 的文章（Codemanship）強調：
- AI 不會取代程式設計師
- 程式設計的難點在於將人類思維轉化為精確的計算思維
- LLM 說穿了只是在做模式匹配，並不是真的理解你的程式碼
Steve Krenzel 的文章（Bits of Logic）則說明：
- AI agent 得有夠水準的程式碼環境才跑得動
- 那些好習慣（測試、型別、文件）從「有最好」變成「沒有不行」
- AI 會「把程式碼庫最糟糕的傾向放大」
三個層次的互補
1. 戰略層面的一致性
兩位作者其實都同意一件事：人類程式設計師還是主角
- Gorman：「當事情重要時，軟體開發人員會掌舵」
- Krenzel：「agent 只有在你為它們創造的環境裡才有效」
所以這不是「AI vs 人類」的零和遊戲啦，而是人類定義規則，AI 在規則內執行。
2. 技術層面的呼應
Gorman 點出 LLM 的根本限制：
- 不理解程式碼，只做統計預測
- 同一個提示丟進去，吐出來的結果還不一樣
- 終究還是得靠人類驗證輸出
而 Krenzel 開的藥方，剛好就是衝著這些限制來的：
- 100% 程式碼覆蓋率：逼 AI 用可執行的範例證明每一行
- 強型別系統：縮小 AI 的搜尋空間，讓非法狀態根本寫不出來
- 快速回饋循環：把 AI「綁在短繩上」，小改動→檢查→修復
講白了就是：既然 AI 不理解程式碼，那我們就用機械化的護欄把它框住。
3. 實踐層面的轉化
Gorman 的預測蠻悲觀的：
「LLM 實際上讓大多數團隊變慢，軟體更不可靠、更難維護」
Krenzel 則給了一條避開這個坑的路：
- 不是放 AI 自由發揮，而是建立嚴格的自動化護欄
- 不是期待 AI 看懂商業邏輯，而是透過型別和測試把邏輯外化出來
- 不是一口氣生出一大坨程式碼，而是快速迭代、持續驗證
深層洞察：AI 作為「放大器」
這兩篇文章其實都指向同一個關鍵：
AI 不是替代品，而是放大器
- 如果你的程式碼庫一團亂、測試不夠、型別鬆散 → AI 會把這些問題放大（Gorman 的警告）
- 如果你的程式碼庫結構漂亮、測試完整、型別嚴格 → AI 會把生產力放大（Krenzel 的承諾）
我想這也解釋了為什麼：
- Gorman 看到的失敗案例：團隊想用 AI 來補技術債，結果債務反而加倍
- Krenzel 看到的成功案例：團隊先乖乖把「技術稅」繳了，再用 AI 領紅利
對實踐的啟示
兩篇合起來看，大概可以拼出一套完整的策略：
短期（現在）
- 先別急著裁程式設計師（Gorman 的建議）
- 把錢投在程式碼品質的基礎建設上（Krenzel 的路線圖）
- 建立 100% 測試覆蓋率
- 遷移到強型別語言
- 凡是能自動化的檢查，通通自動化
中期（1-3 年）
- 把 AI 當成「需要盯著的實習生」
- 重複性的雜事可以丟給它
- 但你得給明確的規則和即時回饋
- 架構決策還是別交給它
長期（3+ 年）
- 重新定義「程式設計師」這個角色
- 從「寫程式碼」轉向「設計系統和護欄」
- 從「實作功能」轉向「定義不變量和約束」
- 比較像「系統架構師 + 品質工程師」的綜合體吧
一個有趣的悖論
Krenzel 那篇文章的標題是《AI is forcing us to write good code》，但說真的：
AI 根本沒逼任何人做任何事
真正發生的是：
- 那些本來就想把程式碼寫好的團隊，發現 AI 剛好給了他們一個超好的理由去說服管理層掏錢
- 那些不想在品質上投資的團隊，則發現 AI 把事情搞得更糟了
這跟 Gorman 的觀察其實完全吻合：AI 不會改變基本面，只會加速本來就在跑的趨勢。
結論
所以這兩篇文章一點都不矛盾，反而像是同一枚硬幣的兩面：
- Gorman 講的是「為什麼」：為什麼 AI 不會取代程式設計師（因為難的從來不是語法）
- Krenzel 講的是「怎麼做」：怎麼讓 AI 變成真的好用的工具（靠的是建立嚴格的環境）
兩篇湊在一起，倒是描繪出一個還算清楚的未來：更多的程式設計師，寫更好的程式碼，把繁瑣的雜活丟給 AI。
只是這個未來不會自己走過來——它需要你有意識地投資，還要一點紀律。想通這件事的團隊會活得很好，沒想通的大概就會繼續掙扎吧。
那麼，你的團隊現在卡在這條光譜的哪一段呢？哪些「技術稅」最值得你先繳？我自己是覺得，測試覆蓋率大概是 CP 值最高的那一筆… :-)