「AI 已經能自己寫 Code、修 Bug、跑測試，工程師還需要學系統架構嗎？」
Bilgin Ibryam 在〈8 Software Books AI Has Made More Relevant〉列出八本書，對應產品價值、規格、領域、架構、資料、安全、韌性與交付流。這不是「AI 讓舊書變成定理」的實證；那是作者對工作重心的判斷。但它抓到一個很實際的變化：程式碼產出變快，不代表系統理解、驗證與營運也變快。
我的立場是：**AI 把稀缺工作從輸入程式碼，移到替決策留下可反駁的證據。**以下八個問題不是必讀書單或每次小修改都要填完的 checklist；它們是判斷「這次變更還缺哪種證據」的索引。
八本書不是書單，而是八個不能交給生成器猜的問題
| AI 產出前要先問的問題 | Ibryam 對應的書 | 本次變更應留下的最小證據 |
|---|---|---|
| 這件事真的值得做嗎？ | Escaping the Build Trap | 使用者結果、非目標與完成訊號 |
| 正確行為是什麼？ | Specification by Example | 正常、邊界與失敗案例 |
| 名詞與規則由誰定義？ | Learning Domain-Driven Design | 共同詞彙、owner 與不變條件 |
| 為什麼採用這個設計？ | Software Architecture: The Hard Parts | 被拒絕的選項與 trade-off |
| 舊資料與其他消費者仍相容嗎？ | Designing Data-Intensive Applications, Second Edition | schema／事件契約與 migration 策略 |
| 哪裡跨越信任邊界？ | Threat Modeling: Designing for Security | 資料流、權限與威脅回應 |
| 依賴變慢或失效時會怎樣？ | Release It!, Second Edition | timeout、重試、退化與回退行為 |
| 整個交付流真的變好嗎？ | Accelerate | 從需求到可接受結果的時間與返工證據 |
這個表把原文的閱讀地圖改成審查面，而非宣稱讀完八本書就能安全使用 AI。O’Reilly 對 Designing Data-Intensive Applications 第二版列出的內容，正包含 schema evolution、replication、transactions、partial failure 與 dataflow；這些都是「測試綠燈」仍可能漏掉的跨系統問題。書籍目錄
不買書，也能先用公開資料補齊這八個面向
書本能提供完整的論述與案例；下列資料不是逐章替代品，而是可公開查核、可直接拿來做一次變更審查的最短路徑。
| 決策面 | 公開資料 | 先做的事 |
|---|---|---|
| 產品價值 | Escaping the Build Trap 線上預覽 | 把「要交付的功能」改寫成一個使用者結果與停止條件。 |
| 行為規格 | Gojko Adzic 的 Specification by Example 文章庫 | 為正常、邊界與失敗情況各寫一個範例，再讓 Agent 產生測試。 |
| 領域語言 | Microsoft 的 DDD 與 bounded context 指引 | 列出這次變更的名詞、owner 與不可變條件；有歧義就先問 domain expert。 |
| 架構取捨 | Architecture Decision Records 原始格式 | 用一頁 ADR 寫下 context、選擇、後果與未選方案。 |
| 資料相容 | Apache Avro schema resolution 規格 | 對 producer 與每個 consumer 跑一次舊／新 schema 相容測試。 |
| 信任邊界 | W3C Threat Modeling Guide | 畫出資料流與邊界，列出威脅、回應與殘餘風險。 |
| 故障與退化 | Google SRE：Addressing Cascading Failures | 指定 timeout、retry budget、degraded response 與何時停止重試。 |
| 交付成效 | DORA Core Model 與公開研究 | 同時記錄 flow、返工與使用者／營運結果，不只計算產出量。 |
這些來源都能公開閱讀，但仍要把它們套回本系統的資料、依賴與風險。找不到對應的 owner、consumer 或失敗行為時，不要以通用文章代替這次變更的證據。
速度感和證據是兩件事
GitKraken 在 2026 年 8 月 20 日發布的 調查文章 訪問 554 位開發者與工程主管。84% 的受訪者認為 AI 讓自己更有生產力，但 39% 的組織沒有方法衡量 AI 的影響，另有 33% 主要依賴開發者自述。這是工具廠商發布的調查樣本，不能推論所有團隊，也不能把「感覺更快」解讀成因果證明。
我的做法是先替一種重複任務記錄從開始到通過驗收的時間，包含人工審查與返工。不要只計算 Agent 產生 diff 的時間；上線後若需回退，也要算進交付成本。這是本文的衡量建議，不是調查已證明的改善方案。
除錯前，先對齊 Agent 缺少的脈絡
2026 年 8 月 19 日線上發表的 Reliable Vibe Coding 研究，分析一名開發者使用 Claude Code 建置與除錯系統時的 163 個互動片段。作者提出 human-AI context gap、非同步學習、信任侵蝕與錯誤擴張四個主題，並在這個案例中描述一個迴圈：背景脈絡沒有補齊，Agent 產生局部合理但整體錯置的修改；錯誤增加後，人類得花更多時間解釋、監控與除錯，脈絡差距又變大。
這篇是單一開發者、單一系統的質性研究，互動紀錄來自 2025 年至 2026 年初，並非 8 月才進行的實驗。因此它不能估算失敗率，卻能幫我們看見失敗怎麼累積。把「需求、架構決策、不可變條件、驗收方式」寫進 repository 的文件與測試，目的不是讓 Agent 變聰明，而是縮小每一輪對話中必須猜測的範圍。
生成程式與理解語意，要分開驗證
Nature 旗下 Communications AI & Computing 在 2026 年 8 月 13 日刊出的 SemBench 研究 評估 LLM 對程式靜態語意的理解。研究報告指出，模型在程式碼生成上的表現，可能比對基礎語意屬性的理解進步更快；其中一項弱點是判斷變數的值在後續程式中是否仍可能被使用。研究使用 1,000 個 C 程式檔案建立題目，這是受限的 benchmark，不等於真實 repository 或所有模型。
我據此調整驗收方式：build、單元測試與 lint 都綠，不足以證明 Agent 理解了資料生命週期、跨模組不變條件或故障時序。例如修改 CSV 匯入器，成功讀入一個正常檔案只驗證了一條路徑。空檔案、缺欄位，以及處理到一半失敗時是否留下半成品，都要由需求決定預期行為，再用對應案例驗證。SemBench 本身沒有測試這個匯入情境；這是本文的應用示例。
本文最初從 Andrew Ng 的 Software Engineering Fundamentals 貼文 出發；作者官網 將同題文章列於 2026 年 8 月 28 日。本次更新以以上三份可讀取的一手資料補充，將「基本功很重要」落到具體驗收。
把 Agent 放進一個可驗證的工作流
我會用下面八個問題審查一次 Agent 產生的變更：
| 審查問題 | 可留下的證據 |
|---|---|
| 這件事要改變哪個使用者結果？ | 目標、非目標與完成訊號 |
| 哪些行為必須維持、哪些要改？ | 變更前後的規格、範例或測試 |
| 名詞、規則與例外由誰決定？ | 領域詞彙、owner 與不變條件 |
| 為何採用這個架構而不是另一個？ | ADR 或 trade-off 紀錄 |
| 資料、事件與舊消費者是否仍相容？ | schema 契約、migration 與 rollback 策略 |
| 哪裡跨過信任邊界？ | 資料流、權限檢查與 threat model |
| 測試沒有覆蓋什麼、故障時怎麼停？ | 明列外部服務、併發案例、告警與回退程序 |
| 交付真的更好，還是只更快產生？ | 交付時間、審查輪數、返工與 production 訊號 |
說不清預期行為、資料相容性或失敗處理，就先停止擴大修改。 八題不必全部適用，但每一題都必須有答案或明確的「不適用」理由；否則先縮小範圍或補齊條件，再讓 Agent 繼續。這是本文建議的停止規則，讓下一步取決於可檢查的證據。
下一步：量測一個小變更
挑一個低風險、可回退的 issue，先記錄人工完成它需要的時間、審查輪數、測試結果與回退方式，再讓 Agent 完成同一類工作。比較交付結果與維運成本，而不是只比較產生 diff 的速度。
先拿下一個 issue 寫下適用問題的答案，再開始產生程式碼。