為什麼在 AI 時代，軟體工程基本功反而比以往更重要？
Matt Pocock 在 2026/4/9 於 AI Engineer 研討會所給的 Keynote
演講中提到
目前的軟體開發範式確實正在經歷劇變，甚至出現了「從規格到代碼（Specs to Code）」這種試圖完全跳過人工編碼、將開發者邊緣化的運動。
然而身為資深技術架構師，他認為：AI 雖然改變了開發工具，但並未讓傳統軟體開發原則過時。相反地，這些基本功現在是決定 AI 產出品質的關鍵因素。當撰寫代碼的成本降低，系統設計的品質反而成為區分「平庸」與「卓越」的唯一分水嶺。
以下是他的論點
重點一：「從規格到代碼」的陷阱與軟體熵的威脅
「從規格到代碼」的理念宣稱：開發者只需撰寫規格文件，交給 AI 生成代碼；若有問題，就修改規格並重新運行，完全不需看代碼。這聽起來很美好，但實踐證明，這是一場通向災難的「向下螺旋」。
當我們單純依賴 AI 根據規格產出代碼，而不去審視與維護其內部結構時，會導致代碼品質隨著每一次迭代而劇烈劣化。你每運行一次 AI 「編譯器」而忽視代碼設計，系統的混亂程度就會呈指數級增加。這正是《工程師修煉之道 (The Pragmatic Programmer)》中提到的「軟體熵 (Software Entropy)」——如果只關注當下的功能變更而忽視系統整體的設計，代碼庫就會趨向崩潰。
John Ousterhout 在《軟體設計哲學 (A Philosophy of Software Design)》中對「複雜度」有精闢的定義：
「複雜度 (Complexity) 是任何與軟體系統結構相關，且會導致系統難以理解與修改的事物。」
在 AI 開發環境下，若放任 AI 產生難以修改的「垃圾代碼」，系統很快就會陷入無法維護的僵局。身為架構師，我要求團隊絕不能放棄對代碼的掌控，因為一旦你停止投資於設計，你就是在對系統進行「撤資 (Divesting)」。
重點二：「程式碼很便宜」是個危險的迷思
當前開發界流行一種觀點：「代碼現在很便宜。」這是一個極度危險的誤區。
事實上，壞代碼是史上最昂貴的資產。因為一個設計不良、邊界模糊的代碼庫，會成為 AI 發揮潛力的巨大阻礙。我觀察到 AI 在一個優質的代碼庫（Good Codebase）中表現極其出色，但在混亂、高熵的系統中則會頻頻出錯且製造更多 Bug。
「代碼並不廉價。事實上，壞代碼現在比以往任何時候都更加昂貴，因為它剝奪了你利用 AI 紅利的機會。」
在 AI 工具普及的今天，維護代碼品質不再僅僅是一種工匠精神的美德，它已轉變為一種生存競爭力。一個具備良好基礎、易於測試的代碼庫，才是 AI 能高效運作的「溫床」。
重點三：運用「拷問我 (Grill Me)」Skill 達成共享設計概念
為什麼 AI 常常做不出我們想要的東西？這通常源於 Frederick P. Brooks 在《設計的設計 (The Design of Design)》中提到的溝通障礙：雙方缺乏一個共同的「設計概念 (Design Concept)」。
當你與 AI 協作時，存在一種關於「我們要建什麼」的隱形假設。如果雙方對此缺乏共識，AI 就只是在盲目執行命令。
為解決此問題，Matt Pocock 分享了他的 Skills For Real Engineers 在 GitHub 上已獲得超過 684,000 顆星，應該很多人覺得有幫助。
他極力推薦一種名為 「拷問我 (Grill Me)」 的技能。與其直接下指令，不如對 AI 下達這樣的指令：
「針對這個計畫的每個面向不斷對我進行提問，直到我們達成深層的設計共識。請沿著設計樹 (Design Tree) 的每個分支，逐一解決決策間的依賴關係。」
它能將 AI 從單純的執行者轉變為「對抗式」的設計夥伴，有時 AI 會連續提出 40、60 甚至 100 個問題來挑戰你的設計細節。這種深度對話能強迫開發者在動工前理清思路，確保雙方在同一條船上。
重點四：建立「統一語言 (Ubiquitous Language)」減少 AI 的廢話
他指出 AI 有時產出的內容過於冗長 (Verbose) 且抓不到重點？這通常是因為語言不對等。
借用領域驅動設計 (DDD) 的概念，核心策略應該是與 AI 建立一套 「統一語言 (Ubiquitous Language)」。具體作法是要求 AI 掃描代碼庫，並生成一個包含核心術語表 (Terminology) 的 Markdown 表格 (Markdown Table)。
這份表格定義了開發者與 AI 共同遵循的術語標準。當 AI 擁有明確的術語框架時，你在閱讀它的「思維路徑 (Thinking Traces)」時會發現，它的計畫變得更精簡，實現過程也會精確地符合你的業務意圖，有效減少無謂的廢話產出。
重點五：深度模組化 (Deep Modules) 是 AI 導航的指南針
在 AI 時代，系統架構決定了 AI 的開發效率。人類工程師必須學會區分「淺層模組」與「深度模組」：
-
- 淺層模組 (Shallow Modules)： 內部邏輯貧乏但介面複雜。如果代碼庫充斥著無數細小、分散的「小肉球 (Blobs)」，不僅 AI 會在導航時迷失方向，人類大腦也會因為過高的認知負擔（Cognitive Load）而感到前所未有的疲憊。
- 深度模組 (Deep Modules)： 核心定義在於 「將豐富的功能隱藏在簡單的介面之後」。
Matt Pocock 提倡的戰略是 「設計介面、委派實現」，並將模組視為 「灰色盒子 (Gray Box)」。身為架構師，你應投入大量精力精雕細琢模組的介面與邊界，確保它們具備高度可測試性；至於內部的具體實現，則可以放心地委派給 AI。
這種結構能完美支持 測試驅動開發 (TDD)。在 TDD 模式下，AI 被強迫採取細小且明確的步驟（Small Steps），有效避免《工程師修煉之道》所警示的 「超速行駛 (Outrunning your headlights)」——即回饋速度跟不上開發速度的風險。深度模組提供的清晰邊界，正是 AI 在黑暗中前行時最可靠的照明。
Matt Pocock 的總結： 「你是戰略指揮官，AI 是你的前線軍士」
在 AI 時代，工程師的角色必須發生轉變。我們必須從繁瑣的「戰術編碼 (Tactical)」抽身，轉向更具價值的「戰略設計 (Strategic)」。
AI 就像是一個極其高效、在前線衝鋒陷陣的軍士長，但他需要一位具備戰略眼光的指揮官來指引方向。正如大師 Kent Beck 的核心建議：「每天都要為系統設計進行投資 (Invest in the design of the system every day)。」
當撰寫代碼的門檻不復存在，你對軟體工程基本功的堅持、對系統架構的洞察，將成為你最不可替代的核心價值。最後，請捫心自問：在 AI 面前，你是那個只會改規格的旁觀者，還是那個能指揮 AI 構建宏大建築的總建築師？