在生成式 AI 工具（如 Copilot, Cursor, Claude Code）快速普及的今天，許多工程團隊發現雖然代碼產出量大增，但開發效率卻未必同步提升，甚至帶來了新的管理壓力。Kubernetes 共同創始人 Craig McLuckie 在與 InfoQ 的對談中，深入探討了 AI 如何衝擊開源社群、工程師的職業路徑，以及為什麼在 AI 時代，刻意設計的團隊文化比以往任何時候都更重要。
AI 對開源社群與工程實務的衝擊
對於初級工程師來說，開源社群原本是最好的學習場域。維護者通常會刻意保留一些簡單的 Good First Issues（適合新手的入門問題），讓新手透過修復小 Bug 來熟悉專案、建立信心並獲得資深開發者的指導。
然而，AI coding 工具的出現打破了這個生態。現在，許多人利用 AI 快速生成大量看似能解決問題、但缺乏品質且不符合專案規範的 PR（Pull Request，合併請求），這種現象被稱為 AI Slop（AI 產出的廢料）。這導致維護者被淹沒在海量的低品質代碼審核中，原本用來培育新手的路徑被堵塞，社群的信任與協作動能反而受損。
在企業內部，類似的情況也在發生。AI 讓寫代碼變得極其廉價，導致出現了巨型 PR 的回歸。過去二十年工程界努力推動小範圍、原子化的提交，但現在一名工程師可能在短時間內利用 AI 產出數千行代碼並提交。如果團隊缺乏足夠的流程成熟度，這種做法會將審核壓力轉嫁給同事，造成團隊內部的摩擦與疲勞。
工程師職能的轉型：從開發者變為管理員
AI 改變了工程師的工作本質。目前的 AI 工具就像一個極其熱情但缺乏智慧的實習生，能快速產出結果，但不能保證正確性。
這意味著工程師的角色正在從寫作者轉向審核者。開發者發現自己每天花更多時間在微觀管理（Micromanage）AI 產出的結果，而非親手創造。這種轉變會帶來情感上的疲勞，因為工程師原本的成就感來自於親手構建系統並深入理解其運作邏輯，而現在則變成了對 AI 產出進行風險控管與品質把關。
更令人擔憂的是初級工程師的成長路徑。傳統上，工程師透過撰寫單元測試、修復簡單 Bug 等基礎任務，逐步建立對複雜分散式系統的深刻理解。當這些基礎任務被 AI 取代，新一代工程師如何從學生成長為能設計大規模系統的專家？這是一個尚未有標準答案的挑戰。
將文化視為團隊的作業系統
面對技術工具的劇變，McLuckie 提出一個核心觀點：文化就是團隊的作業系統（Operating System）。
文化不應該是 HR 貼在牆上的口號，而是一套定義團隊如何處理資訊、如何做出決策的底層邏輯。它應該根據團隊的目標而定。例如，安全團隊的文化核心應是精準與謹慎；而初創團隊則應強調行動導向與緊迫感。
建立刻意設計的文化的實務建議
對於技術主管（Team Lead）而言，建立文化需要經過刻意的設計與持續的強化：
第一，定義文化錨點。透過訪談團隊成員，萃取出四到五個與任務目標一致的核心價值，作為團隊的行為準則。
第二，將文化融入制度。在招聘面試、績效評估與晉升標準中，將這些文化錨點納入考量，確保進入團隊的人與文化兼容。
第三，透過決策強化。當主管面臨困難抉擇時，應公開說明該決定是如何基於團隊文化而做出的，讓文化從抽象概念轉化為具體行為。
第四，避免偽善。偽善是文化的殺手。如果領導者的行為與宣稱的文化價值相悖，文化會立即崩潰。若業務需求改變導致原有的文化不再適用，必須坦誠地與團隊溝通並共同更新文化定義。
給新任技術主管的建議
在 AI 工具普及的環境下，新任主管應注意以下三點：
首先，不要讓 AI 取代你的指導職能。主管可能會發現利用 AI 自己寫代碼比指導團隊快，但主管的價值在於提升他人的生產力，而非成為最強的單兵。
其次，強調所有權（Ownership）。必須明確規定：無論代碼是由 AI 生成還是人工撰寫，提交者必須對其品質負全責。禁止將 AI 產出的 Slop 直接丟給同事審核，這會摧毀團隊信任。
最後，接納隨機性系統。在構建 AI Agent（智能體）系統時，傳統的指令式編程思維（Imperative Systems）不再適用。AI 系統具有隨機性（Stochastic），開發過程需要大量的實驗與嘗試，而非單純的設計圖繪製。
來源：infoq.com (Podcast: Craig McLuckie on Culture as a Team's Operating System in the AI Era)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。