AI 寫完後工程師的工作才開始
AI 會不會取代工程師？
這個問題我被問了大概第三十次的時候，終於想通它的前提就是錯的。
它假設工程師的工作 = 寫程式。
但做了這些年，真正在寫扣的時間，大概只佔一天的兩三成。
剩下的時間在做什麼？
在拆解 PM 丟過來的需求，「他說的通知功能，到底是通知誰？什麼時候通知？通知太多會不會被關掉？」
在跟 PM 開會，釐清需求是被驗證過的事實還是會議室裡的感覺。
在筆記本上畫流程圖、看需求文件裡沒寫的東西，
那些沒被提到的邊界，通常就是之後會出事的地方。
這不是 AI 時代的新現象。工程師從來就不是只在寫程式。
最近我用 Vibe Coding 做了一個自己的小產品，這個感覺更明顯了。
AI 把寫扣的速度拉快後，工程師有更多時間面對那個最難的部分，
決定什麼該做，什麼不該做。
AI 加速的是最小的那一塊
AI 確實讓開發這件事變快了。真的快很多。
以前一個功能可能要花半天寫，現在可能 10 分鐘就有個能跑的版本。這個進步是實實在在的。
但在做 Course Kit 的時候，我發現一件事：寫出來是最快的部分，決定要不要寫才是最花時間的。
比如通知功能。AI 可以幫我寫出來，10 分鐘搞定。
但「這個 app 需不需在第一階段，就要通知功能？」這個決定，我在思考漂流的時候，來回好幾次。
加通知功能聽起來很合理，但那是事實還是感覺？
有沒有數據參考，使用者真的會因為沒有通知而漏掉課？還是我只是覺得他們會？
加了通知，使用者會不會覺得被打擾？不加通知，他們會不會忘記來上課？有沒有比通知更輕的做法？
這就是想的真面目。不是坐在那裡放空，是不斷在腦袋裡跑「如果...就...但如果...呢？」的迴圈。
加一個功能很容易，決定值不值得加，才是最花時間的事。
AI 可以根據你產品背景、開發狀況，建議方案，選了方案把想法變成程式碼，
但這個想法值不值得變成程式碼，還是得自己決定。
說到底，工程師的核心能力就是分辨事實和感覺。
這個需求是使用者在反映的問題，還是會議室裡大家覺得應該要有的？
這件事 AI 做不到。它分不出來哪個是被驗證過的，哪個是大家覺得的。
同樣要小心但方向完全不同
而且事實在不同產業裡，長得完全不同。
過去在 Fintech，也參與過醫療量測的 IoT 專案。
兩個產業都需要非常小心地處理資料。但小心的意思，差很多。
在 Fintech，怕的是錢算錯。每一筆交易紀錄都要留下來，能追溯、能稽核。
掉了一筆資料，可能就是一筆對不上的帳。
在醫療 IoT，怕的是數據影響判讀。量測延遲了三秒，可能不只是慢一點，
而是整組數據不能用。病人的資料存在哪裡、怎麼傳、誰能看，每一個環節都有不同的規範要顧。
同樣是處理資料，做出來的東西可能完全相反。
這種知道在這個情境下要小心什麼的能力，不是讀文件學來的。
是在那個環境裡待過、踩過、想過，才慢慢長出來的。
AI 可以幫你寫程式，幫你推論產業與情境適用的選項。
但你的判斷力來自你走過的路，不是來自你會寫什麼語言。
AI 寫完之後，工程師的工作才真正開始
用 Vibe Coding 做產品，最常出現的狀況是：AI 寫出來的東西，看起來能跑。
打開來功能正常，畫面也對。有一瞬間覺得「哇，好像完成了」。
但直覺會告訴你：能跑，不代表跑得對。
這段邏輯在資料量大的時候撐不撐得住？
這個寫法有沒有留下安全隱患？
如果使用者用一個你沒想到的方式操作，會不會爆掉？
這就是前面說的看需求文件裡沒寫的東西同樣的思考方式，只是現在用在 AI 產出的 code 上面。
要找到沒被考慮到的情境，丟回去跟 AI 討論還有什麼我沒想到的。（這件事它倒是蠻擅長的，畢竟幻想是它的強項）(笑)
AI 就像一個打字很快的隊友。它的產出你不會照單全收，你會 review 沒問題再 commit。
這不是不信任 AI，這就是工程師本來就在做的事 code review。
AI 幫你把東西寫出來了，但決定這個東西能不能上線的，還是你。
所以，AI 會不會取代工程師？
我覺得比較好的問法是：你這些年累積的判斷力，現在終於可以不被打字速度拖慢了。
寫扣從來就只是工程師工作的一小部分。
AI 把這一小部分變快了，剩下的那些真正需要去拆解、去判斷、去決定的事，一件都沒少。
如果覺得寫程式只是我工作的一小部分，那恭喜，你早就準備好了。
如果你也在想怎麼用 Vibe Coding 做自己的東西，歡迎來聊聊。
