AI 讓效率提升，但誰來當保護品質的人？

生產！生產！生產！

每當有新的技術出現時，肯定會以生產力倍增等讓人目亂神迷的字彙登場，不管是 20 年前的教你事半功倍的敏捷，還是十年前小步迭代快速前進的 DevOps，誰不想當菁英團隊呢？不只是老闆想，工程師也能從創造過程中得到滿滿的成就感。這次的 AI 風則吹得更強，不僅有快和生產力，連同取代誰取代誰的新聞也不停地被宣傳。

AI 已經成了不可逆的趨勢

軟體工程師或多或少都會使用 AI 工具來協助自己的開發，更何況現在大型組織甚至會以公司政策的方式推廣。用得是人變多，但相信的人呢? 從 2025 年的 stackoverflow 報告來看，卻只有 33% 的工程師相信 AI 的產出¹。當然用或不用看個人需求，但新聞卻一直訴說著，AI 正在取代軟體工程師！組織內會有多少比例用 AI 取代之類云云。不過，隨著時間過去，這些訊息看起來顯得開始漸漸冷靜。開始有科技龍頭表示，他們有著新的軟體人才需求。說到底，到底怎了？，這訊息，這日子還要不要過了呢？

AI 變動了軟體開發過程的成本配比

一個軟體開發的團隊，不管怎樣配比，肯定寫程式的人比較多。畢竟這是一個現實的議題，需求沒實現出來，一切也就都白搭了。只是當軟體開發出來，就會發現還有很多工作等著要處理，所以全端、全循環、一條龍等等類工程師總是能夠喚起工程師們嘴角的苦笑。不過現在這個程式生產活，貌似有了一個沒心沒肝又不喊累的 AI 可以頂上了。 哇~瓶頸有解了！

解了嗎? 或許有也或許沒有。因為自己會用別人也會用，商業競爭不會停止而且人類的慾望也不會停止，所以既有的穩定與承諾不能落下，軟體還得繼續創造價值。再加上，AI 雖然看起來正經，但時不時會在你無法充分掌握的地方放個炮。身為系統的負責人，一旦炸了當然爆的還是你自己。於是工程師的認知成本增加了，更重要的是程式碼審查成本增加了。說到底審查成本也不見得真的增加，重點在於單位時間的審查密度增加了，而且為了能夠避免放炮，就需要引入更多自動做法或系統性做法來穩住一切。

或許生產不再這麼壓迫人，但判斷能力的需求卻開始陡峭上升！

程式撰寫不是問題，但怎麼知道它真的有實現需求？找出設計方案不是問題，但怎麼知道它符合團隊與產品的限制？一個完美的框架技術，但怎麼知道團隊能不能吞得下去？測試案例的撰寫再也不是問題了，但怎知道它真有覆蓋失效點？怎麼知道 AI 不會註解掉斷言讓一切都美好？一切看似美好的答案，說到底這個答案可信嗎？可維護嗎？ 我受得了嗎？

是的！AI 正在深刻地影響 SDLC 各個階段內的活動。 身為一個工程師，我們應該怎麼應對這些「看起來很完整」的可能錯誤？

從五面向問題駕馭擁抱 AI 的軟體開發

這五個問題的重點在於以漸進的方式為「運用 AI 協助解決的問題」找出整體的脈絡，透過分階段的方式逐步地釐清目標，以便讓 AI 能夠更好地生成出解決方案，也讓自己能夠知道對方案選擇的前因後果。此外，可以在分析過程中將問題切分成子問題後，再用這五個問題來找出解決方案，並且組合成最終的答案。當然有興趣的讀者，請仔細閱讀一下分享的簡報，裡面有更多針對不同階段，以實例的方式展示如何思考五個面向的問題。

AI for Software Engineering vs. Software Engineering for AI

現在大部分焦慮的主題多是環繞在 AI 如何影響軟體開發的做法，但實際上 AI 也已經開始成為軟體系統的一部分。這使得問題變得更為複雜。過去的軟體系統是由固定的條件與邏輯架構實現而成，除非想漏了，否則系統行為是可以預期的，但現在的 AI 以黑盒子的方式成為系統的一部分，進而使得確定性的系統轉變成了非確定性的系統。

說到底，我們要如何管控這樣的系統呢？重點只有一個，那就是只在需要的地方引入 AI，且不要因為看似方便就讓它成為系統的一部分或擴張它在系統的領地。換言之，只在規則列不完或執行路徑具有變動性的情況下，引入 AI。此外，為這樣的元件設計相關的測試把控做法，包含輸入資料與輸出資料樣態與語意邏輯的把控、執行路徑紀錄的檢查、探索性評估和成效驗收等。

工程師該怎麼辦？

如果工具高效卻可能偶爾秀逗，吐槽它但又放不下它，那麼很可能或者說不得不要去思考軟體開發焦點的調整。軟體工程師當然還是要保有實作能力，畢竟這是一切的起點。若沒有一定實作能力，在閱讀和理解程式過程中，必然還是會有些阻力，但除此之外，需要比以往：

關注問題的邊界
AI 需要上下文，然而上下文來自於對於問題的樣貌的了解和描述力，因此模模糊糊的問題只能得到一個看起來合理但模模糊糊的答案
務實的選擇技術
AI 能夠提供相當多，甚至是想都沒想過的解決方式，但團隊只有一個，而自己也只有兩隻手。如果 AI 說什麼就用什麼，多樣性終究會成為團隊沉重的壓力
讓快基於客觀驗證
AI 生成速度很快，然而人力有限。如何用更小的迭代與建構需求、變更和臭蟲的追溯性來根據客觀資料協助自己放行那些高可靠或低風險的生成，以便真正地提高生產效率，而不是因為疲憊或麻痺的安全感讓生產效率變好。
掌握背景知識
AI 的確可以閱讀大量背景資訊，並且給出意見，但沒了背景知識的我們，又能如何判斷意見的好壞? 因此，讓 AI 去生成，但思考和理解也別放下，充分了解問題與需求，並且與利害關係人了解情境，會讓自己掌握難以用語言表達的情境訊息，進而讓產出能夠真的帶來成效。

工程代表的是圍繞的問題，找出具有經濟性且可重複和驗證的做法，從來都不是一個大概大概的思考方式。AI 面對正確終究存在機率性，而實際能負責的終究只有工程師的我們。或許不用再苦命地打出每一行的程式，但如何具備更宏觀且系統性的思考與判斷力去掌控每一行生成的程式，可能才是未來軟體工程師的新課題。