AI in the Loop - DevOps 現況、轉變與我的嘗試

端到端的價值與增長的技術債

面對遺留的程式碼，若要進行技術、架構或工具上的轉換，你會如何進行? 是規規矩矩地重新改善程式碼，還是先上再說?

這個問題對於工程師或者是開發團隊來說，通常不容易回答! 即便回答了，這個答案也會浮動。這是因為組織需要向著最終的產品價值持續發展，而這也導致研發團隊必需或不得不持續地讓技術債增長。DevOps 從維運在敏捷實務做法上的探索，到開發與維運之間的協作，再到端到端價值的追尋，但這就像雙面刃讓持續地價值追尋也等同於持續地增長技術債務。從 Gartner 的調查¹中，可以發現技術債增長的前幾個主要原因(僅列出部分)有：

過度地為了市場的需要而造成軟體架構或設計的脆弱；
追求時效而更甚於軟體品質；
技能落差。

面對這些技術債的問題，研發團隊通常採取的行為，不外乎：

紀錄、追蹤、排入改善時程；
找尋重構機會；
透過測試案例維持最基礎的品質；
監控與偵測，以便即早發現問題並且解決來降地衝擊。

然而，我們真有時間和精力花在這些行為上嗎? 還是單純為了精神上的救贖? 這個問題在 LLMs 橫空出世後貌似有了一個解答，那就是：

用 AI 來提升我們的生產力吧?! 或許這些問題就能迎刃而解。

AI vs. DevOps

其實 AI 應用於 DevOps 的世界裡並不算新鮮事! 早在 2019 年前，就開始期望透過大數據或機器學習模型來協助監控，以便即早的發現問題並且採取行動，但這時候很多的行動仍然是手動進行，而模型對於問題的判斷也不甚穩定。到了 2019~2021 年，機器學習的相關發展從維運端延伸到開發端，開始有工具運用 AI 來程式的品質與 CI/CD pipeline 的最佳化，但這些發展都沒法比得上 2022 年 LLMs 所帶來的衝擊！

隨著 LLMs 的發展，SDLC 各階段的活動如何被 LLMs 影響並且加速軟體開發開始成為顯學！

圍繞著 DevOps 各階段有著不同的探索和發展，如下圖：

說是這麼說，看起來 AI 大可以解決我們的痛點，甚至取代工程師！是嘛? 或許不容易為此問題找到唯一的解答，但可以從 2024 年的 DORA 報告中察覺一些洞見和違和處：

AI 對於程式碼品質、技術債與架構複雜度均能提供幫助，但當 AI 採用率提高 25% 時，穩定度和處理速度卻都是下降的；
工程師對於生成的程式碼信任度仍然偏向懷疑態度(實際上，從其他調查也能發現程式碼一修再修的比率也在上升)；

AI 的確很厲害，但現實是它仍然無法穩定提供 100% 正確的答案，而且軟體開發也不只是將程式碼生出來，還需要考慮架構和後續的發展。說是這樣說，但 AI 所帶來的生產力仍然讓大家難以忘懷，所以面對 AI，顯然不是回答用或者不用，而是要回答「AI 與我們之間的互動關係究竟為何?」和「目前 AI 使用上有哪些顯著的限制或風險?」，因為這樣我們才能夠知道如何在速度和可持續發展兩者之間找尋平衡點。

AI in the loop vs. Human in the loop

所謂 loop，可以想像成達成某一目標的所有活動和工具。Human in the loop 代表著人扮演著提供回饋的角色，但對於最終產出並沒有決定權，也就是說在此種模式下，AI 主導最終成果。它做出決定，而人只是接受它的結果，然而 AI in the loop 代表著 AI 扮演著回應或回饋的角色，而人則對最終產物有最終決定權，所以簡單說：

Human in the loop 代表著自動化，而 AI in the loop 則代表人與 AI 之間的協作

不同的情境和條件，與 AI 的互動關係也會有所不同。比方說，想快速取得使用者回饋且工程師並不需要對程式碼的未來持續發展負擔太多責任時，那麼採用自動化生成會是一個很好的選擇(Human in the loop)，然而對於需要長期維護與發展的軟體來說，工程師需要對成果有長期的責任，所以工程師擁有最終成果的決策權顯然是更好的作法(AI in the loop)。簡而言之，你無法請 AI 負責任，所以當你需要負責任時，那就得想想自動化比較好，還是 AI 協作比較好。至於選哪個比較好，那就得先了解 LLMs 在運用上的主要問題：

如何提供完整的情境(Context)；
Token 數量上限；

上述兩個問題也進一步影響 AI 生成程式碼的品質與對軟體架構的理解和掌控力，而這還不討論模型升級所帶來的答案變動。因此，工程師仍然需要有能力為最後的產出作出決定，然而自動生成的過程也在鈍化工程師的程式碼撰寫與掌控能力。身為一個工程師，如何在自我成長和 AI 依賴性之間取得平衡顯然才是使用 AI 的關鍵問題。至於新人，如何保持清醒並且持續成長更是一個關鍵的挑戰。面對這些關鍵問題，工程師要做的便是「知識分享、偶爾放下或調整與 AI 的距離、與他人互動和討論」，以便保持思考的柔軟度而不會一味地陷到 AI 的論述中，從而持續找到讓自己成長的方法。

隨著 AI 持續的發展，企業對於 AI 工具的擁抱肯定會越來越為普及，然而在在筆者的顧問經驗過程中，目前企業仍著重於生產力，卻未對組織內的 AI 運用政策與成員能力的維持與提升措施有更多的著墨，這顯然又會是技術債或系統風險累積的另一道驅力。生產力固然是重要的議題，但如何讓生產的成果持續為組織帶來價值也是另一個重要的議題，所以組織需要盡快為其 AI 運用形塑屬於自己的治理模式，以便管控組織的營運和業務風險，也才能夠讓 AI 真正地為企業產出價值。關於 AI 治理，組織可以參考 2023 年 1 月發布 NIST AI RMF 框架，而這也是目前最完整的框架標準。