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

貼文底下很快就吵成一團。有人說，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。