73 歲、從機器碼與 Assembler 時代一路寫過來的 Uncle Bob，現在的 AI Agent 開發策略竟然是：
“My current strategy is to not read any of the code written by my agents.”
真正值得思考的，不是「還要不要自己寫 Code」，而是資深工程師多年累積的設計與工程經驗，如何轉換成 Agent 可以遵循與驗證的工作規範。
上個月底在 X 上有這麼一篇討論：
一位從 1983 年就開始寫程式的資深工程師 Ori Pomerantz 提到，他最近開始嘗試使用 Claude 協助開發，但心裡始終有個坎過不去：
如果最後這些程式碼要由自己負責，那麼自己是不是就應該理解每一段 Code？
所以即使使用 AI，他仍然不太放心讓 Agent 直接修改檔案。
結果底下有一位軟體業界更 "老" 的前輩回了這麼一句：
“My current strategy is to not read any of the code written by my agents.”
意思就是：
「我目前的策略，是不閱讀 Agent 所寫的任何程式碼。」
完全沒想到，原來就是大大有名的 Bob 大叔，Uncle Bob，也就是 《Clean Code》 與 《Clean Architecture》 的作者。
其中 《Clean Code》 我自己反覆讀過好幾遍，而且其中很多觀念都切實應用在我的開發實務裡。
例如我自己會進一步落實成比較具體的開發規範：
- 單一 Method 儘量控制在 20 行以內
- Method 參數儘量不要超過 4 個
- 必然撰寫 單元測試（Unit Test）
- 命名必須具有完整而清楚的語意
有趣的是，進入 AI 輔助開發後，這些以前是要求「自己寫程式時要遵守」的原則，現在反而很適合直接轉換成 AI Agent 的開發規範。
而 Bob 大叔真正想表達的，並非一般人所認為的那種「Vibe Coding」 —— 只求結果，而不太理會 Code 如何組織。
剛好相反。
他的做法是把開發者的角色，從親自撰寫、逐行閱讀實作（Implementation），往更高層次的 「約束（Constraint）」 與 「驗證（Verification）」 提昇，也更能體現軟體開發設計者（Designer）的角色。
（這點我深有同感，所以我把不親自寫程式，而專注於設計與組織軟體的開發人員，稱為「Vibe Coder」。）
例如：
- 單元測試（Unit Tests）
- 驗收測試／Gherkin 規格（Acceptance Tests / Gherkin）
- 品質保證流程（QA Procedures）
- 測試覆蓋率（Test Coverage）
- 品質指標（Quality Metrics）
- 突變測試（Mutation Testing）
AI Agent 可以負責大量實作，但最後一定得通過這整套驗證機制。
換句話說，不再是靠：
「這份 Code 我每一行都看過，所以我相信它。」
而是改成：
「這份實作已經通過我所定義的規格、測試與品質關卡，所以我可以相信它。」
我覺得這個轉變其實很值得資深軟體人員思考。
Bob 大叔今年已經 73 歲了。
他老人家從 1960 年代就開始寫程式，早期甚至是從機器碼、PDP-8 Assembler，一路經歷 FORTRAN、COBOL、C、C++ 這些不同世代的語言走過來。
這種真正從「上古時代」一路親手寫 Code 寫到今天的老人家，都已經開始思考如何從 Syntax 與 Implementation 抽離，把更多實作工作交給 AI Agent。
那麼我輩中流，還有什麼理由拒絕呢？
我自己這兩年也見識與聽聞過不少資深工程師，仍然非常相信自己那套「手板斧」功夫。
凡事還是習慣親身下去「刻」程式碼。
即使已經開始使用 AI，很多時候仍停留在：
問問題 → 查資料 → 生成幾段 Code → 自己再接手寫
這當然也算是 AI 輔助開發。
但我現在越來越認為，真正值得學習的，並非是 「怎麼讓 AI 幫我多寫一點 Code」。
而是：
如何把我們多年累積下來的軟體設計、架構（Architecture）、程式規約（Coding Convention）、測試（Testing）與團隊協作（Team Collaboration），轉換成 AI Agent 可以理解、遵循，而且可以被驗證的工作規範。