組織裡，開始有人用 AI 用得愈來愈深，不只是他們開始寫程式，而是做出來的東西，已經成為同事每天工作的一部分。其中兩個人的故事，似乎正呈現著AI時代「工程師」的意義。

一位是在非營利組織工作的技術小白，一位是使用者體驗設計師，兩個人在過去都不會是預期走向工程角色名單的一份子。但這段時間下來，一位用 Claude Code 做出一套現在同事每天在用的專案管理系統，另一位，把原本分散各處的行銷與產品資料整理起來，建立資料處理與分析的流程，產出大家每天在看的 Dashboard。

一切開始變得不一樣。當一套系統有人使用，就得考慮修改會不會影響別人；當一份分析每天有人看，就得確認資料的定義是否一致、結果能不能持續相信。原本只要先做出來的東西，開始需要維護、驗證，也需要隨著工作繼續調整。而我跟他們的互動，也是在這些卡點上，慢慢往工程的思考方式走。

從補充知識到引導工程思考方式

一開始，我幫他們補齊缺少的知識，哪個套件怎麼用、資料要怎麼存，遇到問題，就補上對應的做法。到後來很像我過去當TPM 或 RD manager 時在做的事：帶一個工程師從初階走向進階，除了教他怎麼完成眼前的功能，也會開始問：這樣做，之後好不好改？改了以後，怎麼知道原本的東西還能正常運作？現在解掉的問題，會不會在下一次又出現？這些問題，很難只靠聽過一遍就變成習慣。往往是實際遇到狀況，才開始理解為什麼需要那樣想。現在，只是換了一批對象。他們過去沒有工程背景，卻因為做出了真正有人使用的東西，開始面對相似的問題。

做專案管理系統的這位同事，遇到的卡點，大多跟長期維護有關。一個功能改了，會不會牽動別的地方？這次改版，要怎麼確認沒有破壞原本的功能？對熟悉開發的人來說，這些問題很自然會接到版本控制、測試，以及開發到上線之間的安排。但對他來說，一開始連這些詞彙都很陌生。所以，我沒有先把一套完整的工程課程搬出來，而是從他正在擔心的那個問題開始。先理解這次修改可能影響哪些地方，再談怎麼留下可以追溯的版本、怎麼確認修改前後的行為。讓他知道，工程裡為什麼會發展出這些做法，再回去實際調整自己的系統。這時候，版本控制和測試就有了可以掛上去的脈絡。它們是在回答一個他已經很在意的問題：怎麼繼續改進這套系統，同時讓正在使用的人，可以放心工作？

做資料工程與分析的這位同事，卡點則比較常出現在資料本身。來源不一致、格式不同，甚至同一個欄位，在不同系統裡代表的意思也不一樣。如果直接往下做分析，畫面可能已經做出來了，卻還不知道裡面的數字能不能放在一起比較。我跟他討論的起點，就是他正在處理的那批資料。先把來源和定義釐清，再看資料經過了哪些整理、轉換，最後才談分析的結果。接著，才慢慢往更結構化的方向走：這個資料流程可以怎麼拆？哪些處理會重複出現？分析邏輯要怎麼整理，才不用每次都重新做一次？當 Dashboard 成為大家每天會看的東西，背後的資料怎麼來、怎麼被處理，也就成為需要一起照顧的工作。

基礎還是要學，只是從有感的地方開始

如果按照傳統的學習路徑，可能會先從程式語言、資料結構，一路學到系統設計，再開始做一個完整的專案。但這兩位同事的順序不一樣。他們先透過 AI，把工作上需要的東西做出來，接著才在使用、維護和迭代的過程裡，遇到需要補上基礎的地方。這不代表基礎不重要。只是對當下的他們來說，眼前的問題，讓那些原本陌生的知識有了意義。 我要做的，是從他們卡住的地方，指出這跟工程的關聯，讓他們理解為什麼需要這些做法，再一步步補上能用來判斷的基礎。 有了這個脈絡，學習就比較容易回到工作裡。當相似的問題再次出現，也才有機會自己辨認，而不只是記得上一次用了哪個解法。

組織要長出 AI Builder，還需要有人陪著跨過這一段

和這兩位同事的互動，讓我重新思考工程角色，也讓我看見，AI Builder 的成長，不只發生在「能不能把東西做出來」的那一刻。兩位同事對自己的工作夠熟悉，也願意持續嘗試，才把系統和資料流程推進到有人使用的程度。而當東西真的進入日常工作，接下來要學的，就是怎麼讓它可靠地繼續運作。我過去帶工程師成長的經驗，剛好在這一段派上用場。從他們遇到的問題出發，陪著拆解，再把工程裡已經累積的思考與做法接進來。對組織來說，除了讓人有機會動手做，也需要有人能支持這段成長。做出第一個版本之後，還有很多判斷要慢慢建立。畢竟軟體工程是經過數十年的探討與累積。