幾天前就看到這篇了 (文長)，不過一直忙到現在才有空寫一下我的想法。技術革新的過程中，角色變換本來就是必然的 (不然算什麼 “革新” 呢?)，差別在於你準備好轉換了沒而已。
這趁子，跟同事朋友們陸續聊了幾個相關的話題，趁這機會寫一下…
#1, 以後都 AI coding 了, 工程師還需要存在嗎?
別傻了, 當然需要, 而且只會越來越多。不過軟體工程師必然也不會只做現在的事情。顯而易見的，單純把設計好的規格變成 code 這件事的比例越來越低，因此所有人的技能必然會轉移 (就文內提到的架構師，系統分析師，產品經理等等)。
我從另一個觀點來看這件事。這陣子 (包含這週的直播) 我聊的話題都是 “開發 AI APPs”, 跟現在大家在聊的 “用 AI 來輔助開發” 是兩個完全獨立不相衝突的路線。當所有的 developer 都受惠於 Cursor, GitHub Copilot 這類 AI 強化的開發工具時, 會有各行各業的人也都需要該領域的 AI 強化工具才對。誰能替這些領域的人開發這樣的軟體? 就是軟體工程師啊。不過，這需要工程師對 LLM 運作方式掌握更到位才辦的到。
現階段，你如果搞不懂 LLM 背後怎麼跟 APP 整合再一起運作的話，我相信給你 Cursor 你也搞不定吧，這就是個例子，軟體工程師還是有存在的價值，Cursor 沒有人的配合，應該也沒辦法自己生出一套更強大的 Cursor 吧。因此，前幾天的直播，我都把重心放在 “學會怎麼跟 LLM 合作，把它應用在你的 APP 身上” 這主軸上。
看懂這發展趨勢之後，我打從心底覺得，過去 (我唸書時那年代) 老師講的: 演算法 + 資料結構 = 程式，放到現在來看，AI 應用程式 = AI 應用方式 + AI 資料處理方式 的組合了。學會 AI 解題的基本技巧，跟資料處理 ( RAG，向量檢索等等都算 ) 算是跨入這領域的基本功。
所以，我才會展開幾種 AI APP 的設計模式，Json Mode，Function Calling，RAG 等等題目都屬於這種。這現在還是個藍海，未來勢必有很大的發展空間。你如果要加速進入這個領域，自己先學會好好運用這些 AI 輔助工具是必要的。市場上大家也都在摸索，你沒有太多案例可以依循，自己學會運用 AI 讓你加速了解這領域也是一樣重要…
#2, 現在的軟體工程 ( ex: SOLID ) 觀念還重要嗎?
這是跟同事閒聊的時候談的話題。會談這題的起因是: 如果現在 AI coding 的能力都那麼強大了，程式碼的 “可維護性” 還重要嗎? 可維護性很重要的起因，是因為要讓 “人” 來維護程式碼更容易一點，因為人腦思考速度跟範圍有限，才會發展出這一連串的軟體工程技巧，最大化的讓人腦能夠好好維護這些高複雜度的程式碼… 以後如果都靠 AI，那這動機是否還存在，是否還必要?
我的答案是: 一樣重要，但是應用的領域也會轉移。理由很簡單，目前 AI 管理程式碼的能力還不夠好，受限於意圖的理解能力，還有 context window 大小的限制，高度複雜的問題，人的理解能力還是更勝一籌。但是沒有什麼相依性的小型專案，如果你真的已經能靠變更需求文件，剩下的都能穩定的操作這些工具來 “無腦” (無人腦) 修正維護程式碼的化，SOLID 就沒那麼重要了。
相同的程式碼重複 10 次會怎樣? 如果你跟 AI 變更需求，他也能準確的一次改完這 10 份程式碼，那就沒問題了啊，這是前提，必要的先決條件。
因此，跨出這範圍，SOLID 還是很重要，甚至是更重要了。尤其是在 “跨系統”，”跨模組” 等等情況下更是如此。我先假設，跨越某些邊界後，就是兩套以上的 “專案” 了。AI 再強，這可能就是兩個團隊個別指揮各自的 AI 來各自維護了。要讓兩個團隊能很好的 “維護” 這整套系統，特別在系統架構，或是邊界的介面設計上，SOLID 仍然重要。
這說穿了，就跟這篇文章講的 “角色轉變” 是同一件事情，各位軟體工程師也要做好準備，以後真正需要人腦介入的，會從現在單一專案的 coding 轉移到跨專案的設計，協作了。這邊的協作不是只有指人跟人之間的協作，系統與系統的協作 (就是服務的邊界，API，Interface，Service Contract 都是) 會是主要的戰場。
換一個角度來說，我經歷過高階語言，靠著強大的編譯器，幾乎取代了組合語言存在的價值 (現在大概只剩特定領域的開發需要靠 ASM 了吧)。我舉一個 C++ 編譯器的例子，Inline function.. 為了效率, C++ 編譯器會將部分很小，呼叫頻率很高的 function 攤平，他不會被編譯成 function 被重複呼叫，取而代之的是會把這些程式碼直接在需要他的地方直接展開 (複製) 一份。
這樣效能好上好幾倍 (因為省掉了 call / return 的操作, 省掉了 call stack 的維護)，如果 function 本身也很小，那差距就很大了。為何沒有人抱怨這樣 “binary code” 的維護性會很差? 因為，人類已經不會直接去 “維護” binary code 了啊，即使你只改一個指令，你也會按照程序重新 build 一次。可維護性這件事，到了現在這年代，已經完全被編譯器，還有成熟的 CI/CD pipeline 取代了。大家只管 build 好的 artifacts 好不好管理，沒人管 artifacts 內的東西好不好維護了…。
所以，現在大家眼裡的 source code 還需不需要顧慮到 “可維護性” ? 只要 source code 還得靠 “人” 來檢視，維護，就算你只是 code review 就還需要，更何況現在還需要靠人來 debug …。當 AI coding 進步到像是編譯器這樣的存在時，真正意義上的 source code 已經變成規格文件，或是 system prompt 時，Source Code 已經完全不需要人類介入時，再來想這個問題吧。到那時，Source Code 已經退化成像現在的 Binary Code 般的存在，可維護性就不是主要的議題了。
到那時，會需要 “可維護性” 的，會逐漸演變成 “文件” 跟 “prompt”，還有定義跨系統的各種技術規格 (我也不知道以後這是靠文件，還是靠各種程式語言，如 IDL / OpenAPI 之類的)。而到那時後，軟體開發領域中，人類的角色，會自然的會從現在視角的 “軟體工程師” 轉化成 “架構師”，”系統分析師”，”產品經理” 等等角色了。
加上兩週前，我也貼了篇 GitHub Copilot Workspace 的 PO 文，也提到這是 server side 準備好的 AI agent, 幫你處理你 po 的 issue, 發 PR 給你 code review 的轉變。某種意義上，就是強迫你把角色從 programmer 轉換成 team leader，本質上也是同樣的 patterns.,..
從這角度來看，這篇文章的推論是很合情合理的，但是中間轉移的脈絡，沒有仔細想清楚，只看結論的話應該會無法想像吧… 不管 AI 怎麼發展，其實原則都一樣，你要跟上他，隨時讓 AI 都能成為你的助手 (代表你要有能力駕馭它)，你自然會演變成上述的那些角色。
– 引用的原文，我貼在第一則留言內
