程式碼行數的回歸：AI 虛榮指標 vs. 工程成果

AI 生產力聲稱正從成果轉向數量

軟體工程產業目前正經歷「程式碼行數」(LoC) 作為主要生產力指標的復興，並被重新包裝為 AI 生成程式碼的百分比。雖然產業在過去幾十年中一直致力於擺脫以數量為基礎的指標，但目前主要 AI 供應商的聲稱幾乎完全集中在產出的程式碼量，而非交付的價值。

近期產業聲稱凸顯了這種向數量的趨勢：

這些數量聲稱與早期的「成果」聲稱有本質上的不同。例如，早期的 GitHub Copilot 研究關注於開發者完成任務的速度提升了 55%——這是一個關於價值與速度的可證偽聲稱。相比之下，聲稱 AI 撰寫程式碼的百分比是一種虛榮指標；無論軟體品質、交付速度或客戶滿意度是否提升，它都可以無限增加。

交付的程式碼量與組織生產力的可衡量影響之間存在顯著差距。雖然有些研究顯示有增益，但其他研究則顯示品質下降或對整體速度的影響呈中性。

正面增益: Cui 等人的研究涉及近 5,000 名開發者，發現任務完成度提升了 26%，其中在初級開發者中觀察到的增益最為顯著。
品質疑慮: GitClear 的數據顯示，隨著 Copilot 的採用程度加深，程式碼變動量 (code churn) 正在上升，而重構 (refactoring) 卻在萎縮。
METR 研究悖論: METR 在 2025 年初的一項研究發現，經驗豐富的開源開發者在使用 AI 於其自身的程式碼庫時，速度反而慢了 19%，儘管他們認為自己變快了 20%。到 2026 年 2 月，METR 更新了其立場，暗示 AI 可能確實提升了開發者的速度，但指出研究設計必須被迫放棄，因為開發者現在拒絕在沒有 AI 的情況下工作，這使得精確的衡量變得不可能。
高管層視角: 一項針對約 6,000 名高管的 NBER 調查發現，雖然 69% 的公司使用 AI，但約 90% 的人報告沒有可衡量的生產力影響，跨研究的共識建議組織增益約為 10%。

即使是推廣高產量的公司，也發現了品質上的權衡。Anthropic 自身進行的一項隨機對照試驗 (RCT) 發現，AI 輔助的開發者在對剛交付的程式碼理解力得分上低了 17%，且沒有統計學上顯著的生產力增益。

當數量指標被用來證明裁員的合理性時，它們往往掩蓋了其他的商業動機。聲稱 AI 生產力允許使用更小的團隊來工作，經常被用作裁員的論點，然而在產品驅動且擁有無盡產品路線圖的公司中，幾乎沒有證據顯示 AI 已經創造了真正的閒置產能。

近期範例包括：

Block: Jack Dorsey 在 2026 年 2 月裁掉了超過 40% 的員工 (4,000 多人)，理由是使用 AI 工具的小型團隊可以「做更多且做得更好」。
Atlassian: 裁員 10% (~1,600 人)，承認 AI 改變了所需的技能組合與職位數量。

批評者認為，如果 AI 真的提供了「免費的人力增益」，公司應該使用該產能來交付更多客戶價值（例如增加 MAU、轉換率或營收），而不是減少人員。這表明生產力聲稱可能只是在為那些因疫情期間過度招聘而產生的決策（或投資者壓力）進行公關宣傳。

採用 AI 工具對於現代工程速度是必要的，但採用只是起跑線，而非計分板。為了避免虛榮指標的陷阱，組織應該回歸到既定且基於成果的衡量標準：

DORA Metrics: 關注於部署頻率、變更引導時間 (lead time for changes)、變更失敗率以及服務恢復時間。
Reliability and Stability: 衡量有意義的變動率以及錯誤 (bugs) 的減少。
Business Value: 追蹤營收、收入、客戶獲取與轉換率。
Code as a Liability: 將程式碼行數的觀點從資產轉向成本。正如社群洞察指出，程式碼應該被視為要實施一個功能而支付的代價；目標是用最少的必要程式碼來達成預期成果。

資深開發者之間的討論凸顯了當前 AI 編碼趨勢的幾個關鍵風險：

"程式碼行數是衡量編程進度的方式，就像是用重量來衡量飛機製造的進度一樣。"

"如果你用 LoC 和 token 使用量來衡量生產力，開發者就會把 LoC 和 token 使用量刷到最高！這太可預測了，我們甚至有一條定律來命名這種現象！"

其他貢獻者指出，「瓶頸」不再是撰寫寫程式碼，而是人類的理解與審查 (review) ability 進行審查與理解的能力。真正的擔憂指標應該是「未經人類審查或理解的程式碼百分比」，因為 AI 允許快速產出大量無法維護的程式碼，其速度可能超過人類的理解力。