AI 寫的程式 bug 率比人低，但 bug 總數反而飆升？Shopify 技術長的 AI 管理實戰課

本文整理自 Latent Space: The AI Engineer Podcast 2026 年 4 月播出的單集。

{{< youtube RrkGoX3Cw7o >}}

{{< apple-podcast "tw/podcast/shopifys-ai-phase-transition-2026-usage-explosion-unlimited/id1674008350?i=1000763126873" >}}

---

2025 年 12 月，一場「相變」悄悄發生

Shopify 技術長 Mikhail Parakhin 在 Latent Space Podcast 上秀出一張內部數據圖，讓主持人倒吸一口氣。那是一張以「每日活躍使用 AI 工具的員工百分比」為縱軸的趨勢圖，綠色的總數線幾乎貼到了 100%。Parakhin 在 2024 年從微軟加入 Shopify 之前，曾主導 Bing、Edge、Copilot 等產品的 AI 整合，被 Shopify 執行長 Toby Lütke 形容為「地球上最好的機器學習工匠之一」。他說，現在在 Shopify，不深度使用至少一款 AI 工具就幾乎無法完成工作。

但真正讓他感到驚訝的，是 2025 年 12 月那個清楚的轉折點。模型的小幅改進日積月累，在某個時刻觸發了使用量的爆炸性成長。他把這個現象稱為「相變」（phase transition），物理學的術語，指的是水在零度結冰、一百度沸騰那種突然的狀態切換。在 Shopify 的數據上，這個相變的結果是：2025 年 12 月之後，Token 消耗量進入了完全不同量級的指數成長。

消費分布的變化同樣耐人尋味。Token 消耗量正變得越來越偏斜，排名前 10% 的重度使用者，其消耗成長速度遠快於其他人。Parakhin 坦言這個趨勢「感覺不太理想」，因為如果這個分離速度持續一年，最極端的情況是一個人消耗掉所有 Token。這到底代表頂尖使用者找到了真正高效的用法，還是代表大多數人還沒搞懂怎麼用，他還在觀察。

CLI 正在超越 IDE：開發者行為的意外轉向

Shopify 的內部數據揭露了一個多數人沒預料到的趨勢：CLI 類工具和不需要盯著 IDE 的代理式工具，成長速度明顯快於傳統的 IDE 整合工具。像是 Claude Code 這類命令列工具和 Shopify 內部的 coding agent，採用曲線陡峭上揚。相比之下，GitHub Copilot、Cursor 這些需要在編輯器裡操作的工具，雖然沒有萎縮，但成長速度慢了一截。

這個數據的含義很重要。它暗示開發者的工作方式正在轉變：從「人坐在 IDE 前寫程式、AI 在旁邊建議」，走向「人下達指令、AI 代理在背景執行整段任務」。前者是輔助模式，後者是委派模式。當一個開發者可以同時讓多個代理分頭處理不同任務時，他不需要一直盯著程式碼編輯器。CLI 和代理工具天生就適合這種工作流，這也解釋了為什麼它們成長更快。

Shopify 的做法是讓員工自由選擇工具，公司不指定用哪一款，只從「模型下限」去管控品質。這種由下而上的工具採用策略，反而產生了更真實的使用數據，讓管理層能看清開發者真正偏好哪種工作方式。

無上限 Token 預算，但有模型下限

黃仁勳（Jensen Huang）曾公開建議，如果你的二十萬美元年薪工程師每年沒有用十萬美元的 Token，就是在浪費 AI 代理的潛力。這番話引來不少批評，認為他身為 GPU 供應商當然會這樣說。但 Parakhin 的看法是：黃仁勳方向上是對的。

Shopify 的策略是為每位員工提供無上限的 Token 預算。但真正的管控不是限制花多少，而是限制「至少要用多好的模型」。Parakhin 說得很直接：「請不要用任何低於 Opus 4.6 的模型。」有些人選擇用 GPT 5.4 Extra High，有些人堅持用 Opus 4.6，各有優劣。但公司的態度是寧願多花錢讓大家用好模型，也不要省錢讓大家用便宜模型產出低品質程式碼。

這個策略背後的邏輯值得細想。如果你限制 Token 數量，員工會被迫在便宜模型和少量使用之間做選擇，結果是品質和數量都被壓縮。如果你不限數量但限制模型下限，員工可以放心大量使用，而且每次互動的品質都有基本保障。這是一種「品質優先」的 Token 管理哲學，和多數公司的「成本優先」思維截然不同。

辯論模式：一個代理寫、另一個代理批評

Token 消耗量暴增不代表效率就好。Parakhin 特別點出一個常見的反模式（anti-pattern）：同時開太多代理平行執行，但彼此之間不溝通。「那幾乎是浪費，」他說。

他推薦的做法是「辯論模式」：一個代理產出程式碼，另一個代理（最好是不同的模型）負責批評和提出改善建議，然後第一個代理根據批評重新修改。這個來回的過程比較花時間，延遲會明顯增加，有些人不喜歡等。但 Parakhin 認為，程式碼品質的提升遠大於等待的代價。

他特別在意的一個指標，是「程式碼生成花的 Token 預算」和「PR 審查花的 Token 預算」之間的比率。理想狀態下，你應該把可觀的預算花在讓昂貴的模型（像 GPT 5.4 Pro 或 DeepThink）做嚴格的 PR 審查，而不是全部灌在生成階段。這和直覺相反，多數人會覺得生成才是重頭戲，但 Parakhin 從實戰經驗中發現，審查階段的投資報酬率更高。

目前他還沒有找到滿意的外部 PR 審查工具。市面上的產品多半用便宜模型來跑，速度快但品質不夠。他需要的是「pro 等級」的模型花一小時慢慢想，而不是一群小代理快速掃過。這種需求和多數工具公司的商業模式衝突，所以 Shopify 目前只能自己做。

PR 審查成為新的「全域互斥鎖」

在傳統的軟體開發流程中，PR 審查是一個「全域互斥鎖」（global mutex）。每一次合併程式碼都要通過這個瓶頸，但因為人類寫程式碼的速度有限，這個瓶頸通常不會造成太大問題。然而，當 AI 以機器的速度大量產出程式碼時，這個瓶頸就變成了整個部署流程的致命卡點。

Parakhin 描述了一個惡性循環：AI 產出的程式碼量暴增，導致測試失敗的機率上升。一旦測試失敗，就要找出問題 PR、移除它、重新測試，整個部署週期因此拉得更長。如果你用便宜的快速模型做 PR 審查，漏掉的 bug 就會在後續階段造成更大的時間成本。

所以 Parakhin 的結論有些出乎意料：讓一個昂貴的模型花一小時深思熟慮地審查 PR，從整體部署時間來看反而是節省時間的做法。因為你避免了測試失敗、找問題 PR、移除重測這一連串的下游成本。他把這個觀點說得很明確：「不要看個別 PR 的等待時間，要看整體系統的部署時間。」

他也承認，現在整個軟體產業面對的 CI/CD 架構，是為人類速度設計的。當程式碼產出速度切換到機器速度，我們可能需要完全不同的範式。他甚至半開玩笑地說，身為微服務的終身反對者，他現在開始覺得微服務可能會因為 AI 時代的需求而回歸，因為微服務允許小範圍的獨立部署，不用每次都通過全域的整合測試瓶頸。

AI 程式碼的 bug 率比人低，但 bug 總數反而更多

這是 Parakhin 在訪談中最具啟發性的觀察。他認為，目前好的模型寫出的程式碼，平均每行的 bug 率確實比一般人類工程師低。但問題在於量：AI 不會累，不會分心，可以不斷產出程式碼，寫出的量遠超人類。當你把「較低的 bug 率」乘以「遠大於人類的產出量」，結果是進入生產環境的 bug 總數反而上升了。

這個觀察帶來一個管理上的核心挑戰：你不能只看 AI 的「品質」，還要看它帶來的「規模效應」。品質再好，如果量大到品管流程跟不上，最終結果可能比以前更差。這就是為什麼 Parakhin 對 PR 審查環節如此執著。他把 PR 審查稱為「窄腰」（narrow waist），意思是不管上游產出多少程式碼，都必須通過這個嚴格的品管關卡，否則 bug 數量會失控。

對工程管理者來說，這意味著 AI 時代的品質管理邏輯要翻轉。過去，我們擔心的是工程師產出不夠多；現在，我們擔心的是產出太多但審查跟不上。衡量工程效率的指標也要改變：不是看誰消耗最多 Token 或產出最多行程式碼，而是看生成預算和審查預算的比率是否合理。

我的觀察：黃仁勳對了，但只對了一半

黃仁勳說每個工程師都應該大量使用 AI Token，這個方向沒錯。但 Parakhin 的實戰經驗補充了關鍵的後半句：Token 花在哪裡比花多少更重要。如果你把大量預算灌在生成端，卻沒有對應的審查投資，結果就是 bug 海嘯。

Shopify 的經驗也揭示了一個更深層的問題：我們現有的軟體開發基礎設施，從 Git 到 CI/CD 到 PR 流程，都是為人類的工作節奏設計的。當 AI 把程式碼產出速度提高了一個數量級，這些基礎設施就開始嘎嘎作響。Parakhin 說他還沒看到真正令人信服的新範式出現，大家都只是在想辦法「不被淹沒」。

這或許是 AI 時代軟體工程最值得關注的問題：不是 AI 能不能寫好程式碼（能），而是我們的工程流程能不能跟上 AI 的產出速度。答案目前是跟不上。誰先解決這個問題，誰就掌握了下一波生產力提升的鑰匙。