加拿大有超級豬，組織有膨脹、混血「超級工程豬」

2026 iThome 鐵人賽

DAY 10

Build on Google AI

18th鐵人賽前端三分鐘要轉職養豬還是做被取代的工程師

70 瀏覽

前端三分鐘 X 要轉職養豬還是做被取代的工程師？用 Google AI 打造我的 AI 雙刀流自動化工作流系列

在前面我們聊過了少子化、農業自動化，以及加拿大「超級豬」在缺乏管制下對生態造成的衝擊。但仔細想想，這種「生態失控」與「合規機制失靈」的現象，在我們的 IT 組織與團隊演進中，不也每天都在上演嗎？

當我們把鏡頭從技術架構拉回到「人」與「組織」，你會發現整個 IT 產業的演进史，簡直就是一場大規模的基因雜交、流程崩壞與生態演替。

提到養殖業的集體危機，大家一定對前陣子「廚餘養豬引發非洲豬瘟危機」印象深刻。

許多人以為問題出在「廚餘本身」——就像很多團隊以為問題出在「用了外包/實習生」或「讓 AI 生成程式碼」一樣。但事實上，廚餘本是可以循環利用的低成本資源，真正的核心病灶在於：政府開放了廚餘餵食，卻缺乏一套合理且強制執行的「高溫蒸煮與合規檢驗」過程。

當少數不遵守高溫蒸煮規定的農場貪圖方便、偷工減料，未經過滅菌處理的病毒便順理成章傳播開來，最終釀成整個養殖產業的集體崩壞！

這在 IT 組織中是完全一模一樣的鏡像：

開放 AI 產碼 / 招募多元人力 = 開放廚餘養豬：追求效率與成本降低本來沒有錯。
缺乏 CI/CD 自動化測試與 Lint 審查 = 缺乏高溫蒸煮消毒：當團隊只追求快，把未經測試、未建立 Web Component Shadow DOM 強制隔離的 AI 亂碼直接 Commit 進主線（Main branch），就像把帶著病毒的廚餘直接餵給豬隻。
系統崩潰與泥潭爆發 = 非洲豬瘟全場感染：只要有一兩個人偷懶不蓋隔離邊界、不執行合規驗證，整個專案的 Codebase 就會瞬間陷入 Context Rot，牽一髮而動全身。

當一個企業或部門業務擴大，傳統的做法永遠是「加人」。為了快速填補人力缺口，組織開始大量招募：外包、正職、剛畢業的新人、轉職班的大軍、不同領域的專家，全都被一股腦塞進同一個團隊。

這不就是加拿大「家豬與野豬交配」的 IT 組織版嗎？

多方雜交的混亂生態：原本習慣「手搓 Code」、講求底層效能與演算法的核心工程師，碰上了「只會用 AI 生成程式碼」的新一代 Copy-Paste 工程師。兩邊的開發邏輯、品質標準與思維模式在專案裡激烈碰撞。
「垃圾政策」與「泥潭系統」的誕生：當偷懶不蒸煮的個案發生後，高層往往不是建立自動化的剛性檢驗，而是頒布各種僵化的 SOP、無意義的 KPI、以及繁瑣的人工開會審查政策。結果就是——程式碼裡充斥著未封裝的巨型元件，組織裡充斥著無效的會議與管理流程。

這種生態演替，也直接改變了工程師這個職業的本質。

過去的工程技術，講求的是「資工系思維」：精通記憶體管理、演算法複雜度、作業系統底層，習慣從零開始手搓每一行 Code。

但在 AI 算力爆發與組織規模化的今天，軟體工程正迅速「管院化」：

純手搓工程師的困境：習慣徒手搬磚、堅持一行行手寫的工程師，在 AI 產能大爆發的時代，產出速度被拉開量級差距，面臨被邊緣化的危機。
純 AI 依賴者的風險：只會用 Prompt 叫 AI 寫 Code、完全不懂背後原理與模組邊界的工程師，就像餵未蒸煮廚餘的豬農，產出的只是一堆無法維護且帶病運轉的雜訊。
管院化（Prompt & Process Management）的趨勢：現代工程師的核心能力，越來越像「管理學」——你必須建立「高溫蒸煮」般的自動化驗證流程、調度 AI Agent、定義 Data Contract、管理資源與團隊邊界，並確保產線運作順暢。

要打破「廚餘病毒」與「超級豬生態」的僵局，核心不在於「禁止使用 AI」或「全面禁止外包」，而是要建立剛性的「Harness 韁繩架構與蒸煮機制」：

用 Web Component 建立隔離區：無論是手搓還是 AI 產出的程式碼，都必須封裝在 Shadow DOM 後面，只暴露標準的 API 介面。確保外部雜訊不會感染全域系統。
用自動化 CI Loop（高溫蒸煮）代替垃圾 SOP：建立自動化測試閉環（Vitest / Playwright）與嚴格的 Lint / Type Check。沒有通過「高溫蒸煮」驗證的程式碼，絕對不允許 Merge 入庫！
升級為「AI 產線架構師」：資工系的底層邏輯（理解高溫蒸煮的檢驗標準）+ 管院的調度思維（指揮 AI 與流程設計），才是 AI 時代不被取代的雙刀流工程師。