AI 會放大輸出，但掩蓋不了驗證能力的缺失
AI 讓任何人都能產出看起來不錯的程式碼。我以為把它調教好了，就可以輕鬆完成任務了，結果漏掉了最關鍵的一件事。
帶同事用 AI 開發一段時間後，我以為只要把專案調整成更容易跟 AI 協作的形狀，就能順利完成需求了。
所以我把整個專案的開發細節寫成文件、優化 CLAUDE.md(AGENTS.md)、做成 Skill，再寫一份給工程師看的 prompt 指南，目標是不管誰來，都能產出至少 70～80 分的東西。
程式碼品質確實好了，但我沒預料到這樣還不夠。
輸出變好了，但是「驗證」沒有跟上
表單送出、流程看起來正常，但沒發現資料沒存進 DB。
瀏覽器 console 噴紅字、功能看起來沒壞，卻沒發現其實 api 少了欄位。
種種跡象讓我發現，AI 可以透過各種調教來產出品質穩定的程式碼，但沒辦法替人建立「這樣不對」的直覺。
「驗證」是 AI 暫時補不上的地方。
以前：能力不足 → 程式碼品質差 → code review 一眼看出來
現在：能力不足 → AI 補上程式碼品質 → 問題藏在「有沒有辦法判斷 AI 寫的東西對不對」
從公司的角度來看…
如果公司需要的只是「把需求做完」，AI 工具確實讓這件事的門檻降低很多。
產量提升了呀、開發效率變好了呀、交付速度變得很快呀。
表面上工作都很順利，但這不代表問題不存在，AI 的快速產出只是把真正的問題往後推。
想到這讓我產生了一個疑問：
當我們沒有能力檢驗自己的成果是否正確，我們要怎麼知道我們正在做對的事情？
AI 讓「做完」變容易了，但「做對」還是要靠人
以前看一個工程師的能力，看他寫的程式碼就大概知道了。
但是現在 AI 可以幫任何人寫出語法正確、結構看起來沒問題的東西。
我認為 AI 時代的工程師，還無法被取代的能力是：有沒有辦法判斷這段程式碼解決了沒有、有沒有看出副作用、有沒有做對。
這些確認的動作，才是工程師的工作核心。
下一步，是產品思維
以前「會不會寫程式」是門檻，現在這個門檻幾乎消失了。
但驗證的門檻沒有消失。能不能發現資料沒存進去、能不能看出 console 的錯誤代表什麼、能不能判斷 AI 給的東西有沒有解決問題，這些才是現在真正的差距所在。
AI 讓程式碼變得便宜，但驗證的工作量沒有跟著消失，只是原本分散在 QA、PM 身上的那些判斷，開始往工程師這邊靠。
所以工程師需要發展的，不只是「怎麼跟 AI 協作寫程式」，而是更靠近產品思維的那些技能：能不能從使用者的角度測試自己做的東西、能不能發現需求理解有偏差、能不能在 code review 之前就抓到問題。
這些以前是其他角色的工作，但在 AI 加速產出的世界裡，工程師如果沒有這些能力，就只是一個幫 AI 按確認的人。
之前也有寫過一篇〈公司需要的是工程師，還是只是把工作做完的人？〉，專門討論這個時代工程師應具備的自覺，有興趣可以一起看。