軟體工程中關於生成式 AI 的八個常見迷思 – 基於證據的反駁

迷思 1 – 開發者大部分時間都在寫程式碼

重點： Microsoft 及其他地方的實證研究一致顯示，開發者僅花費工作日的約 14% 用於輸入程式碼。大部分時間都投入在設計、會議、規劃和程式碼審查。

一項針對 >450 名工程師的 2025 年 Microsoft 遙測研究報告顯示，寫程式時間為 14%，「表現良好」的日子為 18%，「表現不佳」的日子為 11%【13】。
一段 2025 年 6 月的訪談引言說明了同樣的觀點：「我確實花了很多時間在設計……一週內花在寫程式碼的時間感覺相對較少。」
Hacker News 的評論者也呼應了這一發現；幾位報告稱，在計算整合測試後，個人的寫程式比例介於 30-40% 之間，但仍強調大部分的精力花在其他地方。

啟示： 僅能加速打字的 AI 工具，最多只能影響整體工作流程中極小的一部分。

迷思 2 – 寫程式碼是瓶頸

重點： 即使將 14% 的寫程式部分提速 2 倍，產出總體生產力也僅增加不到 15%，因為剩餘 86% 的任務（設計、環境設定、測試、整合）主導了開發週期。

文章指出，較快的程式碼生成僅僅是將壓力推向下游，增加了審查和測試的負擔。
一位 Hacker News 評論者觀察到，AI 生成的程式碼通常與其他任務並行，但對總週期時間的淨影響仍然有限。

啟示： 組織必須解決「外迴圈」（需求、架構、測試）才能實現實質的交付速度提升。

迷思 3 – AI 生成的程式碼行數 (LOC) 可以衡量影響力

重點： LOC 是衡量生產力的一個在統計上無效的代理指標；追蹤 AI 生成的 LOC 可能會激勵浪費性的寫程式行為，並掩蓋真正的成果，如品質、安全性與可維護性。

一項 2014 年的統計研究得出結論，LOC 未能通過有效性測試，且效用有限【2】。
公司（例如 Microsoft）已公開報告 AI 生成的 LOC，但該指標與軟體品質或商業價值並不相關【2】【7】。
評論者警告，依賴 LOC 會導致「投機」行為和有毒的文化。

啟示： 成功指標應專注於以結果為導向的指標（缺陷密度、週期時間、用戶滿意度），而非原始程式碼量。

迷思 4 – AI 對所有任務和工程師的幫助程度相同

重點： GenAI 的有效性因任務類型、開發者經驗、提示詞工程（prompt-crafting）技能以及對程式碼庫的熟悉程度而有巨大差異。

2024 年 Microsoft AI-Productivity Report 發現，在熟悉的、理解透徹的任務以及具有先前 AI 經驗的開發者身上，增益較大【6】。
研究報告顯示效果不一：在某些情境下增益巨大，在其他情境下則影響中立甚至產生負面影響【4】【5】【3】。
提示詞重寫在 46% 的案例中改變了生成的程式碼，在 28% 的案例中改變了正確性【12】。
Hacker News 的討論強調，資深開發者在使用 AI 時有時會看到實作時間變慢，證實了對情境的依賴性。

啟示： 團隊應識別高影響力的任務（例如：樣板程式碼、重複模式）並投資於提示詞工程培訓。

迷思 5 – AI 能將開發者轉變為 10 倍效能的「超級工程師」

重點： 報告中提到的 10 倍生產力增益僅限於針對狹窄任務的受控實驗，無法擴展到現實世界的協作軟體專案。

文章引用了一項特定研究中 55% 的生產力增益，但指出協調、審查和整合的開銷抵消了個人的加速效果。
Hacker News 用戶報告了混雜的經驗：有些人看到了團隊規模縮減和更高的開發速度，而其他人則觀察不到可衡量的變化。

啟示： 預期管理至關重要；AI 是生產力輔助工具，而非團隊合作和系統級工程的替代品。

迷思 6 – 個別工程師必須讓 AI 發揮作用

重點： 歷史性的生產力增益源於系統性的、全組織範圍的變革，而非孤立的工具採用。

Cal Newport 對流水線的類比強調，「優化系統」需要投資、流程重新設計和文化轉變【16】。
文章認為，在沒有明確使用指南的情況下花費數百萬美元購買 AI 授權，產生的回報微乎其微。
Hacker News 評論指出，「自動化 AI 使用的組織政策與程序」比讓個人自行採用更有效。

啟示： 領導者應重新設計工作流程、提供培訓並將 AI 嵌入 CI/CD 流水線，而不是依賴臨時的個人使用。

迷思 7 – 高性能的 AI 工具將被自動採用

重點： 採用過程受到信任缺失、能力懲罰和社會心理障礙的阻礙。

一項 2025 年的研究發現了「能力懲罰」現象，女性和年長工程師在 AI 輔助工作方面會受到更嚴厲的評價【1】。
儘管 80% 的人已使用過這些工具，但僅有 29% 的開發者信任 AI 的輸出；許多人在除錯 AI 生成的程式碼上花費的時間比自己寫程式碼還要多【20】。
Hacker News 參與者提到「倫理疑慮、對技能退化的恐懼以及缺乏學習時間」是採用障礙。

啟示： 成功的推行需要透明的評估、包容性的培訓以及呈現 AI 置信度分數（confidence scores）的機制。

迷思 8 – 企業可以以新創公司的速度利用 GenAI 進行創新

重點： 結構性差異——遺留程式碼、監管限制和規模級別的可靠性要求——阻礙了大組織達到新創公司的速度，即使使用 AI 也是如此。

新創公司在與 LLM 訓練數據一致的開源技術棧上進行訓練；企業則依賴專有的、未記錄的程式碼庫。
合規性、安全性與向後兼容性的義務增加了不可逾越的開銷。
一位 Hacker News 評論者指出：「AI 可以縮短需求-開發-測試-部署的迴圈，但輸出 $\neq$ 結果」——最終產品仍必須符合企業標準。

啟示： 企業應針對特定階段（例如：自動化測試生成）尋求 AI 驅動的改進，而不是期待全面的加速。

社群洞察綜合

並行工作流程： 幾位評論者觀察到，AI 讓他們可以在專注於設計或研究的同時運行程式碼代理（coding agents），有效地使任務重疊。
不斷演進的證據基礎： 一些用戶指出，隨著模型的改進，所引用的研究會迅速過時；持續的測量至關重要。
文化阻力： 多種聲音提到「炒作疲勞」以及對供應商敘事的懷疑，強化了基於證據採用的必要性。
指標對齊： 一個反覆出現的主題是「輸出」指標（LOC、Token 使用量）與「結果」目標（品質、安全性、商業價值）之間的不匹配。

給領導者的實務建議

衡量重要的事物： 追蹤缺陷率、交付週期和用戶影響指標，而不是 AI 生成的 LOC。
識別高影響力任務： 在研究顯示增益最大的領域（如：樣板程式碼、測試腳手架和文件）部署 GenAI。
投資系統性變革： 重新設計程式碼審查、CI 流水線和入職流程，將 AI 輔助作為共享資源嵌入其中。
建立信任： 提供置信度分數、審計追蹤和明確的指南，以減輕能力懲罰。
持續迭代： 建立反饋迴圈，隨著模型的演進和新研究的出現，重新評估 AI 的影響。

結論

ACM Queue 文章中檢視的八個迷思揭示了生成式 AI 是一個強大但有限的工具。它的影響受到開發者實際寫程式時間比例極小、LOC 基準指標不足，以及需要全組織工作流程重新設計的限制。當 AI 被選擇性地應用、針對以結果為導向的 KPI 進行衡量，並得到文化與流程變革的支持時，真正的生產力增益才會出現。