AI

這些年，AI 的蓬勃發展和誘人的可能性，早已讓組織一股腦地投入 AI 相關應用與探索，以便提升自身的競爭力。不過隨著技術漸漸落地，應該也不難發現 AI 所帶來的不確定性。比方說，即便發送相同問題的請求，AI 也無法保證次次給出相同或預期的結果，而且這還不討論近幾年大語言模型的幻覺現象。因此，想要從 AI 獲得好處，我們需要思考的是如何管控這些不確定性，並且做出合理的權衡決策。 NIST AI RMF 便是用來協助組織管理 AI 所帶來的風險與影響，讓組織能在控制潛在危害的同時，真正取得 AI 所帶來的效益。 想要了解這個工具，首先得先來聊聊 Risk 在風險管理情境下的概念。在日常情境下，聽到 Risk 這個字多半會先想到負面的事件。不過在風險管理的角度上來看，Risk 卻有更為寬廣的定義。 ISO 31000 定義 Risk2 為不確定性對既定目標所產生的影響(effect of uncertainty on objectives)

生產！生產！生產！ 每當有新的技術出現時，肯定會以生產力倍增等讓人目亂神迷的字彙登場，不管是 20 年前的教你事半功倍的敏捷，還是十年前小步迭代快速前進的 DevOps，誰不想當菁英團隊呢？不只是老闆想，工程師也能從創造過程中得到滿滿的成就感。這次的 AI 風則吹得更強，不僅有快和生產力，連同取代誰取代誰的新聞也不停地被宣傳。 AI 已經成了不可逆的趨勢 軟體工程師或多或少都會使用 AI 工具來協助自己的開發，更何況現在大型組織甚至會以公司政策的方式推廣。用的人是變多，但相信的人呢? 從 2025 年的 stackoverflow 報告來看，卻只有 33% 的工程師相信 AI 的產出1。當然用或不用看個人需求，但新聞卻一直訴說著，AI 正在取代軟體工程師！組織內會有多少比例用 AI 取代之類云云。不過，隨著時間過去，這些訊息看起來顯得開始漸漸冷靜。開始有科技龍頭表示，他們有著新的軟體人才需求。說到底，到底怎了？，這訊息，這日子還要不要過了呢？ AI 變動了軟體開發過程的成本配比 一個軟體開發的團隊，不管怎樣配比，肯定寫程式的人比較多。畢竟這是一個現實的議題，需求沒實現出來，一切也就都白搭了。只是當軟體開發出來，就會發現還有很多工作等著要處理，所以全端、全循環、一條龍等工程師頭銜總是能夠喚起工程師們嘴角的苦笑。不過現在這個程式生產活，貌似有了一個沒心沒肝又不喊累的 AI 可以頂上了。 哇~瓶頸有解了！

端到端的價值與增長的技術債 面對遺留的程式碼，若要進行技術、架構或工具上的轉換，你會如何進行? 是規規矩矩地重新改善程式碼，還是先上再說? 這個問題對於工程師或者是開發團隊來說，通常不容易回答! 即便回答了，這個答案也會浮動。這是因為組織需要向著最終的產品價值持續發展，而這也導致研發團隊必需或不得不持續地讓技術債增長。DevOps 從維運在敏捷實務做法上的探索，到開發與維運之間的協作，再到端到端價值的追尋，但這就像雙面刃讓持續地價值追尋也等同於持續地增長技術債務。從 Gartner 的調查1中，可以發現技術債增長的前幾個主要原因(僅列出部分)有： 過度地為了市場的需要而造成軟體架構或設計的脆弱； 追求時效而更甚於軟體品質； 技能落差。 面對這些技術債的問題，研發團隊通常採取的行為，不外乎： 紀錄、追蹤、排入改善時程； 找尋重構機會； 透過測試案例維持最基礎的品質； 監控與偵測，以便即早發現問題並且解決來降地衝擊。 然而，我們真有時間和精力花在這些行為上嗎? 還是單純為了精神上的救贖? 這個問題在 LLMs 橫空出世後貌似有了一個解答，那就是： 用 AI 來提升我們的生產力吧?