這篇文章，是我開始放下「如果我不用AI，我還能自己寫出來嗎？」的擔憂，轉而接受「程式碼本來就應該要由AI撰寫」的思考紀錄。我想思考的是，這個時代，身為軟體工程師的我還有什麼價值？
從刻意練習到 AI 協作：程式開發的範式轉移
身為軟體工程師，在工作中大量使用AI已經是常態，從最早的ChatGPT介面，一直到現在的Claude Code、Codex、Copilot，隨著工具的效能不斷提升，我從來沒有停止擔憂過。
熟悉刻意練習這個概念的人都知道，唯有夠過自己親手實作、克服困難，大腦才能把這項技能真正學會，也就是基於這個觀念，我一直認為手寫程式碼是必要的，使用AI是時間窘迫下的解法。對於在工作中用AI產出的程式碼，總有種心虛的感覺，覺得自己沒有能力寫出這些程式碼是一個很大的問題。
以上這個論點是對的，但有一個隱藏的前提——實作程式碼仍然會是軟體工程師的主要價值來源。試想過去熟練組合語言的工程師，也是經歷刻意練習才習得的，但我卻從來沒有因為不熟組合語言而感到心虛，因為這已不是軟體工程師的必要技能了。也許在未來的程式設計師，程式就像是組合語言一樣，本來就是應該交給工具去處理的。
放棄對程式碼的堅持後，尋找其他產出價值的管道
一個有趣的現象，正當AI已經可以完全幫我實作程式碼時，我更有機會看出軟體工程師實際的價值是什麼。
一、對公司業務流程和既有軟體系統的理解
這就是大家常說的domain knowledge & vertical knowledge。
我觀察公司的資深工程師，已經不再寫程式碼，每天主要做的事情是和PM談需求、判斷商業需求能不能被現有系統支援、並把規格設計出來，至於實作——就交給資淺工程師或是AI做。
他們的角色更像是顧問，關鍵工作產出是「設計決策」，把商業需求翻譯成能被軟體支援的設計。
既然AI已經能夠做掉資淺工程師的工作，其實我是受益的，在實作的時間被釋放出來後，更有機會花時間在業務流程的理解和設計上，參與以前資深工程師或是PM的討論，成為另一種可能貢獻價值的方式。
二、花更多時間在使用者上
以前受限於時程，總要使用者忍受一些卡頓、無法優化的介面和流程等等。而現在的軟體有了更高的要求，就是花更多時間在UI/UX與使用者體驗、需求分析上，做出使用者真正要的體驗。
三、軟體工程的設計面——系統設計、軟體設計準則
作為組內最資淺的軟體工程師，以下都是我切身之痛所犯的錯。
我發現就算我配備最強的模型，寫出來的程式仍然有許多面向可以改進，所以我總結出這些面向是最不容易被AI取代的：
API 介面設計
前端、或是其他服務會怎麼用這些API？我要怎麼設計讓他們方便使用和擴展？實作有百百種，AI每種方法都做得出來，但是需求方到底要什麼、這個情境的權衡適合什麼，卻只有經驗才能做出判斷。
軟體架構設計
這次遇到要實作一個新服務，資深工程師指出適合用Microkernel architecture去實作，可以讓後續擴充以plugins的形式加入。如果沒有他的經驗，我根本不會想到要這樣架構軟體，只會要求AI寫出一個符合功能的軟體。
對於限制、原則與取捨要有「明確而堅定」的看法
我發現自己在不了解軟體的重要原則下，很容易被AI帶歪走偏。AI傾向給出一個「可以的寫法」，但卻忽略實務的考量，舉一些例子：
- 過多的Logging，卻沒有想到後續系統上線，Debug排查時會被Noisy logging淹沒。有經驗的工程師指出，只應該在最容易出錯的關鍵邏輯分支處做Logging
- 違反SOLID原則，像是寫出一個巨大的switch-case，沒有想到擴充性的問題，像是改採Strategy pattern
- 過多的Magic string在程式碼中，沒有獨立成Constant，沒有顧慮後續維護會很困難
這些例子都還算好處理，可以在Claude.md加上就好。但像是更抽象的決策，像是redis要存什麼以支援某功能、整體系統設計等等，如果完全沒有經驗，會覺得「每一種做法感覺都不錯」，所以系統設計、軟體設計準則的學習仍然沒有因為AI時代而褪色。
四、重新定義學習的重點
以前學程式，注重「技能面」，現在轉向更多「概念面」。
像是DP的遞迴式概念只要用數學證明過就懂了，但需要反覆刷題，花很多時間熟悉語言的API、語法，才能寫出各種背包問題，這就是概念和技能訓練之間的鴻溝。
但是這個鴻溝正在縮小中，當技能面可以交給AI去處理，人類反而需要花時間的部分，是在把概念清楚的描述，知道在什麼時候用上。
所以現在學習的目標，可能更側重是否「能用自然語言清楚描述」，啊，其實不用講這麼拗口，不就是能夠寫出文章嗎！
然而概念的理解，不應該是一種折扣過後的理解。我在寫文章時，仍會要求自己手寫第一版草稿，因爲唯有手寫，才能重新思考自己要講什麼，而這是書寫仍然是不可被外包的部分。只有在釐清自己的架構和論述後，才會給AI潤飾、加上例子，讓讀者更容易理解。
這是AI時代，我正在嘗試並覺得可行的學習方法。
五、寫程式的工作流程改變
儘管改用AI寫程式後，要順利的合作，仍有許多技能需要培養。
版本控管
AI常常大幅動修改codebase，版本控管變成很重要的技能，讓AI的產出可以被控制。
審核
這邊說的審核包含兩個部分：Code Review 和測試。
審核的關鍵在於，工程師要清楚理解軟體預期的行為是什麼，才能夠想出測試情境(為什麼要寫測試？)。審核的能力依然很重要，因為AI很容易連測試碼都一起改，就像是裁判兼球員的感覺。
在審核時，是逼迫自己花時間從程式碼的意圖思考，像是問自己：當初要這個function的原因是要處理什麼？這樣寫容易理解嗎？有達到他的目的嗎？用這個觀點來評估AI的產出，而更少花在實作細節上。
值得的投資：花幾週的時間去重構自己的AI工作流
探索Skills、MCP Server等等agent功能，變成和寫程式同等重要的工作。像是我同事，花很多時間在寫出更好的Skill，反而不是在寫程式，這點對我而言很有啟發。
新的軟體工程師樣貌
我想像自己是工業革命初期的手工業者，過去依賴手藝維生，直到機器出現後，純粹的手工技能不再是核心價值，而需要重新定位。
現在的軟體工程師面對 AI 的處境也類似，程式碼實作技能的重要性下降，但這也是重新定位自己價值的機會。我想像中的軟體工程師，在未來的工作模式會有以下的型態改變。
- 花更多時間在溝通
- 花更多時間學習垂直整合的知識，更像是Product Owner的角色
- 專注在概念理解、給出堅定的原則、權衡、約束去提高AI的產出品質
- 花更多時間在思考工程抉擇帶給使用者的價值
- e.g. SOLID & Clean code 是為了更快更好的做出並交付功能
- e.g. 設計好用的API介面和軟體架構，是為了未來能夠讓PM更自由的去擴展功能