每美元僅剩十八美分：當 AI 程式碼的技術債到期時，這些工具的真實成本
專欄概述
詢問一屋子滿座的工程主管，AI 程式開發助手是否讓他們的團隊變得更快，幾乎所有人都會說是。但若要求他們拿出具體證明，對話就會變得尷尬許多。今年相隔幾週內發布的兩份數據，悄悄重新開啟了一場多數業界人士以為早已塵埃落定的辯論：AI 生成的程式碼實際上真的比較便宜好交付嗎？還是我們只是把成本移轉到了沒有注意到的地方？
沒有人逐條列出的帳單
那個在開發者 Twitter 上引發熱議的數字來自 Entelligence AI，他們從 2,444 家公司提取了使用數據，並做了一件幾乎沒人願意做的事：追蹤每一塊花在 AI 程式開發 token 上的錢，一路追蹤到實際上線為止。結果的分佈毫不隱晦。每花一塊錢，有 44 美分用於修復 AI 自己引入的錯誤，27 美分用於重寫撐不住的 AI 生成程式碼，另外還有 11 美分蒸發在人類試圖搞清楚模型到底做了什麼時，所產生的程式碼審查與合併延遲摩擦中。把這些加總起來，每花一塊錢，大約只有 18 美分的真實、可交付價值存活下來。十萬美元的 token 預算，最終只給你大約一萬八千美元真正能上線的程式碼。
這種表述方式傳播得很快，因為它極度清晰易懂——一個任何人都能在會議中脫口而出的單一比例。但它也幾乎同樣迅速地引發了反彈，而且其來有自：一則將某家廠商的總體調查數據提煉出來的瘋傳推文，並不等於一項對照實驗研究，「18 美分」這個數字將截然不同的工程工作混為一談，且各個團隊在審查流程的嚴謹程度上差異極大。一篇正好提出此論點的反駁文章〈每美元僅剩十八美分〉，值得與原始主張一起閱讀，而非取而代之——它並沒有推翻潛在的趨勢，而是主張這個特定數字被要求承載了超出其所能支持的精確度。值得記住的重點不在於小數點後第二位。而在於研究發現的形態：有很大一部分的 AI 程式開發支出並未創造新價值，而是在為製造這些混亂的同一個工具善後。
為什麼「快兩倍」仍可能讓你虧錢
如果 Entelligence 的數字是一張快照，那麼 James Shore 的文章〈你需要的是能降低維護成本的 AI〉——這篇文章攀升至 Hacker News 頂端，並在一個意見真正分裂的留言區中持續位居——就是解釋這張快照為何會如此呈現的運作機制。Shore 的論點不需要你相信 AI 會寫出糟糕的程式碼。它只要求你接受一個多數 ROI 推銷簡報都方便地略過的會計恆等式：總維護負擔與你正在維護的程式碼數量成正比，而不是與你產出它的速度成正比。
將模型向前推演。一個 AI 代理讓團隊產出加倍——兩倍的功能、兩倍的檔案、兩倍被寫入程式庫的邊緣案例。如果每單位程式碼的維護成本保持不變（這是最樂觀的情況），你並沒有削減維護帳單；你反而讓它加倍了，因為你現在有兩倍的程式碼，會產生兩倍的支援工單、安全性修補與整合頭痛問題。Shore 的模型將時間軸拉長，以使論點具體化：在一系列合理的假設下，在大規模採用 AI 加速開發後約兩年半內，維護工作將攀升至佔據開發者一半以上的時間。開發速度提升了。執行新工作的淨產能卻沒有——因為舊工作的稅負也隨之同步增長。
這篇文章下方的 Hacker News 討論串值得被視為一個獨立的資料來源，而不僅僅是一個互動指標。意見的分歧大致如你所預期：擁有強大測試覆蓋率、嚴格審查紀律，以及由資深工程師主導 AI 的團隊回報說，這種複利效應是真實的但可控的，比較接近 20-30% 的維護稅負，而非失控的螺旋。而讓 AI 生成的程式碼在較寬鬆的監督下就上線的團隊，則描述了比較接近 Shore 最壞情況的狀況。這種分歧比任何一個極端都重要，因為它表明結果並非由工具決定——而是取決於一個組織是否已經具備足夠的紀律，能在這筆債務複利滾存之前就先攔截下來。
沒人想承認的依賴性
將第三個數據點疊加上去，整體情況變得更加令人不安地清晰。TechCrunch 關於開發者現在拒絕在沒有 AI 協助下寫程式的報導，描述了一個已悄悄跨越門檻的勞動力，而且幾乎沒有太多關於是否該這麼做的內部辯論。因為一個工具能讓你變得更快而採用它是一回事。但達到一個不再覺得能夠不靠它工作的地步——在這個地步，不靠輔助寫程式碼的技能已經萎縮到回頭幾乎已不可能——又是另一回事。
將這一點與維護數學放在一起看，你會得到一個真正尷尬的組合：一支越來越依賴某個工具的勞動力，而該工具的產出卻創造了許多同樣這些開發者無力手動償還的維護帳單，無論是能力還是資源上。如果 AI 寫了這些程式碼，而 AI 無法被信任能以當初撰寫時一樣低廉的成本來維護它，且平時會進行這些維護工作的人類，恰恰是在沒有 AI 介入下最缺乏練習的一群，那麼這筆債務就不會被償還——它只會被延後。這不是一個假設性的失敗模式。這正是 Shore 文章所描述的確切機制，只是從人力資本的角度而非程式庫規模的角度來檢視。
業界忘記建立的指標
這一切都無法推導出「AI 程式開發工具沒有用」的結論。這裡的每一個來源，包含抱持懷疑態度的來源，都將這些工具確實能加速程式碼的撰寫視為理所當然——這點毫無爭議。有爭議的是，業界是否一直在衡量正確的東西。每小時程式碼行數、每個衝刺期合併的 PR、每個交付功能所花費的 token——這些都是生產端的指標。它們告訴你管線前端移動得有多快。但它們都無法告訴你，六個月後當這些程式碼需要被某個不是原作者、且可能第一次也沒有仔細審查過它的人修改、除錯或擴充時，會發生什麼事。
這才是整個辯論所圍繞的實際變數：AI 對軟體團隊的淨影響，不是一個你可以透過衡量產出速度來回答的問題，因為速度恰恰就是在帳單到期前一刻飆升的那個數字。一個更誠實的 ROI 模型，會像放款人看待貸款那樣來看待 AI 輔助的程式碼——今日交付的價值，必須與幾季後開始出現在維護帳本上的還款期程進行權衡。有些團隊已經在以這種方式建構他們的 AI 採用策略，對任何 AI 生成的內容設有更嚴格的審查關卡與強制測試覆蓋率，正是因為他們已經將這種權衡內化了。但根據上述數字，大多數團隊仍把這筆貸款當作補助金來算。每美元 44 美分的數字與兩年半的維護曲線，是描述同一張未付帳單的兩種方式。這張帳單究竟會維持在可控範圍內，還是會成為這十年軟體開發的主導成本，與其說取決於你使用哪個模型或哪個代理，不如說取決於你的組織是否決定在它送達前先看它一眼。