幾個月前，我在社群媒體看到一張裁員通知書的截圖。底下有一行說明：「公司說是因為導入 AI 工具，現有的人力已經足夠應付產出需求。」

貼文底下，討論炸鍋了。有人說「AI 終於來搶工作了」，有人說「才不是，景氣才是主因」，有人說「這只不過是管理層找的藉口」。

你有沒有發現，每次講到 AI 取代工作，大家都搖身一變成為科幻小說作家或政論節目名嘴，但很少有人能把問題問得更精確一點？

這正是我想做的。

企業裁員本來就常常同時混著很多因素：景氣循環、利率環境、先前擴張過頭、部門重整、資本市場壓力，還有管理層自己的判斷失誤。AI 可能是其中一個原因，但通常不會是唯一原因。

即使如此，如果企業真的導入 AI，而且確實拿它來減少人力，那這件事在理論上會受到什麼限制？仍然很值得分析。

這篇想做的，不是判斷每一次裁員到底有多少能歸因於 AI，也不是「AI 會不會取代人類工作」那種容易流於口號的大哉問，而是把問題縮成一個更乾淨的版本：

如果公司導入 AI，並且希望用它減少一部分人力，那麼這個人力縮減比例，在理論上有沒有上限或下限？

這篇想做的，就是用一個非常簡單的理性模型，把這件事的骨架先抽出來。

傳統上，複雜的軟體專案，除了程式設計師之外，還會搭配系統設計師，甚至系統分析師，確保領域知識及商業邏輯都有朝對的方向前進。

生成式 AI 既然會寫程式，下一個問題就是：它也會做系統分析嗎？

理論上來說，應該是的。畢竟我們在前一篇文章都親眼看過，AI 既然能理解規格、潤飾需求、撰寫程式碼，甚至生成測試案例，那麼系統分析 (SA) 和系統設計 (SD) 這類「中間產物」，確實也難不倒它。畢竟，系統分析本質上就是資訊的整理、建模與推理，而這些都是 AI 擅長的領域。

我認為，SA/SD 也應該納入 AI 協作。尤其是從 SA/SD 擅長的建模角度，能夠協助我們及早確認領域知識及商業邏輯，檢查需求規格是否有矛盾、遺漏或模稜兩可的地方，甚至提出改善建議，幫助系統分析師更快定位問題，減少後期開發的返工成本。譬如說，透過 AI 生成的狀態轉移圖，也有助於規劃黑箱測試，提高測試覆蓋率，進而提升系統的穩定性與可靠性。

接下來就是現實問題了：讓 AI 產生的狀態圖，真的比人工畫得更好嗎？能省多少時間？

這就要實測了！現在，就讓我們拿前一篇文章的規格作為引子，看看 AI 生成的狀態圖表現如何吧！

人類從事的領域，不斷被生成式 AI (GenAI) 入侵。

社群媒體上，早就充斥一大堆「AI 體」的文案圖案，現在就連程式設計領域也開始淪陷。像 Google 執行長就透露：「在 Google，超過 1/4 的新程式碼已經是先由 AI 生成，再讓程式設計師去複審與確認。」¹ 而 GitHub 執行長更大膽預言 80% 的程式碼都將會由 GenAI 生成。²

也就是說，以前，程式設計師得親手撰寫大部分的程式碼；現在則開始挪出一段時間去跟 GenAI 對話：調教提示詞 (prompt)、審核生成的程式碼、確認正確性，如此反覆進行好幾個回合。

GenAI 進展神速。如果某一天進展到，只要提示詞下得夠精準，第一次生出來的程式碼幾乎就合格過關了，是否也就意謂著，程式設計師的專業訓練及工作重點，將會更轉向 ⑴ 鑽研提示工程、⑵ 審核生成的程式碼這兩條路線發展？換句話說，將會更朝向 ⑴ 前段的需求規格、⑵ 後段的測試驗收這兩條路線？

如果頭尾兩端（需求規格與測試驗收）都由人來看守定義，中間步驟（撰寫程式碼）改由 GenAI 來操刀，是否也就意謂著，程式碼會變成像是可拋棄的東西，反正隨時都可以叫 GenAI 再生出一份出來？甚至當 GenAI 能力升級之後，又能夠生出比拋棄掉的還要更好的程式碼？

聽起來可能有點兒瘋狂。可是如果以上屬實，那麼，敏捷四大宣言之一「可用的軟體 重於 詳盡的文件」，在 GenAI 時代是否依然成立，可能都值得再重新評估檢討。

為此，我在 ChatGPT 4o 進行一系列小小的實驗。試試看當 GenAI 收到前段的需求規格之後，能夠生出什麼樣的程式碼以及測試驗收案例；緊接著會與 GenAI 協作調教頭尾兩端（需求規格與測試驗收），再看看 GenAI 重新生出來的程式碼，會有什麼不同。

「敏捷」這概念，台灣很晚才起步。

儘管敏捷宣言 (The Agile Manifesto) 早在 2001 年就問世，可是在台灣，如果以 David Ko 在 2014 年首次舉辦的 Agile Tour Taipei 活動作為開端，「敏捷」開始成為台灣業界的話題，大概也不過十年。

於是，在國外早已經百家爭鳴的「大規模敏捷」流派（連 SAFe 都出到 6.0 版了呢），在台灣，直到近年才零零星星有人談到這議題。

大規模敏捷的各家流派，多半是從 Scrum 之類的原型出發。但 LeSS 與眾不同的是，它非常謹慎自制，避免在規模化過程中引進無謂的複雜。

就如同《多團隊高效協作密技》所說：「規模化，不是角色變多、流程變複雜，而是協作方式的改變。LeSS 的導入，難處都不在 LeSS 的流程，而是在環境與人的不配合。」因此，想學習 LeSS，重點不要只放在流程上，應該更留意探討這些協作、環境、人的議題。這才是形塑 LeSS 的關鍵驅力。

全球都在享用 Google 首屈一指的線上服務群，但直到他們在 2016 年出版了 Site Reliability Engineering 一書，世人才第一次全面認識到該如何支持這種深度廣度的系統維運。

全球性線上服務系統，規模與複雜度遽增，只靠傳統的人力或獸力是無法長久維運下去的。面對這問題，擁有第一流軟體研發能量的 Google，大膽拋開傳統作法，改從一個獨特的提問出發：「如果我們賦予軟體研發工程師一個任務，讓他們有機會從頭去設計維運系統，那會是什麼模樣？」

更進一步的提問是：「如果我們限制他們最多只能投入 50% 的時間在維運上，那會是怎麼樣的工作方式？」

從這角度出發，便是目前我們現在看到的 SRE。