這兩個人最近都上了 Pragmatic Engineer 的訪談，聊的都是 AI 如何改變軟體開發，但他們的觀點卻有巨大的時代差異。

一邊是 Martin Fowler — 2001 年 Agile 宣言的共同作者、經典書籍《Refactoring》和《Patterns of Enterprise Application Architecture》的作者，長期在 ThoughtWorks 擔任首席科學家。他的個人網站 martinfowler.com 大概是軟體工程領域被引用最多的部落格之一，從設計模式、持續整合到微服務架構，很多現在業界習以為常的概念都是他在推廣、定義的。四十年功力的軟體工藝大師。

另一邊是 Peter Steinberger — 奧地利開發者，做了 PSPDFKit 13 年(裝在全球 10 億台裝置上的 PDF SDK)，賣掉公司超過一億歐元後，休息三年、經歷嚴重倦怠，2025 年底重新回來寫程式。這次他帶著 AI 工具，一個人，在 2026 年一月份寫了 6,600 個 commits，做出了 OpenClaw — GitHub 史上增長速度最快的 repo 之一，短短幾週衝破 100K stars，Google 搜尋量超越 Claude Code 和 Codex。現在剛加入 OpenAI。

兩位都是頂尖開發者，但對 AI coding 的看法正面衝突。小編覺得這個對比太有意思了，來整理一下。

最根本的分歧: Vibe Coding

這是兩人差距最大的地方，而且是正面衝突。

Martin Fowler 說: Vibe Coding 斷掉了學習迴圈。你不看程式碼就停止學習，最後手上有一份自己完全看不懂的程式碼，只能從頭重來。他舉了一個很具體的例子: 同事用 LLM 生成了一段 SVG，結果產出的程式碼「驚人地複雜和迂迴」，根本無法微調，唯一的選項就是砍掉重練。他把這比喻成 Stack Overflow 複製貼上的加強版 — 同樣的問題，只是規模更大。

更深一層來說，Fowler 認為 AI 帶來的最根本變化不是抽象層級提高，而是從確定性到非確定性的轉變。他用太太(結構工程師)的思維來類比: 結構工程師永遠在想容差和安全餘裕，軟體開發者現在也需要這種思維 — 你不能把非確定性的邊界推太緊，否則遲早出事。他預測:「在資安領域一定會出大事，因為太多人對這個非確定性掉以輕心了。」

Peter Steinberger 直接說:「I ship code I don’t read.」(我出貨的程式碼我自己不讀。)他的觀點是，你的判斷力應該放在架構決策、使用者體驗、產品方向上，而不是逐行審查 AI 寫的程式碼。完美主義在這個時代是負債，不是資產。不過 Peter 也明確拒絕「vibe coding」這個標籤 — 他稱自己做的是「agentic engineering」(agent 工程)。差別在哪? Vibe coding 是凌晨三點不動腦亂下 prompt; agentic engineering 是深度思考架構、設計回饋迴路、跟模型充分對話之後再讓它去建構。

而且 Peter 認為「不讀程式碼」不代表沒有回饋: 「有人說寫程式時你能感受到摩擦力，這就是好架構的來源。我在下 prompt 的時候也感受到一樣的摩擦力 — 我看程式碼飛過去的速度、我看 agent 有沒有抗拒、我看產出的結構有沒有道理。」換句話說，他的回饋迴圈還在，只是運作在不同的抽象層級上 — 不是看每一行程式碼對不對，而是看整體行為和結構合不合理。

差別不只是觀點不同，而是兩個人在描述完全不同的現實。

工作方式的根本差異

Martin Fowler 的思維模型: AI 是一個你不能完全信任的強力助手。他的建議是把 LLM 的每次輸出都當成「一個產能很高但愛說謊的 junior 工程師送來的 PR」，每一行都要嚴格審查。他特別強調 LLM 會「睜眼說瞎話」，舉了 LLM 被要求插入當天日期結果連錯兩次的例子，然後說:「如果他們真的是個 junior 工程師，HR 應該找他們談談了。」

Peter Steinberger 的思維模型: 你是一個指揮調度者，同時跑 3 到 8 個 AI agent 在平行作業。你的工作是管理方向和驗收結果，不是讀懂每一行程式碼。他把這比喻成星海爭霸的多線操作 — 主基地和分礦同時管理。或是像西洋棋大師同時下多盤棋。他的核心原則是「直接跟它講就好」— 不要寫複雜的 prompt 模板，不要搞花俏的技巧，用自然語言講，越自然越好。

Peter 的做法是「對話優先」: 用「我們討論一下」或「給我幾個選項」讓模型保持在規劃模式，討論架構和取捨，只有說出「build」的時候才讓它開始寫程式碼。他甚至會故意少給指示，讓 agent 自由發揮 — 80% 是廢物，但 20% 會給他意想不到的好點子。

Peter 說了一句蠻震撼的話:「我現在可以造任何東西了。以前你得仔細挑選要做哪個 side project，因為寫軟體很難。現在? 我根本不會 Go，但我有夠好的系統理解力，這就夠了。」這就是那個 6,600 commits 背後的心態 — 實作的摩擦力大幅下降，瓶頸從「會不會寫」變成「知不知道該寫什麼」。

他有個很生動的例子: 在摩洛哥旅行時，透過 WhatsApp 跟他的 AI 助手 Claudebot 對話。他不小心發了一則語音訊息 — 這個功能他根本沒有做過。結果 30 秒後 agent 回覆了。它自己檢查了檔案格式是 OGG、用 FFMPEG 轉檔、發現機器上沒裝 Whisper，就自己翻出 OpenAI 的 API key、用 curl 呼叫轉錄 API，把語音轉成文字回覆他。整個過程完全自主完成，沒有人教它怎麼做。這就是 Fowler 說的「不能信任的 junior 工程師」和 Peter 體驗到的「自主解決問題的 agent」之間的落差。

對「不讀程式碼」的不同解釋

有人可能覺得「不讀程式碼」很危險，但 Peter 說的有個重要前提: 他的系統有自動編譯、lint、測試的回饋迴路，agent 自己會跑測試驗證結果。他不讀程式碼，但他讀結果。

Peter 認為這是整個 AI coding 最關鍵的秘密:「Agent 必須能夠自己除錯和測試自己的輸出。這就是為什麼 AI 寫程式這麼強但寫文章普通 — 因為程式碼可以編譯、lint、執行、驗證，但文章沒有這種客觀的驗證機制。」他叫這個原則「closing the loop」(閉合迴圈)。做 web app 時，他建 CLI 介面讓 agent 不用開瀏覽器就能測試; 做 Mac app 時，讓 agent 自己建一個除錯用的 CLI 工具來呼叫同樣的程式碼。

這和 Fowler 擔心的那種「完全盲目接受輸出」其實不完全一樣 — 驗證的方式從「人眼逐行審查程式碼」變成了「設計系統讓 agent 自己跑測試驗證」。

更激進的是，Peter 甚至在為 agent 優化程式碼結構，而不是為人類:「我設計 codebase 的方式不是讓我自己好讀，而是讓 agent 好用。我會為了讓模型跑得更順而犧牲自己的偏好。反正最後要處理這些程式碼的是它們，不是我。」他還觀察到一個有趣的自我強化效應: 因為程式碼本身就是 agent 寫的，它們的命名和結構天然就是 agent 最容易理解的方式。

Peter 還有一個蠻挑釁的觀察:「大部分 app 在做什麼? 資料從 API 進來是一種格式，parse 完變另一種，存進資料庫又一種，吐出 HTML 再一種。我們就是漂亮的 JSON 印表機。真正困難的問題 Postgres 30 年前就解決了。」如果大部分程式碼本質上就是資料格式的搬運和轉換，那花大量時間逐行審查的價值確實要打個問號。

而 Fowler 這邊，他也承認 AI 在某些場景已經證明了價值: 快速原型、理解老舊系統(ThoughtWorks 把這放到 Technology Radar 的最高推薦等級)、探索不熟悉的技術。但他堅持: 你必須理解程式碼才能演進它，這是不可妥協的。

對工具的態度: 刪繁就簡 vs. 謹慎觀察

Martin Fowler 還在從旁觀察各種工具(Cursor、Claude Code 等)，他自己親身使用的非常有限。他更多是透過跟 ThoughtWorks 同事合作寫文章來理解 AI 的實際影響。他坦承自己「不是每天做 production 工作的人」，主要的角色是幫第一線的實踐者整理和表達想法。

Peter Steinberger 的策略是極簡主義的工具鏈: Ghostty 終端機 + Claude Code / Codex CLI，不用 VS Code 終端(太不穩定)，不用 worktree(反而慢)，不用 subagent(不值得增加複雜度)。他每隔幾個月就更新工作流程，因為模型一直在進步，去年的最佳實踐今年可能已經過時。

Peter 對 MCP 的看法也蠻有意思: 他認為 MCP 是個「拐杖」— 不能串接呼叫、不能過濾結果、所有東西都得預載進 context window。CLI 才是 agent 最自然的工具，因為模型天生就很擅長用 Bash 指令。他甚至做了一個叫 McPPorter 的工具，專門把 MCP 轉成 CLI。

這裡有個蠻有意思的反差: 很多資深開發者試了一下 AI 工具覺得不行就放棄了，Peter 認為這就像「你會彈吉他，我給你一台鋼琴，你試了一下覺得爛，就回去彈吉他了。但那是因為你還沒學會怎麼彈鋼琴，不是鋼琴不好。」他的觀點是: 這是一種完全不同的開發方式，需要投入大量時間才能公平地判斷好不好用。他自己也是凌晨三點對 Claude Code 大吼大叫很多次之後，才慢慢摸出門道的。

怎麼跟 AI 溝通: 精確語言 vs. 自然對話

這裡兩人的分歧也蠻有意思的。

Fowler 對同事 Unmesh Joshi 的一個做法很感興趣: 用 LLM 來共同建構抽象概念和精確語言，然後用這套語言跟 LLM 溝通，提高輸出的可靠性。他舉了一個例子: 如果你用自然語言描述棋局，LLM 學不會下棋; 但如果用棋譜記號，它就能學會。他的推論是: 也許我們需要發展出一套跟 LLM 溝通的精確語言(類似領域專用語言)，才能從這個非確定性工具中得到更可控的結果。

Peter 的立場完全相反: 直接用人話講就好。不要寫複雜的 prompt 模板，不要搞花俏的技巧，越自然越好。

一個要打造精確語言來馴服非確定性，一個說直接講人話讓模型自己搞定。這反映了兩人對 AI 能力上限的根本判斷不同。

重構: 兩種完全不同的體驗

Fowler 認為重構在 AI 時代更重要 — 如果 AI 產出大量「能跑但品質可疑」的程式碼，重構就是讓它變好的方式。但他也坦承，LLM 目前不太擅長做重構。他的同事用 Cursor 重新命名一個 class 花了 1.5 小時，消耗 10% 的月度 token 配額，而 IntelliJ 二十年前就能秒完成。他比較看好 LLM + 確定性工具的組合: 用 LLM 做初步分析，再用傳統工具做精確操作。

Peter 的體驗完全相反: 他把整個系統從單一 agent/單一模型供應商改成多 agent/多供應商架構，手動估計要兩週，Codex 三小時搞定。一次 15,000 行的 plugin 架構重構，agent 產出的結果他形容為「好到不可思議」。

這個差異可能反映的是工具進步的速度 — Fowler 的同事用的是較早期的 Cursor 體驗，Peter 用的是最新的 Codex，兩者的能力差距確實不小。

對開發者的建議

Fowler 對新手的建議: 找一個好的資深導師，這比選公司、選技術棧都重要。用 AI 工具但保持懷疑，主動問它「你為什麼這樣建議?」，理解輸出而不只是使用輸出。他判斷資訊來源品質的標準蠻有意思: 越是充滿不確定性、願意說「我不確定」的人，反而越值得信任。

Peter 對新手的建議: 保持無限好奇心，瘋狂去做東西。用 AI 當無限耐心的老師 — 找複雜的開源專案，問模型「這為什麼要這樣設計?」來獲得系統層級的理解。年輕人其實有優勢，因為他們不會被舊經驗綁住。

Fowler 認為核心能力是溝通 — 理解該寫什麼比會寫程式碼重要得多。Peter 認為核心能力是品味 — 感受產品該怎麼做、使用者體驗該怎麼設計。方向其實一致: 純粹的 coding 技能在貶值，但知道「該做什麼」和「做得好不好」的判斷力在升值。

Peter 還把開發者分成兩類: Builder 型(在乎產品、成果、使用感受)在 AI 時代如魚得水; Problem Solver 型(喜歡演算法、純技術挑戰、不太在乎產品本身)會比較掙扎，因為「那正好是 AI 擅長做的事」。

兩人的共識

儘管風格截然不同，有些事情兩人其實一致同意:

🔹 都反對無腦的 vibe coding: Fowler 說它摧毀學習迴圈; Peter 說那是「凌晨三點的產物」。兩人都強調你必須理解你在建構什麼，只是理解的層次不同。

🔹 架構思維比以往更重要: Fowler 強調建立好的抽象層; Peter 說「用 agent 寫程式反而讓你變成更好的工程師，因為你必須更認真想架構」。

🔹 測試不可少: Fowler 引用 Simon Willison 的經驗強調測試; Peter 把測試內建進 agent 的回饋迴路。執行方式不同，但都認為不可跳過。

🔹 迭代開發仍然是王道: Fowler 堅持 Agile 的小切片快速循環; Peter 批評那些寫完整規格書然後讓 AI 跑一整天的做法是「瀑布式開發的復辟」— 兩人都認為這種「先寫完整 spec 再讓機器去 build」的模式行不通。

🔹 AI 不會消滅軟體開發，但會徹底改變它: Fowler 類比為組合語言到高階語言的轉變; Peter 說軟體開發還是很難，只是難的地方不一樣了。

誰說的更對?

兩個人其實面對的是不同的問題。

Martin Fowler 說的是企業軟體的現實 — 有老舊系統、有監管要求、有一大群工程師要協調、程式碼要維護幾十年。他提到跟美國聯邦儲備銀行的人聊過，他們目前完全禁止使用 LLM，因為出錯的代價太大了。在這個語境裡，Fowler 的原則都沒錯。而且他指出一個常被忽略的結構性問題: 就算 AI 讓生產力提高十倍，你還是需要一個十人團隊來做以前百人團隊做的事，而我們根本還沒搞清楚 AI 在團隊環境中該怎麼用。

Fowler 也點出一個重要的產業大背景:「打擊我們最大的不是 AI，是零利率時代的結束。」軟體業已經裁了數十萬人，同時 AI 泡沫又在膨脹，兩件事同時發生，一個掩蓋另一個。他認為 AI 確實有價值(不像 blockchain)，但泡沫遲早會破，破了之後剩下什麼才是重點。

Peter Steinberger 示範的是一個人做產品的天花板 — 沒有老舊系統包袱、自己就是 PM 和 CTO、可以每天根據結果調整方向、出問題了直接砍掉重練。在這個語境裡，他的方式確實讓人大開眼界。一個月 6,600 個 commits、GitHub 史上最快破 100K stars，這些數字說明了 AI 時代 solo builder 的上限可以有多高。

但 Peter 也沒有迴避黑暗面。他直說:「公司大概可以縮減到 30% 的人力，這非常可怕。經濟上這會是一場災難，很多人會在新世界裡找不到位置。」而且他認為大公司要成功導入 AI，需要的不只是技術轉型，而是「對公司做一次大重構」— 不只是程式碼，是整個組織架構都要重新設計。

還有一個蠻有意思的觀察: Peter 認為他離開科技圈三年反而是優勢。其他資深開發者從 GPT-2 一路看到 GPT-4，過程中累積了「AI 就那樣」的刻板印象。Peter 跳過了這段撞牆期，直接遇到最強的工具，所以能用全新的眼光看待可能性。這某種程度上解釋了為什麼 Fowler 這樣長期觀察 AI 的人，和 Peter 這樣帶著新鮮眼光進場的人，會得出如此不同的結論。

小編的看法

坦白說，小編讀完兩場訪談之後，覺得 Peter Steinberger 帶來的啟發更大。

Fowler 說的那些原則 — 小切片、學習迴圈、測試 — 本質上都沒錯。但他自己在訪談裡也坦承:「我寫的唯一 production code 是我自己網站的程式碼。」他現在的工作主要是編輯同事寫的文章，而不是親自動手做專案。一個人在談 AI 時代的工程原則，但他其實沒有在 AI 時代真正用 AI 寫過複雜的軟體 — 這個落差是存在的。道理都對，但「道理對不對」跟「實戰管不管用」是兩件事。

反觀 Peter，他的每一個觀點背後都有具體的實作經驗: 一個月 6,600 commits、三小時完成兩週的重構、agent 自主處理語音訊息。這些不是理論推演，是可驗證的成果。在這個技術快速變動的時刻，第一線實戰者分享的具體經驗，往往比原則性的框架討論更有操作價值。

當然，Peter 的做法不是放諸四海皆準 — 主持人 Gergely 自己也提醒，OpenClaw 比較「YOLO」，跟 production 系統還是有差距。兩人的背景差異也決定了他們的視角: Fowler 長期待在 ThoughtWorks，面對的是企業客戶的老舊系統、監管要求、大型團隊協作; Peter 是連續創業者，自己就是 PM 和 CTO，做的是從零開始的新產品，出問題了直接砍掉重練。不同的戰場，自然會長出不同的方法論。

但如果要問「在 AI 時代，誰的經驗更有啟發?」小編會說是 Peter。理論框架和第一線實戰之間的落差，大概就是 Fowler 的觀點讓人覺得「道理都對，但好像少了什麼」的真正原因。