谷歌50%代碼靠AI寫，交付速度反而跌了

AI工具幫谷歌寫了50%的代碼，微軟也有30%。這個數字放在三年前，足夠讓CTO們集體高潮。但一個反常識的事實是： shovelware（粗制應用）沒有爆發，反而在減少。更扎心的是，越來越多工程師覺得AI在拖慢他們。

Stack Overflow去年調研了3萬多名開發者，45%的人把"調試更耗時"列為AI帶來的最大痛點。不是AI寫得慢，是工程師讀不懂AI寫的代碼。就像你讓實習生一夜趕出80頁PPT，第二天匯報時你根本接不住話。

代碼膨脹：AI的"數字肥胖癥"

PlayerZero團隊追蹤了一個典型現象：某團隊用AI輔助后，代碼提交頻率飆升300%，但生產事故響應時間從平均2小時拉長到6小時。問題不是出在AI生成環節，是出在后邊的消化環節。

工程師Spencer在內部復盤會上打了個比方：「以前我們像手藝人，工具是錘子和鑿子；現在像指揮交響樂團，但樂譜是AI即興寫的，你還得實時判斷哪個音符會走調。」

數據印證了這個困境。GitClear分析過1.5億行代碼變更記錄，發現AI輔助代碼的"代碼流失率"（上線后6個月內被重寫或刪除的比例）比人工代碼高出37%。換句話說，AI在批量生產技術債，而技術債的利息是復利計算的。

調試地獄：不熟悉的地形最耗體力

傳統開發中，調試約占30%工時。AI時代這個比例被打破了——不是降低，是結構性地轉移了。以前是"我寫我修"，現在是"我猜我修"。

一位在微軟Azure團隊工作的工程師描述過典型場景：凌晨2點，告警響起。他點開代碼，發現核心邏輯是三個月前Copilot生成的，自己只做過表面審查。「就像走進別人家廚房找鹽，你知道肯定有，但每個抽屜都得翻一遍。」

Stack Overflow的調查里還有個細節被忽視了：62%的開發者承認，他們會因為"代碼不是自己寫的"而傾向于整體重寫，而非局部修復。這種心理成本沒有被任何效率計算器收錄。

工具鏈的"最后一公里"陷阱

AI編碼工具的商業模式有個先天缺陷：它們按"生成token數"或"使用時長"收費，天然鼓勵多寫、快寫。但軟件工程的真實成本從來不在"寫"，在"維護"。

PlayerZero的觀察更尖銳：當前AI工具解決的是"打字速度"，不是"思考速度"。當工程師把認知負荷從"設計"轉移到"審查"，整體系統風險在上升——因為審查比設計更容易走過場。

谷歌內部有個未公開的指標叫"代碼理解深度"，用AI輔助的模塊得分平均比人工模塊低22個百分點。這個數字沒有出現在任何財報里，但出現在無數次延期評審會的PPT腳注中。

組織層面的"代謝綜合征"

更隱蔽的問題在團隊層面。當AI成為默認選項，"代碼所有權"這個概念正在瓦解。

Netflix工程師曾分享過一個案例：兩個團隊合并后，發現核心服務里有40%的代碼找不到明確負責人——不是沒寫名字，是寫名字的人自己也認不出那是自己"審批"過的AI產出。「就像檔案館著火，你沖進去救文件，發現每份都蓋著章，但沒人知道章是誰刻的。」

這種模糊性直接推高了協作成本。原本5分鐘能確認的改動，現在需要跨3個時區拉會對齊。AI省下的打字時間，加倍償還給了組織溝通。

PlayerZero的結論是克制的：AI編碼工具的價值不在"更快交付功能"，在"降低特定類型任務的門檻"。把兩者混為一談，是過去三年行業最大的集體幻覺。

他們給出的建議也反直覺——不是少用AI，是更刻意地保留"人工痕跡"：強制要求工程師手寫核心邏輯的偽代碼，再讓AI填充；建立"代碼口述歷史"機制，每個模塊必須附3分鐘講解視頻；把代碼審查從"批作業"改成"結對考古"。

這些做法都在承認一件事：軟件工程的瓶頸從來不是打字速度，是人對系統的理解深度。AI可以幫你跳過打字，但跳不過理解。

那位Stack Overflow的受訪者最后說了句被調研報告埋在第47頁的話：「我現在寫代碼的時間確實少了，但做夢都在想那些我沒寫過的代碼會不會在凌晨3點崩掉。」

當50%的代碼來自AI，你的焦慮是減半了，還是翻倍了？