AI 時代的軟體開發變革-系統邊界
延續前一篇AI 時代的軟體開發變革-趨勢，本篇接著談我認為軟體開發即將發生的其他改變。
系統邊界的改變 - 先談客製化
在AI 時代，系統的 codebase 我認為會變小，也就是預先定義，並且被開發出來的功能會減少。或者大家可以解讀為，許多功能會由 AI 完成，甚至是不寫 code 就完成，因此實際人類要寫，或由 AI 代勞寫出來的 code，整體應該是減少的。
但因為 AI 的出現，也讓系統本身得以延伸，包含讓自己成為一個資訊中心，將自身的功能與數據極大化的與其他系統連結，又或者反過來，跟盡可能多的系統進行數據交換藉此完善自身功能。
在這邊先援引 Happy 的文章：
Happy Lee 李昆謀
Happy 文章中提到的客製化我非常有感，因為過往我們為了滿足不同的客戶需求，我們總會需要撰寫額外的 code，而這通常導致架構開始變亂，要維護的程式分支增加，技術債愈堆愈多。可偏偏，客製化在業務推進過程，經常都是必要之惡。
我們通常只能盡可能的框好客製化的範圍，讓多數的開發資源還是投入在產品的標準功能上，而非單一客戶的客製化需求。
可是隨著業務擴展開了，客製化需求通常也會愈來愈多，而成熟的開發團隊也會開始認真思考(至於不成熟的團隊就不好說了XD)。如何讓客製化不再需要投入工程師進行開發，而是客戶透過設定，或者我們所提供的工具就能完成他所需要的功能。
上述是我對軟體客製化的四種層級：
Lv1：用戶設定，以使用者為單位，使用者介面上讓他根據自己的喜好做設定。
Lv2：系統參數，以系統為單位，系統管理員可以針對整個系統進行偏好設定。
Lv3：模組化工具，像是 PowerBI、Salesforce 的流程工具，軟體廠商提供了工具，讓使用者可以透過一些學習便能做到更多元的客製化。
Lv4：開發整合，可能是提供一個 PaaS 平台，或者提供更多的 API 或元件，讓客戶端的 IT 或工程師能透過撰寫程式來實現標準產品所沒有的功能。
L1、L2 基本上都還是得修改系統，Lv3 則可以在系統內，也可以是個外掛程式，Lv4 的靈活度最高，但進入門檻也是相對高的。但如果開發團隊有做了上述四件事，公司是有相對大的機會將客製化這件事降到最低。
對團隊來說，關鍵任務是將這些客製化、個人化的需求委由使用者、企業 IT、外部開發人員來處理。如果真的需要開發團隊處理，那工作量要盡可能降到最低。
而要做到這件事，我們得重新定義系統邊界，也就是系統做什麼與不做什麼。嚴格來說，那些不在產品 roadmap 上的項目，是盡可能不做的，但今天客戶需求來，在有業績目標壓力時，有多少人可以很堅定的說「NO」呢？我認為這挑戰性非常大。
如果今天接收到的需求，我們必須得做，但需求又在系統邊界之外時怎麼辦？我們必須得開放系統介面(interface)，讓外部能夠存取。
上述的四種客製化模式，本質也是開放系統介面，差別在於形式與深入程度。
從 API 到 Agentic AI
而開放系統介面最常見的方式，就是開放 APIs(Application Programming Interface)，把系統中資料的存取權限，透過一個個的 API 開放出去。讓外部系統可以讀取(read)跟寫入(write)系統中的資料，進而達到跨系統間的整合。
而近兩年大家談論的最多的議題，應該是關於代理 AI(Agentic AI)，指的是透過 Agent 來進行系統間的整合。但 Agent 並不能完全取代 API，Agent 比較像是做為外部系統與 API 之間的中介。
Agent 可能同時對應一個或多個 API，替代 API 來跟外部系統進行溝通，等於是在 API 與外部系統間多架了一層。而 Agent 除了處理自然語言之外，也結合 LLM 進行最擅長的分析、規劃、匯總等工作，然後再進一步調用 API 來執行多樣的數據處理工作。
這邊舉一個案例，以前如果要召開一個有效能的跨部門會議，我們可能需要做以下幾件事：
- 發信件或透過其他方式確認關鍵與會者的時間。
- 發出會議通知。
- 會議進行過程進行會議記錄。
- 會議後發出會議紀錄與待辦事項。
- 跟進待辦事項。
這中間可能會涉及到多個數位工具與大量的人工作業，但現在我們可以撰寫一個 Agent 來達成以上任務，這個 Agent 的運作可能長這樣。
- 連結 Outlook 或 Google calendar，直接找出關鍵與會者的空檔時間，並發出會議通知。
- 會議進行過程自動呼叫 AI 機器人進行會議記錄，並於會議後自動發出。
- 分析待辦事項內容，將待辦事項分派給對應的負責人並設定回報時間。
- 下次跟進會議時，直接調閱待辦事項進度。
上述每個動作，都由 Agent 自動完成，過程中無須人工介入。現實工作中固然沒法做到盡善盡美，但這已經是現在 AI 能輕鬆搞定的任務了。
再舉一個例子，今天公司的業務主管想要知道部門內業務的工作狀況，一般而言他會需要處理幾件事：
- 上 CRM 系統查詢業務的業績數字。
- 上 行事曆 系統查詢業務行程。
- 上 CRM 查詢客戶拜訪紀錄、業務開發計畫，並與行事曆進行比對。
- 上 HR 系統確認員工的出缺勤。
- 上 CRM 系統查詢員工歷史業績表現與業績獎金。
- 彙整整體工作狀況。
這個動作跨了兩個系統，且涉及資料的彙整，對資深業務主管來說，他得花上不少時間處理，而對新手主管來說，還多了一層業務管理 know-how 的挑戰。
但這些 know-how 與資訊處理過程完全能由一個「業務管理 Agent」來取代掉。
業務主管只要下 prompt：「我想知道 OOO 最近兩個月的業務推進狀況。」，Agent 便會自動進行上述動作，並產出一份工作現況分析。
你可能會覺得，那這還不是要花大量時間寫 Agent？跟以前為了這情境寫一支完整的程式有什麼差別？加上要重新學習 AI，會不會花的時間反而比本來更多？
會有這樣的疑問不奇怪，但我們得先回到 GenAI 的出現到底對寫程式帶來了什麼改變。
我認為關鍵差異在於，LLM 的存在，讓 Agent 具備自適應能力。
簡單舉幾個例子：
- 多個系統之間，資料交換格式不同，過往需要人共介入撰寫大量的程式來處理格式問題，現在 AI 有能力自行處理。
- 維運上任何的細微調整，包含 A 伺服器附載過重或回應過慢改連 B 伺服器，A 伺服器發生錯誤直接切換到 B 伺服器。這些過往要不仰賴大量人工處理，就是得做好許多預先定義的邏輯。但現在 AI 能根據系統維運的基本邏輯，以及已知的系統架構，自行調節配置，並且開始修復錯誤。
- 傳統模式中，所有程式的邏輯都是預先設計好，不具備自動適應能力，但 AI 可以根據使用者回饋、數據結果、錯誤回報等機制來動態調整邏輯。
這樣的例子很多，不勝枚舉，但我認為核心關鍵在於 AI 的自適應能力，也就是可以根據數據、prompt 直接調整邏輯，而不是固定不變的。
聽起來神奇，但依然存在許多風險，因為重要的系統功能，在缺乏人為監管的狀態下，哪能放心全然交給 AI 處理。
不過這就是個過程，我們可以逐步將低風險的任務，先交給 AI 處理，並監管一段時間，確保結果符合預期。接著就可以拿掉監管，往後只要每個月確認一次，或者在問題升級時再做處理即可。
往 Agentic AI 發展的第一個挑戰 - API 化
開發 Agent 的前置工作是系統本身的 API 要盡可能的完善，從系統觀點，API 的存在除了讓系統間可以有效溝通外，還有封裝與隔離的作用在，API 限制了外部對系統的存取操作範圍，這對於確保系統的安全性是有重大幫助的。
想像一下，如果一個 Agent 在自適應過程出了差錯，在沒有 API 層隔離的狀態下，他可能會直接面對整個系統內的所有可存取的 function，最終會搞出什麼問題來還真的不好說。但因為多了 API 層，Agent 能做的事其實就被 API 給限制住了，這也確保了系統本身的安全性。
之前跟一家公司的工程師在討論這方面的需求時，有個工程師曾說要做一個 Super API，這個 API 擁有資料庫中所有資料表的 CRUD 功能，這樣就不用針對個別資料表的存取去撰寫 API 了。
這個想法超級危險，因為不同資料表之間可能有所關聯，針對不同的狀態也有不同的存取權限控制，忽略這些直接將整個資料庫的存取都開放給 AI，跟裸奔其實沒兩樣。
所以撰寫 API 是走向 Agentic AI 架構過程很難避免的工作，但有了完善的 API，那開頭提到的客製化乃至於整合的問題便會大量減少。
因為你可以讓第三方來撰寫 Agent，或者由外部系統廠商、客戶自行撰寫 Agent 來實現他們的需求，大大減少自家產品的工作量與複雜度，是很值得投資的一件事。
為 GenAI 的輸入/輸出格式做好準備
在思考系統邊界問題時，我也看到另一個可能會影響系統設計的議題，那就是怎麼處理 GenAI 的輸入與輸出。
多元的輸出格式
先談輸出，許多系統的前端介面是寫死的，這直接限制了 GenAI 在介面上的表現能力。就像早期的 ChatGPT 只能回傳聞自，無法回傳圖片，或者只能提供醜醜的 ASCII 表格，但做不到複雜表格處理，也無法做到高互動介面。
你說這是因為 GenAI 的限制嗎？其實不是，限制住他的其實是 ChatGPT 的前端架構。
所以如果我們要解放 GenAI 的能力，我們的前端架構也需要相對有彈性，這樣使用者下 prompt 後能獲得的個人化效果也會大大增強，更有機會透過 GenAI 實現高度客製化。
自然語言輸入
再談輸入，從輸入角度，我覺得 GenAI 帶來的變革是劃時代的，因為他能接受自然語言。
以前如果我要查詢一些資料，我得在介面上根據我要的條件逐一輸入參數，有時這些參數還具有先後順序與邏輯性。像是 AND 或 OR，AND 跟 OR 有沒有先後的問題，或者 >、<、= 之間是否有任何邏輯互斥的問題。
過去為了讓使用者能獲取自己想要的結果，這種介面設計是必要之惡，但這種設計的學習成本非常高。
但現在使用者可能只要下 prompt：「請幫我抓取 OOO 部門，在 3 月 1 號到 15 號之間，缺勤次數超過 2 次的員工，以及加班時數超過 10 小時的員工。」
以前為了組成上述條件式，我們可能得忙個老半天，但現在交給 GenAI，他可以直接理解，並給出對應的資料。這除了大大降低學習成本外，也會讓使用者更願意經常使用系統。
另一個我覺得很多軟體服務都已經在用的是將系統操作的指引也交給 GenAI，像是 Canva 上有很多功能我剛開始用的時候其實都不知道怎麼使用，哪些功能藏在哪我也不知道，但我只要「問問 Canva」他就能教我怎麼用。
以前在產品功能愈加愈多時，我們總得進行介面的重構，確保介面不會複雜到使用者找不到所需功能。就像以前的 Office 一樣，選單跟功能很多，但如果不常用，經常會找不到在哪，因為你可能連功能的名稱都不記得了。
但現在因為可以直接用自然語言問，有些功能就算藏的很深也不擔心，因為使用者跟系統互動的方式已經從 GUI 進步到自然語言了。
讓使用者用自然語言操作系統，我認為這是未來所有系統的重要趨勢。
上面是我過去一年的一些想法，提供大家參考，而關於 AI 時代的系統邊界問題，我有以下幾點總結。
- 系統的 codebase 會變小，由外部系統或 Agent 處理的比例會增加。
- 系統的邊界還是得看 Agent 是否被含括在系統範圍，如果 Agent 是一個模組，那其實仍在系統邊界內，如果是一個外部服務，那便排除在外。
- 開放 API 會讓系統能力往外延伸，也會同時增強系統本身能力，API 化會是跨入 GenAI 的重要步驟之一。
- 要享受 GenAI 的能力，系統的輸入與輸出的介面設計非常重要。
如果你覺得我內容寫得還不錯，歡迎訂閱我的電子報，我每雙週會發送一封電子報到你的信箱。訂閱連結在這，過往的電子報也在這：Gipi電子報
也鼓勵你可以將我的電子報分享給你認為有需要的朋友們，也許你的舉手之勞，將會改變另一個人的思維與習慣。
