AI 運行的環境和執行的任務都過於「無菌」，與現實世界有一定的差落差。
本篇參考自史丹佛大學的研究員 Yegor Denisov-Blanch 的研究成果，完整演講也已公布《Does AI Actually Boost Developer Productivity?》
Denisov-Blanch 發現，目前業界所宣稱 AI 能帶來的「生產力榮景」，其實過於誇大也同時忽略了背後的隱藏成本。更重要的是，AI 運行的環境和執行的任務都過於「無菌」，與現實世界有一定的差落差。
生產力的迷思
關於 AI 如何影響開發者生產力的現有研究，大多存在三個關鍵性限制，嚴重削弱了這些研究在真實世界中的可靠性與適用性。
衡量指標的錯誤
許多研究將提交次數（commits）、pull requests 或完成的任務數視為生產力指標，假設「更多的活動」就等於「更高的生產力」。然而，這種方法根本誤解了軟體開發工作的本質。
不同任務的複雜程度差異極大，提交次數增加並不必然意味著真正的效率提升。Stanford 的研究甚至揭示了一個令人憂慮的現象：
AI 經常產生額外任務，因為它本身先寫出有缺陷的程式碼，隨後又需要人類開發者進行修補。
結果導致開發者看似更忙碌，實際上卻在無效循環中打轉。
研究設計的人工化
大多數受控實驗會將開發者分成兩組，一組使用 AI 工具，另一組則不使用，然後要求雙方完成「greenfield」任務：從零開始開發全新專案、完全沒有既有上下文。在這類情境中，AI 確實經常表現優於純人類方法。
但問題在於，這樣的情境與現實世界的軟體開發差距甚大。專業程式設計通常涉及既有的程式庫、複雜的依賴關係，以及長期演化而成的業務邏輯。實驗室裡這種「無菌環境」根本無法反映真實的開發挑戰。
過度依賴自我回報的調查
Stanford 研究團隊曾要求 43 名開發者自行評估相對於全球平均的生產力，並將自己放入五個百分位區間之一。
結果顯示，自我評估與實際測量數據的相關性極差，幾乎等同於「擲硬幣」。開發者平均誤判了約 30 個百分位點，只有三分之一能正確估算自己大致所在的區間。
調查雖然仍然有助於理解開發者對 AI 工具的滿意度與士氣，但顯然不能可靠衡量實際生產力影響。這一發現對眾多依賴自我調查報告來支持 AI 成效論述的產業研究，具有重大挑戰意義。
許多研究將提交次數（commits）、pull requests 或完成的任務數視為生產力指標，假設「更多的活動」就等於「更高的生產力」。
重構四大衡量指標
認知到上述限制後，Stanford 提出了更精緻的方法，超越了單純的「程式碼行數」或「提交頻率」。他們的方法核心在於 分析程式碼變更實際交付的功能性，而不是僅僅看表面上的活動量。
理想的測量系統應由 10 至 15 位資深工程師組成專家小組，從多個面向獨立評估每段程式碼：品質、可維護性、輸出價值與實作時間。
為了解決此問題，Denisov-Blanch 的團隊開發了一套能自動模擬專家評估的模型。該系統與 Git 儲存庫整合，能分析每次提交的程式碼變更，並在與人類專家相同的維度上進行量化。
這套方法揭露了傳統簡單指標無法察覺的生產力模式。系統將程式碼變更分為四種類型：
- 新增功能（added functionality）
- 刪除功能（removed functionality）
- 重構（refactoring）
- 返工（rework，修復最近的程式碼，通常代表浪費性活動）
透過這種細緻的分類，AI 導入的隱性成本與收益才得以被完整揭示。
生產力提升伴隨隱藏成本
當 Denisov-Blanch 將這套方法應用於跨公司 AI 導入案例時，結果顯示出比廠商宣稱的「單純效率提升」更加複雜的面貌。
一個典型案例是一間擁有 120 名開發者的公司，在九月全面導入 AI 工具。表面數據看來成效顯著：
程式碼輸出量大幅增加，提交次數與開發活動大幅提升。
然而，深入分析卻揭露了令人憂慮的模式：雖然總產出激增，但其中很大一部分來自「返工」 開發者需要修復近期 AI 所生成的程式錯誤。
數據顯示，AI 導入通常會帶來 30–40% 的「總生產力提升」，也就是開發者確實產生了更多程式碼。但若考慮修復與調整所耗費的額外時間，「淨生產力提升」平均僅為 15–20%。這中間的落差，正是 AI 的隱性成本：
即處理 AI 初稿錯誤所需的額外工作量
這也解釋了為什麼許多組織在導入 AI 後，感覺「比以前更忙」，卻不覺得「完成得更多」。開發者確實寫了更多程式、處理更多任務，但其中相當部分只是清理 AI 自己製造的問題。
開發者確實寫了更多程式、處理更多任務，但其中相當部分只是清理 AI 自己製造的問題。Photo by Procreator Global UI UX Design Agency on Unsplash
AI 不擅長維護與除錯
Stanford 的分析指出，AI 的效能與任務複雜度高度相關，結果挑戰了業界對 AI 工具適用範圍的常見假設。
在 低複雜度任務 中，AI 的優勢顯著，尤其是在 greenfield 專案中（從零開始建立新系統）。當開發者處理簡單、定義明確的新問題時，AI 能帶來 30–40% 的效率提升。這正好符合 AI 的強項：
模式識別、樣板程式碼生成、以及標準演算法與資料結構的實作。
然而，Denisov-Blanch 指出，隨著任務複雜度增加，AI 的效能顯著下降。
在 高複雜度的 greenfield 任務 中，效率提升僅剩 10–15%；而在 高複雜度的 brownfield 開發（即在既有程式基礎上進行維護與擴充）中，效益僅有 0–10%，甚至有些情況會導致效率下降，因為開發者花在修正 AI 錯誤的時間超過了原本的時間。
研究還揭示了 greenfield 與 brownfield 的重要差異。greenfield 開發由於缺乏既有上下文與歷史依賴，AI 能發揮更大作用（AI 能發揮的自由度更大）。
但現實世界更大量出現的專案型態卻是 brownfield 開發，AI 工具往往難以理解既有程式架構、遵循既有模式與慣例、並在複雜依賴關係中正確運作。
Denisov-Blanch 也解釋，這就是為什麼許多有經驗的開發者對 AI 工具有著複雜感受：
AI 在「全新功能開發」這類少數情境下相當有用，但對「維護、除錯與改進既有系統」這類佔大多數的任務，幫助卻十分有限。
