當 AI 已經會寫 Code，工程師的價值在哪？
程式碼只是手段，工程師的價值最後還是看產出有沒有真的解決問題。如何取捨？怎麼驗收？後果誰扛？這才是核心。
從需求到實作的過程裡，每一次交棒都可能漏掉資訊，也可能因為不了解背景與領域知識，把上一棒的意思翻錯。 當團隊變大後，甚至加入 AI 的協作之後，這件事會更明顯。
從需求到實作就像一場接力賽，資訊在每一次交棒中都可能失真。過去我們能靠小團隊的「默契」來彌補上下文，但在團隊擴張、甚至引入 AI 協作後，這種隱性信任已經撐不住了，我們只能將信任轉移到規格、介面與測試紀錄上。
AI Coding agent 大幅壓低了「實作」這段的成本，但它無法修補源頭錯誤的問題定義，也無法保證最終交付的價值。 當實作變得飛快，測試、部署與決策卻還在排隊時，工程師的戰場就轉移了，我們更該把力氣花在守住那些 AI 無法代勞的轉換點上。
以前很在意的東西，似乎正在貶值
記得 API 細節、熟悉特定框架的邊角行為、從文件和 Stack Overflow 拼出一個可用解法、快速寫完 CRUD 與各種樣板程式，這些能力的價值正在下降。 它們沒有突然變得毫無用處。當驗證證據不夠、除錯陷入僵局，或事故需要人接手時，讀懂程式碼的基本功仍然重要，只是它們很難再單獨構成工程師的護城河。
這件事對我並不抽象。我也曾經花很多時間，把「我知道得比別人多」當成專業的一部分。記得一個冷門設定、遇過某個框架的坑、能比別人早幾分鐘找到答案，都會帶來一點資深工程師的安全感。 如今 agent 幾秒就能翻完文件、找出相關程式碼，還順手送上一版修改。那份安全感當然會鬆動。
這種鬆動也不是第一次發生。Compiler 出現後，手寫組合語言的稀有性就沒了；ORM 之後，很多人賴以維生的 SQL 手藝變成偶爾才打開的工具；雲端把插網路線、裝機器那套本事收進了控制台。 每次抽象層往上抬一階，受傷的往往是把自我認同綁在那一層的人。
最近在社群上常看到一種說法：如果對 AI 的變化有學習焦慮，放著別管就好，因為再過兩三個月之後就會發現已經不用學了。 AI 跑得太快，那些半年、一年前很紅的工具與工作流，現在可能已經沒人提了。
我在上一篇〈看 Code 與不看 Code？在 Vibe Engineering 時代的難題〉裡，談的是面對 agent 產出的大量程式碼，人類該把注意力放在哪裡。
這篇想接著問的是：當熟悉度與產出速度都被 AI 超車之後，工程師還剩下什麼？
過去的徵才標準，現在不一定還能一體適用
這也是我最近在面試新人時最猶豫的地方。 過去的舊題目當初有它的用途，只是它們的鑑別力變了。能默寫 API，過去可能代表一個人真的用過很多次；現在也可能只代表他剛好為面試背過。 白板上手刻演算法，可以看到候選人怎麼拆問題，卻很難預測他回到工作現場、身邊有文件與 agent 時，能不能把一個模糊需求安全地送進 production。
我不會因此把基礎題全部丟掉。有些職位真的需要對效能、記憶體、安全邊界或底層行為非常熟悉，這時基本功依舊重要。
剛入門的工程師也需要足夠的基礎，才讀得懂 agent 交出來的東西。 工具已經改變日常工作，面試卻假裝候選人進公司後會永遠關掉工具，這樣量到的能力離真實工作越來越遠。
現在的我會更想看一個人怎麼面對不完整的資訊，以及怎麼把技術工作連回它要產生的結果。 會先停下來確認問題與受影響的人，在幾個可行方案之間說清楚自己為什麼選這個，再找出足以支持判斷的證據。 AI agent 可以一起出現在過程裡，因為我想看的正是他如何使用工具，以及察覺什麼情況不該再交給工具。
當然，這只是我自己的觀察標準，稱不上什麼正確的答案。 我也還在摸索怎麼把這些能力問清楚，並避免讓面試變成「猜面試官腦中的風險清單」。 但至少我確定，熟悉哪個框架已經很難單獨回答一個人能不能把事情做好。
我會開始懷疑這些標準，是因為日常工作的重心先變了。實作成本一降，拉開差距的地方就往方向與結果那邊跑。
實作變便宜以後，我反而更常懷疑方向
我很喜歡 AI 把實作變便宜這件事。以前一個想法要花兩天才能驗證，現在下午就能看到結果；以前因為成本太高而捨不得做的 prototype、spike 或單次丟棄式實驗，現在都已經不是問題了。
只是我也慢慢發現，以前實作昂貴，會自然逼人停下來想一下。要花兩週的功能，通常會先問需求、畫流程、確認誰真的需要它。 現在 AI agent 十分鐘就能開工，那道由痛感形成的閘門消失了。
但是，我只要有一句話沒講清楚，它也能很勤奮地往錯的方向蓋出三層樓。
看著終端機持續輸出、PR 一張接一張送出、看板上的卡片不斷往右移，這些東西都看得見，很容易讓人覺得工作正在前進。 至於使用者的問題有沒有變小、需求是否理解正確，通常要更晚才會知道。
走得快當然有價值。單次走錯的代價有時是變小了，以前賠掉兩週，現在也許只浪費一個下午。 便宜的 prototype 可以讓錯誤更早曝光，試完一條路後也更容易乾脆地換方向。
但是麻煩發生在回饋還沒回來，產出卻已經進了 production、開始保存資料，或被其他人當成穩定介面依賴。 這時速度沒有縮短試錯，錯誤反而更快長進系統裡。
有些界線一旦跨過，方向就很難拉回來。
資料庫 migration 已經改寫資料、API 已經公開、其他團隊已經接上來，使用者也開始依照新流程工作。
程式碼或許可以 git revert，這些已經發生的改變卻不會跟著回到原點。 團隊最後可能明知方向有問題，仍被自己前幾天的速度綁住，只能繼續替錯誤的選擇支付維護成本。
所以我現在理解的「走得對」，不要求動工前就把所有答案想清楚，那大概也做不到。
更實際的做法，是先知道這次想驗證什麼、哪些證據代表方向有問題，以及發現走錯時能不能及時回頭。工程師要做的，是讓 agent 的每一次加速更早接到真實回饋，必要時再把它停下來。
AI 讓動手的成本降下來了，想清楚的成本沒有。 這種落差我自己也踩過，它很像同時帶了好幾組施工隊，每一隊都在等我回答問題。
看起來我升級成監工了，實際上整天都在替大家補一句沒講清楚的需求，最後連整棟房子的樣子都快忘了。
工程師的角色，是讓產出真的帶來價值
我們到底要解決什麼？哪些限制是真的，哪些只是過去留下來的習慣？時程、成本、風險與團隊能力互相衝突時，哪一種代價可以接受？ 接著還得證明結果可信，並確認上線後真的出事時，誰知道影響範圍、誰能把系統救回來。
這些問題的終點不在技術本身。使用者可能只是少等一天、少走一段冤枉路，接手的人打開專案時不必再花兩個禮拜重新考古。 功能準時上線只是讓價值開始接受檢驗，這些改變有沒有真的發生，才是產出最後留下的東西。
我想起 DevOps Taiwan 社群常掛在嘴邊的一句話是「交付價值、持續改善」。 這裡的交付一路延伸到使用者真的得到結果；持續改善則把回饋帶回下一個小批次，讓價值不必靠一次猜對。
這些問題，AI 都可以參與。它能整理訪談、找出規格矛盾、列出方案、補測試，甚至提醒我沒想到的風險。我現在也會把這些工作交給它。
可是做決定的時候，仍然有一部分脈絡不在 prompt 裡。可能是某位同事下個月就要離職，可能是客服已經被某類客訴淹沒，也可能是公司此刻根本養不起最理想的架構。 模型可以提供一個合理答案，工程師得判斷這個答案放在眼前的團隊裡是否合理。
於是我的位置慢慢挪到了另一邊：要對結果負責的那一邊。
每個決定不必由我憑空想出來，agent 給的方案有時比我的第一個念頭更完整。 我的工作是把目標與邊界說清楚，辨認選項背後各自的代價，決定團隊願意承擔哪一種結果，最後確認預期的價值有沒有發生。 實作可以授權，決定權要跟責任放在同一個地方。
當 agent 開始動手，我的角色又往驗證環境移了一步。比起逐行盯著它有沒有照我的習慣寫，我更需要先準備可檢查的規格與有判斷力的測試，讓執行結果看得見，失敗時也救得回來。 只有在這些證據越強，我可以放手的範圍才可能越大；一旦 agent 動到驗證規則、改出原本授權的邊界，或拿不出與宣稱相符的結果，我就得把授權收回來。
這份責任也不能只靠我守在最後一道關卡。有些判斷能交給規格、測試、觀測與回復機制，就該提早放進交付流程，不必每次都排隊等人肉驗收。
還有一個常被「從寫 code 升級成管理 AI」這句話輕輕帶過的角色：維持對系統的理解。 如果我只會分派任務、看綠燈，系統會在每次快速交付之後離我更遠，最後連工具卡住時該從哪一層接手都講不出來。
更現實的是，agent 不會 on-call，不會在事故檢討裡解釋當初為什麼這樣選，也不會在幾年後收到通知，才發現某個當初覺得「先這樣就好」的欄位已經成為整間公司的命脈。
畢竟最後要向使用者與團隊解釋上線結果的人還是我們。
以前我比較容易把工程師的價值想成「我能做出多少東西」，現在我會把程式碼往後放一點。 它還是重要，只是逐漸從作品本身，變成創造價值時使用的一種材料。
「理解系統」這件事，我的看法也跟著變了。平常功能順順跑時，懂不懂底下的實作好像沒有差別。 如果沒有人知道資料怎麼流、模組為什麼這樣切、哪些假設不能碰，先前省下來的閱讀時間就會變成認知負債。
然後在未來的某一天連本帶利要你償還，不定時炸彈誰接到誰倒楣。
最擔心的，其實是自己有沒有繼續長出判斷力
AI 寫 code 這件事，最常被討論的是它會取代多少工作；對我來說，另一個更貼身的問題是：如果它也接走了大量練習，我們以後靠什麼長出判斷力？
我觀察到一個有點矛盾的畫面。缺乏程式背景的人第一次透過 Vibe Coding 做出成果時，很容易把「目前跑得動」當成主要的信任依據。 畫面正常、按鈕能按、資料看起來有存進去，系統似乎就已經完成了。程式碼背後的資安、資料完整性與維護風險不會立刻浮上畫面，他也未必有其他方法可以驗收。 這未必出於草率，很多時候，那就是他手上唯一看得懂的證據。
另一端，有些經驗較深的工程師反而更難放手。他們見過太多「現在能跑，半年後出事」的例子，知道綠燈底下仍可能藏著錯誤的系統假設。 這份保留有時守住了安全邊界，有時也可能只是過去的工作習慣還沒跟上工具。
我沒有資料可以證明資歷愈深就愈不信任 AI，這只是目前看到的現象。 被 AI 雷過一次的初學者可能比誰都保守；熟悉 coding agents 的資深工程師也可能最敢授權，因為前面那些驗證與界線他早就準備好了。
比起資歷，現在我更在意的是人有沒有能力校準信任。
我回頭看自己的經驗，很多判斷並不是看書學來的。它們來自寫錯、被 review、硬著頭皮修好，然後過半年又被自己當初的決定咬一次。 這條路很慢，偶爾也很蠢，卻會讓人記得某些代價為什麼不能省。
假如我剛入行時就有現在的 coding agent，我一定會比之前交付得快很多。 但那個「比較快的我」，會不會也少碰過一些牆？
到了需要獨立判斷的那天，他能不能說清楚 agent 為什麼這樣寫、哪裡最可能壞，以及燈號全綠時還漏了什麼？
AI 同樣可以是很有耐心的老師。
它不會嫌問題太基礎，可以陪著追一個錯誤追到凌晨，也願意把同一個觀念換五種方式再講一次。 差別可能在於，我們用它來跳過理解，還是用它逼自己把理解補起來。
這個問題也落在我身上，資歷增加以後，我很容易用經驗替自己的直覺背書，覺得「這種東西我自己寫比較快」，或看到 agent 的方案就先皺眉。 某些時候那份警戒救了我，另一些時候只是舊習慣不肯退位。
現在我得學的，是校準自己在什麼地方可以放手，什麼地方必須親自追到底。
目前我還沒有找到一套完整的方法論，只能說，在做完一個任務後，回頭看它省了多少時間、重做幾次、留下多少缺陷、哪些部分我能解釋，以及哪個瞬間最後仍需要人介入。 感覺自己變快並不夠，我需要一些證據確認，那份速度沒有拿理解去交換，產出是不是內化變成自己的東西。
至於團隊五年後要怎麼長出下一批 senior，我現在也沒有答案。 過去 junior 寫下不成熟的程式碼，senior 在 review 裡修正它，功能與未來的 senior 會一起被生產出來。 現在功能可以直接生成，那條學習的副產線也可能跟著停掉。
保留練習會犧牲短期速度，完全不保留又可能讓團隊慢慢失去接手高風險問題的人。 這大概會是接下來幾年，每個工程團隊都得自己付學費做的實驗。
又或者 AI 會繼續成長到我不需要擔心這個問題也不一定，就只好繼續看著發展走下去。
怎麼看待「被 AI 取代」的焦慮
「我會不會被 AI 取代？」這句話裡，其實疊著幾種不同的擔心。
有些任務會被自動化，這已經發生在我每天的工作裡；熟悉的技能跟著降價，多學一套工具也蓋不掉那種感覺。至於工程師這個角色會不會整個消失，現在的我沒有證據可以回答。
這份焦慮也來自過去相信的專業標準開始鬆動。我在上一篇文章裡提到，連提倡 Clean Code 多年的 Uncle Bob，都開始刻意不讀 coding agents 產出的實作。他沒有放棄品質。原本放在逐行閱讀上的信任，被移到單元測試、驗收規格、QA 與 mutation testing 組成的關卡裡。
如果連「把程式碼寫乾淨、逐行讀懂」都不再是每次開發的固定答案，那未來的標準又在哪裡？ 以前我可以從 code 看見一個人的能力與手藝，現在實作可能由 agent 完成，連驗證也有一部分可以自動化。 只看最後有沒有跑起來太薄，只看程式碼漂不漂亮又離真正要解決的問題太遠。我現在的做法是先問這份產出改變了什麼，再看有什麼證據撐得住這個結果。
Clean code 不會因此過期，它能降低維護成本、幫助團隊接手；測試與觀測性則讓錯誤更早現形。 工程師的判斷則決定了有限的資源要花在哪個問題上。標準沒有消失，只是從程式碼一路往外擴大。
把它們混在一起時，焦慮會變成一團沒有出口的霧。拆開以後就各有各的做法：任務被接走，我得往更完整的問題移動；技能在折舊，我得重新安排練習；產業會往哪裡走，那超出任何一個工程師能控制的範圍。
當公司發現同樣的功能可以用更少的人完成，職缺、分工與薪資都可能跟著改變。即使個人再努力，也拿不到免於組織調整的護身符。 我不想用「AI 只是工具」安慰自己，那句話沒有回答工具讓誰的工作消失，也沒有回答入門機會減少後，下一代工程師要在哪裡累積經驗。
但我也不想把每天的選擇都交給最壞的預言。
如果我只因為害怕被淘汰，就追著每個新模型、新框架與新工作流跑，最後可能收集了一大串很快過期的操作方式，卻沒有接住任何一個真正會發生的問題。 焦慮提醒我重新定價自己的能力，無法替我決定今天該學什麼。
回到那句「兩三個月後就不用學了」的玩笑，我到現在還是同意一半。
技術或者工具真的可以放著。某個 agent 新增了什麼模式、哪套 prompt 又成為本週最佳實踐，我不需要每一項都追。 等需求真的出現，再花一點時間補上通常來得及。把精神耗在工具更新的跑馬燈上，對職涯的幫助可能還比不上好好睡一覺。
但能力放著不會自己長。拆開一團模糊需求、看懂別人的系統、在幾個都不完美的方案裡選一個、設計真的能抓到錯誤的驗證方式、事故發生時保持冷靜，這些東西不會因為模型升級就自動安裝到我身上。
《蜘蛛人：返校日》裡，Tony Stark 把戰衣收回去的時候，講過一句我一直記得的話。
「如果你沒了這套衣服就什麼都不是，那你更不應該擁有它。」（If you're nothing without this suit, then you shouldn't have it.）
《蜘蛛人：返校日》
這句話很容易被拿去嗆人，說某某某只會用 agent。 我倒覺得它更適合拿來問自己：戰衣我會繼續穿，agent 也會繼續用，只是當裝備被脫下來之後還剩下什麼？
我目前能做的，是停止拿程式碼產量跟 agent 比，也沒必要。這條路仍然需要會寫 code，但「會寫」現在只能算起點。
最後還是要問：產出改變了什麼
寫到這裡，我沒有得到一份可以安心照著走的新能力清單，只是把評估工作的順序調整了一次。 以前功能上線、測試通過，我很容易把它視為完成；現在我會再往外看一層，確認問題有沒有真的變小，這份方便又讓我們背上多少長期成本。
上一篇文章最後，我寫過一句話：一個連藍圖都看不懂、只會看進度燈號的監工，不會自動變成建築師。現在回頭看，懂藍圖、會驗收也還不夠。 建築師還得知道房子為誰而蓋，住進去的人需要什麼，以及這棟房子值不值得被長久維護。
AI 可以幫我們畫得更快、蓋得更快，甚至比我們更早發現某些錯誤。 它讓很多原本做不起的事現在做得起來，也讓「做出來」這件事愈來愈難單獨證明工程師的價值。
程式碼可以由人寫，也可以由 agent 生成，我更願意用產出在真實世界留下的改變衡量自己。 當那些改變真的發生了，這份工作才算有價值。