剛開始，我也很焦慮。AI 發展實在太快了，才剛熟悉一個工具，下一個模型又出現；原本要花時間查資料、寫程式、反覆調整的工作，現在幾輪對話就有了像樣的結果。有些事情，它確實做得又快又好。
對工程師來說，這種衝擊很直接。我們花了很多時間累積技術，也習慣從解決問題的過程裡確認自己的能力。當自己長期擅長的事情突然變得容易，難免會想：那我累積的這些東西，還剩下多少價值？
後來讓我比較能面對這份焦慮的，是把自己的工作放回整個交付過程來看。當實作越來越容易，工程師更需要為「什麼值得交付，以及如何知道它做好了」負責。 從決定產品該做成什麼樣子，到確認它在使用者手上確實有用，這一路上的判斷，都會影響我們最後交出去的成果。
把實作交給 AI 之後，工程師仍然得先釐清產品現在最需要解決什麼、哪些資訊還不完整，以及哪些限制必須說清楚。等 AI 提出方案，還得判斷這個看起來合理的做法，放進眼前的產品到底合不合適。工具能做很多事，但我們如何提出問題、判斷答案，會影響它最後能幫上多少忙。
這種把工作交出去、仍然要對成果負責的方式，在 product manager 和 engineering manager 身上並不陌生。PM 不必親手實作每一個功能，EM 也不可能寫完團隊的每一行程式，但他們仍然需要理解問題、協調資源、做取捨。我們本來就知道，一個人的貢獻可以大於他親手完成的那一部分。使用 AI，讓更多工程師也必須練習把事情交出去，同時維持對方向與品質的判斷：需求要講清楚，也要知道什麼時候該追問、推翻方案，甚至停下來。
AI 本身的能力、可用的資料與工具，仍然會限制它能完成的工作，把需求講清楚也不保證任何事情都做得到。而在它做得到的範圍內，同一個功能往往有很多種實作方式，還需要有人決定該選哪一種。我把這部分理解為工程上的品味：知道產品現在需要什麼，也能判斷它值得承擔多少複雜度。
假設你正在做一個還沒找到穩定客群的 startup，最急迫的問題可能是確認有人願意使用、願意付費。這時候，先把多區域部署、微服務、容器編排與一整套平台工程搬進來，即使每個零件都有道理，也可能讓團隊在驗證需求以前，就先背上維運工作。AI 可以很快產生一份完整的架構，後續的雲端帳單和維護成本卻不會跟著消失。工程師需要判斷的，是這些投入現在值不值得。
AWS 或 GCP 當然可以從第一天就用，關鍵在於選了哪些服務、開了多少資源，以及團隊有沒有能力維護。AWS 自己給新創的架構指引，也把效能、擴充性、維護負擔與成本放在一起討論，並指出適合的架構會隨成長而改變。AWS：Choosing an Architecture，2022
今天適合的做法，可能是先把系統做簡單，保留日後調整的空間；等流量、客戶要求或團隊規模真的改變，再增加必要的能力。涉及權限、資料保護與備份的基本要求，則不能因為還在早期就略過。我說的品味，就包括願意少做一點、知道哪些地方不能省、能解釋為什麼現在接受某個限制，也願意在條件改變後修正決定。AI 可以提供選項，採取哪個做法、接受什麼代價，仍然需要有人負責。
決定要做什麼、做到什麼程度之後，接下來的責任就是確認它確實做好了。這也讓我開始留意，AI 加速的是交付過程中的哪一段。程式碼產生得更快時，我們很容易把這種速度當成整個團隊的效率，但理解、修改、驗證與交付所花的時間，並不會自動一起縮短。要知道 AI 究竟幫上多少忙，就得把這些工作一起算進去。
研究結果也提醒我們注意這個差別。2023 年發表的一項 Copilot 實驗，要求受試者完成 JavaScript HTTP server；在完成任務的人當中，使用 Copilot 組的平均耗時少了 55.8%。到了 METR 針對 2025 年初工具的研究，16 位熟悉自己開源專案的開發者處理 246 件真實任務，允許使用 AI 的條件反而讓耗時增加 19%。兩者的任務、工具與工作情境不同，不能拿來直接互相抵銷。Peng 等人的 Copilot 實驗、METR 2025 研究
工具持續進步，這些結果也需要放回各自的時間背景。METR 在 2026 年 2 月的後續更新中表示，新資料出現加速的跡象，但參與者與任務的選擇偏誤，以及多個 agent 並行時的計時問題，讓他們無法可靠估計效果。因此，19% 也不能直接當作今天使用 AI 的答案。對我而言，這些研究的意義，是提醒自己沿著交付流程往下看，確認實作省下的時間，有多少留了下來，又有多少花在後續的理解與修正上。METR 2026 年更新
而我現在最有感的瓶頸，是 PR review。當 AI 可以持續產生修改，人仍然需要理解它碰了什麼、為什麼這樣做，以及會不會影響其他地方。如果程式碼進來的速度持續超過團隊能消化的速度，工作就會堆在審查這一關，生成端的加速最後也可能變成另一端的等待與返工。只靠增加人工逐行閱讀，去承接不斷擴張的自動化產出，我覺得很難長期維持；除了把修改拆小、限制同時進行的工作，我們也需要讓更多檢查可以重複、自動地執行。
CodeRabbit 就提供了這樣一種做法。依照官方文件，它能提供 PR 摘要、程式碼問題與修改建議，結合儲存庫脈絡和靜態分析工具，並在後續 commit 進來時做增量審查。這些功能讓部分檢查可以交給工具處理，但流程有沒有因此改善，還得看實際結果。CodeRabbit 官方文件
對我而言，值得追蹤的是它找出的問題有多少需要處理、處理誤報花了多少時間，以及人是否因此能更專注於重要的設計與風險。CodeRabbit 自己也把產品定位為補充人工審查，因此增加機器留言的數量，並不足以說明審查變得更有效。CodeRabbit FAQ
公開研究也顯示，不能把採用工具直接等同於效率改善。一篇 2026 年 7 月的預印本分析了 207 個專案、約 102 萬個已審查 PR，發現部分 AI reviewer 採用方式與較快的審查決策相關，另一些沒有顯著改善。它量測的是依變更規模調整的決策時間，以及審查流程的風險指標；作者也明確說明，結果不能解讀成因果，更不是實際 bug 數的比較。Zhong 等人的程式碼審查研究
即使工具讓審查變快，仍然要回答一個問題：如果人沒有逐行讀過每一份修改，憑什麼相信交付的結果？寫一般應用程式時，我們通常不會在每次修改後，逐行閱讀編譯器產生的組合語言，而是把注意力放在能有效理解、控制與驗證的層次，需要追查底層問題時再往下看。我覺得 AI 開發也可能往類似的方向走，只是這個比喻還不能直接當成放心放行的理由。
編譯器依照程式語言的語義做轉換，AI 從自然語言需求產生實作，還牽涉到如何理解那些沒有講完整的意思。像 CompCert 這樣的編譯器，甚至對特定範圍的語義保留建立了形式證明；這種保證不能直接套到 AI 生成程式碼上。CompCert：A trustworthy compiler
因此，減少逐行人工檢查，必須伴隨更可靠的驗證依據。架構變更、權限邊界、資料遷移，或難以復原的操作，仍然值得人深入理解；要把多少工作交給自動化，應該取決於目前有哪些證據，以及出錯的後果。這也是我覺得現在仍是一段過渡期的原因：工具已經大幅改變程式碼的產生方式，我們卻還在學習怎麼承接這些產出。我猜審查的重心會逐漸往需求、系統行為與風險移動，並把更多可明確判定的檢查交給自動化，但這還不是所有專案都已具備的能力。
要往這個方向走，首先得把一個基本問題說清楚：我們到底要交付什麼？ 假設要做的是「讓使用者取消訂閱」，一個按鈕、一支 API、幾個通過的測試，還不足以把這件事定義完整。我們得先決定取消何時生效、已付款的使用權保留到什麼時候，以及畫面應該如何告知使用者，才有辦法判斷實作是否符合預期。
有了這些決定，接著才能驗證：使用者只能取消自己的訂閱；重複點擊不會造成重複操作；付款服務暫時失敗時，系統不會宣告取消成功；畫面、資料庫與付款端的狀態，最後能保持一致。這些情境讓「完成」有了具體意思，也讓人有機會在寫程式以前，就發現需求本身的矛盾。
軟體測試很早就有一個名字來描述這個難題：test oracle problem，也就是如何判定程式的行為是否正確。能自動產生輸入、執行測試，並不等於已經有可靠的預期答案；相關研究討論的方向，就包括規格、契約與其他可用來判定結果的資訊。Barr 等人：The Oracle Problem in Software Testing，2015
放到 AI 開發裡，如果實作和測試都沿用同一個錯誤理解，測試全綠也可能只是兩邊錯得很一致。驗收依據需要來自釐清過的需求、重要限制與實際案例，並接受獨立檢查；單純換另一個模型說「看起來沒問題」，不會自動補上缺失的標準。我會把確認這些標準，視為把更多實作交給 AI 之前必須做好的工作。
即使標準已經釐清，驗證也不該停在合併 PR。Google 的 SRE 實務指出，測試環境無法涵蓋所有正式環境的情況，因此可以先讓一小部分流量使用新版本，觀察結果，再決定擴大、暫停或回復。程式通過測試之後，真實使用情況仍然會提供新的證據，也可能迫使我們回頭調整實作。Google SRE：Canarying Releases
把這整段流程放在一起看，就很像在關心一間工廠的良率。假設一條產線突然能做得更快，我們會關心產量，也會追問成品是否符合規格、問題在哪一段出現，以及異常發生後製程有沒有跟著修正。NIST 對製程控制的說明，就是依照監控結果調整製程，其中同時包含人的工程判斷與自動控制。NIST：What is Process Control?
在軟體交付裡，需求和限制決定我們想做出什麼，測試與審查協助找出偏差，正式環境的資料則讓我們知道，交到使用者手上的東西實際表現如何。發現問題以後，要把案例放回驗證流程，調整規格、工具或工作方式，讓同一種錯誤更難再次通過。如此一來，每次交付的結果才有機會改善下一次的製作過程。
不過，軟體不能直接照搬工廠的良率數字。每個 PR 的規模與風險不同，一個邏輯錯誤也可能影響所有使用者；修改文案和修改付款邏輯，很難當成等值的兩件產品，算出一個平均通過率就安心。我想借用的，是持續觀察、驗證與修正的工作方式。至於做出來的功能到底有沒有人需要，還得回到使用者身上確認，因為符合規格的產品，也可能是一個沒人想要的產品。
這些工作讓我看見，即使 AI 承接了更多實作，工程師仍然能透過判斷影響成果。不過，知道自己的工作還有價值，不代表就能放下被取代的擔心。談到 AI 裁員，我的判斷是：往後更有機會留下來的，會是能夠思考、做出判斷，並對結果負責的工程師。 這裡的思考，包括在接到需求時確認問題是否值得解決，在 AI 提出方案時找出它省略的前提，在大家急著上線時辨識哪些風險不能接受。即使一個功能做得出來，卻無法幫助產品，也有能力說明為什麼應該停下來。
如果工程師能提供的，主要是把已經講清楚的規格翻成程式碼，那麼這部分工作就更容易與 AI 的能力重疊。我更想培養的，是處理那些還沒講清楚的事情：找出真正的限制，決定應該驗證什麼，並根據結果修正方向。親手實作、除錯與理解系統，仍然是累積這些判斷力的方式；把更多實作交給 AI，則讓我有機會把心力用在取捨與驗證上。
但工作市場不會只按個人能力分配結果。Anthropic 在 2026 年 3 月的一項美國勞動市場研究中，尚未發現高 AI 暴露職業的失業率出現系統性上升，卻觀察到年輕工作者進入這些職業的招募可能放慢。這是當時資料下的早期證據，還不能替任何人的工作保障下結論。Anthropic：Labor market impacts of AI，2026
我也不會把自己的判斷反過來解讀成「被裁員的人不會思考」。公司可能取消整個產品、團隊或業務方向，個人做得再好，也未必能改變那個決定。「人有品味」無法保證工作永遠不會改變，經驗的價值終究要看它有沒有幫助團隊做出更好的決定。我仍然相信，持續培養思考與判斷的能力，會讓工程師更有機會被需要。
回頭看，我的焦慮並沒有完全消失，但現在比較知道該把力氣放在哪裡了：理解問題，把限制講清楚，選擇適合當下的做法，建立可信的驗證，並對交付之後的結果保持關心。當產出變得容易，我想練習的是，更清楚地知道什麼值得做，以及拿得出證據說明，它確實做好了。
資料查核至 2026 年 9 月 5 日。文中的新創與訂閱功能是說明用的假設情境；對工作方式與未來方向的判斷，屬於個人觀點。