Claude Code 之後，工程師還剩下什麼？
最初的問題
最近跟主管 1-1 時，我提出了幾個自己這陣子反覆在想的問題。
第一個問題是，Claude Code 出現之後，我發現人很容易放棄思考。以前寫 code 時，至少還會逐行理解自己寫了什麼；現在有了 AI coding agent，很容易變成把需求丟給 AI，然後接受它產出的結果。表面上效率提高了，但人也可能在不知不覺中從主駕駛變成副駕駛，甚至只是坐在後座。
第二個問題是 code review 的壓力變得很大。現在大家都可以用 AI 寫出大量程式碼，產出速度變快，但 review 的成本並沒有同步下降。有時候我花很多時間去 review，問得越深，越會發現寫 code 的人其實沒有完全理解那段邏輯，甚至有些東西是不需要寫的。更直接一點，有時候得到的回答只是：「這是 AI 寫的。」結果就變成 coding effort 很低，但 review effort 很高，瓶頸反而全部卡在 reviewer 身上。
第三個問題是，當 Claude Code 變得越來越強，工程師到底還有哪些事情是不能被取代的？
他的回應
主管給我的回應很簡單，但我覺得很關鍵。
重點不是告訴 AI「怎麼做」，而是要定義清楚「要做成什麼」以及「如何驗證」。團隊要讓 AI 參與開發流程，就需要有共識、有規則，而且這些規則應該被寫進 CLAUDE.md，變成團隊共同遵守的工作方式。讓 AI 幫忙 review 也不是叫它隨便看，而是要用我的方式問問題，讓它協助我檢查我在意的事情。
換句話說，核心不是 prompt 寫得多漂亮，而是 target driven。AI 可以幫我們完成 task，但人要先定義清楚 target 是什麼。
工具一樣 != 結果一樣
這讓我想到一個例子。
同樣是請 ChatGPT 安排日本五天四夜行程，一個第一次去日本的人，跟一個已經去過日本很多次的人，得到的結果一定不會一樣。
第一次去的人，可能會直接接受 AI 排出來的行程。看起來景點很多，交通也似乎合理，就覺得差不多了。但有經驗的人會繼續追問：這樣的交通順嗎？住這裡方便嗎？這次旅行的目的是什麼？是想看風景、吃東西、購物，還是帶小孩放鬆？每天的移動時間會不會太長？有沒有更好的路線？哪些地方只是有名，但其實不一定適合這次的需求？
工具是一樣的，但結果不會一樣。
工程師的價值
差別不在於有沒有 AI，而在於使用者有沒有足夠的經驗、判斷力、問題意識，以及持續優化結果的能力。
回到工程開發也是一樣。
如果目標是模糊的，AI 產出來的東西就很容易歪掉。它可能寫了很多 code，看起來也很完整，但不一定真正解決問題。相反地，如果一開始就能定義清楚目標、限制、input/output、驗證方式、測試案例，以及哪些事情不應該做，AI 的產出就會穩定很多。
所以真正重要的能力，開始從「我會不會寫這段 code」，轉移到「我能不能把一個模糊的問題定義清楚」。
很多需求一開始其實都是模糊的。可能來自 PM，可能來自主管，可能來自客戶，也可能只是某個很粗略的方向。以前工程師可能會直接開始拆 task、寫 code，然後用產出的行數、完成的功能來證明自己的存在。
但在 AI coding agent 變強之後，這件事正在改變。
工程師更重要的價值，會變成能不能把模糊目標拆成具體的小目標；能不能定義清楚每個 task 的 input 和 output；能不能先想清楚結果應該長什麼樣子；能不能設計出合理的驗證方式；能不能判斷 AI 的產出到底是剛好夠用、過度設計，還是根本走錯方向。
在請 AI 做事之前，人應該先有計畫。
要做成什麼 >>> 要如何做
這也影響我對工程管理的看法。
當團隊的產出量因為 AI 而大幅增加，如果我還是試圖用傳統方式 review 每一行 code，理解每一個細節，那瓶頸一定會卡在我身上。這不是長期可行的方法。我不應該把自己定位成那個逐行看懂所有 code 的人，而是要設計一套讓產出可控、可驗證、可追蹤的流程。
不同類型的任務，也應該有不同程度的要求。
如果只是內部小工具、一次性的 script、低風險的輔助工具，也許可以比較放鬆，重點是快速解決問題。但如果是客戶案子，例如 CEER 這種正式交付，就不能只看「有沒有做出來」。這時候更重要的是規格是否清楚、驗證是否完整、邊界條件是否有處理、產出是否符合專案真正要的結果。
AI 讓工程師的產出變快，但也讓「定義問題」這件事變得更重要。
因為 AI 很會執行，但它不一定知道什麼才是對的。它可以根據你的描述往前衝，但如果方向一開始就錯了，它只會更快地把你帶到錯的地方。
所以，Claude Code 之後，工程師還剩下什麼？
我現在的答案是：工程師要更像一個定義目標、設計驗證、拆解問題、判斷取捨的人。
會寫 code 當然還是重要，因為你需要理解系統、判斷品質、看得出 AI 寫出來的東西哪裡有問題。但單純「會寫」這件事，已經不再是最稀缺的能力。
更稀缺的是，你能不能知道要做什麼、不做什麼，做到什麼程度才算完成，以及如何證明它真的完成了。
AI 時代的工程師，不應該只是更快地寫 code。
而是要更清楚地定義問題，更精準地使用工具，並且對結果負責。