AI 時代的工程團隊，問題從來都不是技術

> Meta Shift

我的判斷很直接：AI 工具讓個人工程師的生產力提升了，但同時也讓團隊裡的人性問題更難被忽視。以前你可以用「大家都很忙」當藉口，現在 AI 把重複性工作清掉之後，剩下的全是需要人跟人協作才能解決的問題。Cat Hicks 這本《The Psychology of Software Teams》出得很是時候 — 不是因為它很潮，而是因為工程界終於有人用科學數據在講這件事，不是靠感覺、不是靠 agile 教練的直覺。

這本書的作者 Cat Hicks，UC San Diego 量化實驗心理學 PhD，創辦了 Catharsis 這個科學顧問公司，做的事情是幫組織用人本證據驅動轉型。這不是一個純粹賣管理學課程的人在寫的書，數據是從頂尖工程組織和全球數千名工程師身上蒐集來的。

---

你現在在工程團隊裡看到什麼？

我最近看到的現象有幾個層次：

第一層：個人生產力數字好看，團隊交付卻沒有等比例提升。

GitHub Copilot 在 2022 年的研究數據顯示，使用 AI 輔助的工程師完成任務的速度快了 55%。（來源：GitHub 官方研究報告）這個數字很漂亮，但同一家公司的產品還是照樣 delay，bug 還是照樣從 staging 流到 production。個人 velocity 跟團隊 throughput 之間有一條鴻溝，沒有人認真去量那條鴻溝有多寬。

第二層：code review 的 dynamic 正在變得很奇怪。

現在很多 PR 是人跟 AI 合寫的。reviewer 不確定他在 review 的是工程師的判斷還是 AI 的輸出，被 review 的人也開始對 feedback 不太確定要怎麼回應 — 「這個問題是 AI 生的，不算我不懂」。這聽起來很蠢，但我確實在幾個工程師社群裡看到這類對話。accountability 變模糊了，而 accountability 模糊的地方，文化就開始爛。

第三層：「10x Engineer」的迷思被 AI 具象化了，然後炸開了。

過去「10x Engineer」是個神話，大家心知肚明這個說法主要是用來合理化某些人的自大行為。現在有了 AI，真的有人因為工具用得好，在短時間內產出十倍的 code volume。然後主管不知道該怎麼評估這件事，其他工程師也不知道這是否代表自己的績效很差，團隊裡的比較焦慮開始發酵。Cat Hicks 在書裡有一章叫「More Bands and Fewer Rockstars」，就是在戳這個問題 — 搖滾明星文化在軟體業一直是個毒瘤，AI 把這個毒瘤放大了。

---

為什麼技術問題往往是人的問題？

這讓我想到 2010 年代初期 DevOps 剛興起的時候。當時大家的問題不是沒有工具 — Jenkins、Chef 都已經存在了。問題是 Dev 和 Ops 兩個部門的人不說話，文化上互相甩鍋，工具再好也沒用。解決 DevOps 問題的不是更好的 pipeline，是讓兩個部門的人開始共同承擔 on-call 責任，讓他們有理由坐下來講話。

現在的 AI 導入也是同樣的邏輯。你可以買最貴的 AI coding assistant，但如果你的 team lead 對 AI 生成的 code 有隱性偏見、或者你的資深工程師把 AI 當成是「讓初級工程師失業的威脅」，這些工具的 ROI 就會遠低於預期。

Cat Hicks 在書裡拆解了幾個關鍵的心理機制：

The Performance Paradox（第四章）： 工程師在被評估績效的時候，反而會迴避有學習價值的挑戰性任務，選擇自己熟悉、有把握的事。AI 工具的引入沒有解決這個問題，甚至可能強化了它 — 因為現在你有更多 cover 可以讓「看起來很忙」變得更容易。

Psychological Safety 不是 HR 的事： 書裡引用的研究數據（基於 Google 的 Project Aristotle 以及 Hicks 自己的研究）指向同一個結論：team psychological safety 是預測工程團隊效能最強的單一因子，比技術 stack、比工程師個別能力都更有預測力。（來源：Google re:Work、書中研究）但在我看到的大部分工程組織裡，psychological safety 要不是被當成 buzzword 貼在牆上，要不就是被完全忽略。

Conflict or Coalitions： 這是第五章的主題，核心問題是：你的團隊在面對衝突的時候，是真的在解決技術或方向上的分歧，還是在玩政治？工程師很擅長把「我不喜歡這個人」包裝成「這個 architecture decision 有問題」。AI 工具的引入，因為它改變了每個人的工作方式，會觸發更多這類隱性衝突。

老實說，這不是什麼新問題。Frederick Brooks 在 1975 年的《The Mythical Man-Month》就講過了 — 軟體開發不是線性擴展的，加人不等於加速，因為溝通成本是 O(n²)。快五十年後的今天，我們把人換成 AI，溝通成本的結構沒有根本改變，複雜度倒是又多了一層。

---

Meta 判讀：這是 Meta Shift，不是 Patch Note

我的判定是 Meta Shift，原因有三：

第一，問題的暴露速度加快了。 AI 工具清掉了大量的瑣碎工作，讓工程師有更多時間面對真正的軟體設計和人際協作問題。過去你可以靠「大家都很忙」掩蓋文化問題，現在這個藉口越來越難用了。