編按：本文綜合整理自 ACM Queue《Eight Myths on Software Engineering and GenAI》、DX 工程部落格 Brian Houck 摘要，並加入 Siami 編輯部觀點與分析。原文作者群包含 Jenna Butler、Margaret-Anne Storey、Travis Lowdermilk、Emerson Murphy-Hill 等微軟研究院與學界知名學者。
一篇六月登上 ACM Queue、由微軟研究院與學界共同執筆的論文，最近在 Hacker News 上以 124 分、81 則留言登上頭版，被工程主管圈視為「給 GenAI 投資熱潮的冷水」。論文用近兩年的大規模研究、開發者訪談與田野觀察，整理出圍繞 GenAI 與軟體工程的八個最常見迷思——從「開發者一天到底在寫多少 code」、「AI 寫 code 越快等於交付越快」，一路到「10× 工程師真的存在嗎」、「AI 會取代工程師嗎」。
作者群寫得很直白：「GenAI 正在重塑軟體工程，但敘事已經失控。」 這八個迷思橫跨三個層次——開發者真正花時間的地方、AI 衝擊的衡量方式、以及 AI 在真實組織裡的落地方式。下面把整篇論文重點整理給沒時間讀完 30 頁的讀者。
迷思 1：開發者大部分時間在寫程式
這是整篇論文最常被引用的數字：開發者一天只有 11-18% 的時間在「寫程式」——其餘是設計、會議、code review、跨組溝通與行政瑣事。微軟內部 2025 年一項針對大量工程師的研究，得出更精確的 14% 這個平均數。
這個數字本身不新——過去十年的人類工時研究反覆驗證過類似的比例。但論文把它放進「AI 投資回報」的脈絡：如果寫 code 只占一天 14%，那把「寫 code」自動化的 GenAI 工具，天花板也就 14% 上下。 這跟業界一直喊的「Copilot 讓生產力提升 55%」之類行銷話術有明顯落差。
「把 AI 當 code generator 來看，槓桿比媒體講得要小。」——原文段落翻譯
DX 公司 2026 年 Q2 報告呼應這個結論：典型企業導入 AI 工具後，code 吞吐量只增加 7.8%——不是 2×、不是 10×、是 7.8%。而且這 7.8% 還不是淨值——下游瓶頸會吃掉一部分。
迷思 2：寫 code 是瓶頸
既然寫 code 只占 14%，那把這 14% 加速 5 倍，整體工作能不能加速 14%？不一定。
論文舉了一個內部 AI coding agent 的實例：跑一陣子之後，只有約一半的 PR 最終被 merge，15% 被放棄，15% 卡在等 reviewer。 換句話說，當你加速「寫 code」那一段，瓶頸會往後移到 review 跟整合。Amdahl 定律在開發流程裡一樣適用。
更糟的是沒被消化的存量：當 agent 一個下午丟出 20 個 PR 給 reviewer 看，reviewer 變成新的瓶頸。微軟的 field data 顯示，code review 的負擔直接膨脹，等於把省下來的時間又還回去。
迷思 3：用行數衡量生產力
這條論文呼應三十年前 Bill Gates 的那句名言：
「用程式行數衡量軟體生產力，就像用飛機多重來衡量它飛了多遠。」—— Bill Gates
但 2026 年的工具廠商仍然在推「AI 生成多少行 code」這種指標。論文直接點名：把 AI 生成行數當 KPI 衡量生產力，會誘導工程師為了數字膨脹程式碼、繞過 review 流程，最後反而增加 review 跟品質成本。
替代方案是 PR Throughput（PR 完成量）——把「被 merge 的 PR」當成更完整的 work 單位。DX 公司長期推這個指標，但它仍然要在 AI 時代小心：純 throughput 一樣會掉進「為了衝量而衝量」的陷阱。論文推薦的是「DX Core 4」這類多重指標框架——結合 DORA、SPACE、DevEx 跟 AI-specific metrics。
迷思 4 與 5：AI 效果穩定 10×、AI 讓資深跟 junior 一樣強
論文把這兩個合併處理，因為它們犯的是同一個錯：把研究結果一般化。
事實上，GenAI 對開發者的效果研究高度分歧：
- 有些研究看到顯著加速
- 有些研究看到中性效果
- 一份針對資深開源貢獻者的研究甚至發現，AI 工具讓他們的實作時間平均增加 18%
變異不是隨機的：
- 熟悉任務獲益大於陌生任務
- 開發者經驗、動機、解題風格都會影響結果
- 連 prompt 都有差——一份研究發現語意等價的改寫 prompt，在 46% 的情況下產出不同 code，在 28% 的情況下影響正確性
至於「10× 工程師」這個敘事，論文直接說它站不住腳。在孤立、玩具規模任務上量測出來的生產力提升，到真實 codebase 跟真實團隊裡幾乎不會存活。 過去文獻也指出，開發者之間的差異大部分是任務特性造成的，不是人的特性。
迷思 6-8：採用率 = 採用深度、信任 = 採用、靠工程師自己衝就好
這三條是論文最尖銳的部分。媒體跟工具廠商常引用「80% 開發者已經在用 AI 工具」這種採用率當作成功指標，但論文點出三個被忽略的層次：
信任落差
「80% 開發者在用 AI 工具，但只有 29% 信任 AI 工具的正確性。」
採用不等於信任。這 51 個百分點的差距，就是企業每天看著 license 費燒掉但看不到 ROI 的原因。
能力懲罰（Competence Penalty）
近期研究發現一個微妙的偏誤：開發者——尤其是女性跟年長工程師——在使用 AI 輔助產出時，即使成品一模一樣，也會收到更嚴厲的評價。 這條直接挑戰「AI 工具是平等賦能者」的敘事。
個人 vs 系統
過去軟體生產力的真正提升，從來不是靠個別開發者優化自己的工作流，而是組織層級的系統性變革。但幾乎所有現有的 AI 開發研究，都在研究**「一個開發者配一個工具」**這種一對一場景，把生產力負擔丟回個人。
論文直接下這個結論：
「AI 可能是第一種技術——企業在還沒想清楚怎麼從它身上榨出價值之前，就花了好幾百萬買 license。」
為什麼這件事重要
這篇論文對 Siami 讀者群（台灣與中文圈的工程主管、AI 工具採用決策者、創業團隊）有三個立即的現實意義：
第一，「AI 把開發者變 10× 工程師」這種行銷話術，在 2026 年中已經被主流學術研究正式打臉。如果你正在評估要不要導入 AI 工具、或者已經導入但看不到效果，這篇論文提供了 8 個具體的「問錯問題」清單，幫你重新對齊預期。
第二，行數 / PR 量 / 採用率這三個最常見的 AI ROI 指標，論文都明確指出它們的盲點。對工程主管來說，這是一份難得的「指標防呆手冊」。
第三，「採用率 80% 但信任只有 29%」這個數字，幾乎可以解釋台灣企業導入 AI 開發工具後的普遍困境——license 買了、員工也在用，但產出品質沒提升。問題不在工具，在信任建立跟工作流程重構。
對工程師個人來說，論文也提供了一個保護機制：當你被要求用「AI 生成行數」當 KPI，或者當你發現自己的 AI 輔助工作被比別人嚴格審查時，你可以拿這篇論文當後盾。
數據解讀 / 質疑
幾個值得進一步追問的點：
- 14% 寫 code 比例的樣本偏差：微軟內部的研究對象主要是大型企業的軟體工程師，對 startup、新創、外包團隊不一定適用。新創工程師的一天可能 60% 都在寫 code，因為沒有那麼多 cross-functional meeting。
- Amdahl 定律的適用邊界：論文把「加速 14% 那一塊、整體上限 14%」這種線性模型套上去，但真實 AI agent 已經跨進 review、test、debug 環節（即 86% 那一塊）。HN 留言 armitron 直接質疑：「這篇讀起來像 2026 年在批評 2023 年的工具。」
- METR 研究引用問題：HN 留言 mkozlows 指出，論文引用的那份「2025 年初 METR 開發者生產力研究」其實有重大方法論爭議（樣本偏差、自選 bias），但論文把它當作「最近一份研究」使用，措辭略嫌過時。
- 缺少正面案例：論文幾乎沒有列舉「哪家公司具體怎麼用 AI 工具拿到真實 ROI」的成功案例。批評容易，建設性方案難。期待後續 ACM Queue 刊出 companion piece。
編按：本文綜合整理自 ACM Queue 原文、DX 工程部落格、Hacker News 49176830 討論串，並加入 Siami 編輯部觀點與分析。Siami 編輯部對原論文持「引用但保留質疑」立場——這是一份重要的「指標防呆」參考，但對 Amdahl 線性模型套用、引用研究的新舊程度等，仍有可議之處。
網友熱門留言 (5)