全世界都在砍人，但真正被砍掉的是公司的未來

作者：柯仁傑（三叔公）

這兩年，軟體產業的空氣冷得讓人打冷顫。你一定有感：公司不是不缺工程師，而是不想再養「沒經驗的人」了。

裁員潮過後，招募市場進入了極致的現實主義：凍結新人名額、不收 Junior，所有的職缺都指名要 Senior，最好還能無縫接軌 AI 協作。表面上看，這決定聰明極了——省掉漫長的培訓期，靠 AI 輔助產出，報表上的開發速率甚至比以前還漂亮。

但身處其中的人都知道，這條路走久了，前方是一片看不見底的斷層。你省掉的不是成本，而是這家公司長久活下去的「免疫力」。

當「資深」成為絕響：被犧牲的經驗傳承

資深工程師不是從石頭裡蹦出來的天才，他們是靠著無數次與前輩的技術辯論、在半夜修復崩潰系統、以及在複雜架構中反覆踩雷，才慢慢磨出來的。這種「工程直覺」是活的，它存在於辦公室的閒聊裡，存在於 Code Review 時的一句點撥中。

當公司決定只留下 Senior，並把所有複雜的事全部往這群人身上堆時，組織的結構就開始變脆弱。因為沒有了 Junior 來承接基礎工作，資深老手被瑣事與高壓磨耗，根本無暇分享經驗。漸漸地，知道系統「為什麼當初這樣設計」的人越來越少。

AI 寫程式很快，但它不會幫你養下一代。 AI 能產出語法正確的程式碼，卻無法傳承那種「看過世界崩塌後留下的判斷力」。如果你的公司不再有空間讓人學會如何變成 Senior，那這家公司的技術壽命，就只剩下那幾個老臣的職涯餘溫。

LeSS 如何在 AI 時代救火？打破「資深工程師」的黑盒子

當每個人都躲在 AI 背後快速產出，技術就變成了少數人的「私房菜」，這正是組織走向崩潰的開始。Large Scale Scrum (LeSS) 的存在，並非為了增加開會時間，而是要設計一個「強迫知識流動」的架構，解決 AI 帶來的孤島效應：

1. 多團隊 PBR：讓「判斷力」變的可視化

在 AI 時代，最不缺的就是 Code，最缺的是「為什麼要這樣寫」的判斷。LeSS 要求的 Multi-team PBR (需求釐清)，是讓多個團隊聚在一起拆解需求。當資深者在討論「這個功能會影響到哪個陳年舊帳」時，Junior 在旁邊聽的就是最實戰的架構思維。這不只是在看規格，這是在進行「思考方式」的集體校準，讓 AI 無法取代的經驗值，能透過對話從大神腦中「外溢」出來。

2. 跨團隊 Planning：打破「各掃門前雪」的慣性

AI 讓個人開發變快，卻也讓團隊變得「自私」，大家只管自己的 Task。LeSS 的 Sprint Planning 讓大家看到全貌，強迫不同團隊去思考彼此的依賴關係。這能防止 Senior 帶著 AI 狂奔，最後卻在整合時撞牆。這種整體的協作觀，是讓新人能從全域角度理解系統，而不只是當一個被 AI 餵食的「填空作業員」。

3. Review 與 Overall Retro：建立組織的「集體記憶」

當 Senior 靠 AI 寫出精妙但難懂的程式碼時，LeSS 的 Sprint Review 提供了一個公開檢驗的機會，確保「知識」不是鎖在某人的電腦裡。而 Overall Retrospective 則是讓組織停下來修補那些因為追求速度而裂開的協作流程。它確保團隊不是在盲目衝刺，而是在不斷優化那個「讓人能變強」的環境。

結語：這是關於「繁衍」的抉擇

有些公司選擇極大化眼前的產能，壓榨資深者的剩餘價值，把人才當作耗材。而有些公司選擇建立一個結構，讓經驗能被攤開、被接住、被繼承。

LeSS 提醒我們的現實很殘酷：當全世界都在拒絕 Junior 時，真正危險的不是人變少，而是你的組織已經失去了繁衍能力。如果一個團隊只剩下幾個大神在撐，底下卻沒有任何生命力在遞補，那不叫高效，那叫「倒數計時」。

這不只是流程優化的問題，而是公司到底想不想活得久一點的問題。 在 AI 浪潮中，跑得快的人很多，但能帶著團隊一起走遠的人，才是最後的贏家。