AI生產力陷阱：更多的產出

AI使得生成代碼、草擬工單、總結會議和撰寫提案變得極為便宜。但更便宜的生成並不意味着工作實際上完成得更快。更多的原始產出意味着更多的審查、更多的驗證和更多的下游清理，這是不可避免的趨勢。如果獲得正確的拉取請求合併或合理工程決策的總時間沒有改善，那麼引擎只是在產生更多噪音。實際交付速度並未改變。

我們必須區分產出、吞吐量和成果。產出是我們生成的原始工件。吞吐量是通過交付系統成功移動的經過驗證的工作。成果是正確的決策或安全的生產變更。AI增加了個人產出，但往往使吞吐量和成果保持平坦。

這一差距在最近一項關於經驗豐富的開源開發者的METR研究中得到了凸顯。當開始使用這些工具時，開發者預測AI會將他們的任務時間減少近四分之一。即使在研究之後，他們仍然主觀上感覺節省了時間。但現實世界中的測量結果恰恰相反：當開發者被允許使用AI工具時，任務耗時增加了19%。研究人員表示，標準的產出衡量可能具有誤導性。生成式工具往往產生冗長但等效的代碼，或者將任務分解成更多部分，而不實際減少總認知努力。因此，一個錯誤報告變成了五個工單、三個拉取請求和一個遷移説明。這導致更大的差異需要審查，更多的生成測試需要運行，以及更多的人工製品需要分類，增加了錯過關鍵細節的可能性。

有趣的是，開發者的體驗仍然非常積極。AI擅長消除空白頁面的摩擦，使工作感覺更加流暢。AI將人類勞動從創造轉變為評估，因此主觀速度和實際測量時間存在差異。檢查他人的工作通常比自己編寫更容易，儘管往往需要更長時間。下游的審查、清理和驗證工作堆積起來，但開發者感到暢通無阻。AI仍然非常有用。使用Copilot等工具的對照實驗表明，開發者可以更快地完成有界編程任務，如編寫樣板代碼、生成API膠水代碼或編寫測試框架。

問題在於審查和驗證需要更多時間，這進一步拖延了交付週期。年度DORA報告指出，AI採用增加了個人的生產力感，但AI採用可能成為軟件交付穩定性和吞吐量的瓶頸。更快的代碼生成增加了審查隊列和合並風險，推動團隊採用更大的批量規模。AI會放大它所進入的系統。大多數具有良好定義的軟件所有權、嚴格審查流程和高度可靠部署管道的團隊將從該技術中受益。但在弱激勵、模糊的生產邊界和糟糕驗證的情況下，AI只會成為低質量輸出的加速器。

當組織獎勵大量AI令牌使用作為生產力的代理（例如代碼行數或提交次數）時，測量是一個大問題。這些指標很容易被操縱，與實際業務價值幾乎沒有關係。

您在數千名開發者的遙測數據中可以看到這種模式。Faros對超過10,000名開發者的分析發現，雖然高AI採用率與完成更多任務和合並拉取請求相關，但也導致了更長的審查時間、更大的拉取請求以及每個開發者更多的錯誤。他們沒有發現高AI採用率與公司層面交付指標或質量關鍵績效指標之間存在有意義的關聯。

這很明顯。如果開發者編碼速度加倍，但人工審查仍然是瓶頸，那麼工作只會卡在審查中。AI生成的大差異大大擴展了審查者需要查看的搜索空間。在看起來幾乎正確的生成代碼中，微妙的錯誤需要比審查具有清晰人類設計的手寫代碼更多的專家關注。如果沒有強有力的所有權或穩健的驗證，那麼可能產生的就是審查債務。

我們在代碼之外也看到了這一點，以AI生成的“作品垃圾”形式出現。這些是看起來不錯但並未真正推進項目的華麗東西。無休止的備忘錄沒有解決任何問題，會議記錄掩蓋了分歧，提案將盡職調查的負擔推給讀者而非作者。這為所有必須花時間閲讀和處理低實質產出的人創造了真正的隱藏成本。

實際工作只是被推到了下游，那些需要驗證聲明、協調總結並確定提案是否可行的人。與其計數工件，不如衡量團隊是否用了更少的總時間達到正確的合併、堅定的決策或已交付的結果。這需要更好的指標，如每次接受變更的審查時間、返工率、變更失敗率、決策延遲和審查者負載。收集這些措施比收集簡單的令牌計數或完成任務更困難，因此許多組織並不收集它們。良好的交付跟蹤需要考慮已接受的工作和真實的交付成本。

AI是一個強大的工具，用於降低草稿、框架和初次運行的障礙。在那之後，瓶頸仍然是審查。

我正在構建什麼

委託任務。獲得軟件。

給Vroni一個GitHub問題、錯誤報告、規格或粗略想法。它會讀取倉庫、計劃變更、編寫代碼、運行檢查，並朝審查就緒的拉取請求努力。

請訪問vroni.com。