編碼從來不是瓶頸

我的工作是開發者生產力。我已經在開發者基礎設施領域工作了六年，因此我對此有切身利益。我希望AI生產力故事成真——更多的產出、更短的時間線、更快樂和更高效的工程師。誰不希望呢？但我不斷審視實際研究，再看看現實世界中發生的情況，卻無法讓它們相互吻合。或者更確切地説，我可以讓它們吻合，但前提是我願意承認“高效”並不意味着最近大多數討論所認為的那樣。

最令人不安的發現

2025年初，研究組織METR對開源開發者進行了一項對照實驗。他們發現（與行業預期相反），使用AI工具的工程師比不使用的工程師花費的時間多19%，置信區間為+2%到+39%。這種放緩在統計上是穩健的。那是行業的一個不同時期：Claude尚未發佈其Opus模型，行業正在摸索AI能做什麼和不能做什麼。但這一發現引人注目的不是放緩本身，而是工程師們相信他們大約快了20%，而數據卻顯示相反，揭示了感知與現實之間的顯著差距。

這一發現值得我們先消化一下，然後再堆砌其他證據，因為它改變了你閲讀其他一切的方式。

METR試圖從2025年8月開始進行一項後續研究，而這項研究的結果可以説比最初的結果更具揭示性。2026年2月，他們發佈了一篇文章，解釋了為何放棄實驗設計。問題在於，太多開發者拒絕參與，除非他們可以在所有任務中使用AI。30%到50%的剩餘參與者報告有選擇性地迴避提交他們不想在沒有AI的情況下完成的任務。樣本變得系統性地偏向於那些最不可能顯示AI價值的開發者和任務。

2025年末的研究數據顯示了趨勢的改善。對於返回的原始開發者子集，估計效應轉變為速度提高18%（置信區間：-38%到+9%）。在新招募的開發者中，速度提高了4%（-15%到+9%）。但METR指出這些數字可能是一個下界，因為許多人自我選擇退出。他們的結論是：自2025年初以來，AI工具變得更加有用，但選擇效應現在已經如此嚴重，以至於近乎無法進行對照測量。最熱衷於AI的開發者將不再在沒有AI的情況下工作以作為對照組。

這不是METR方法論的失敗。這是一個信號，表明我們身處何處以及我們將走向何方。

另外三個數據點

2025年末和2026年初還發布了若干其他研究。

Anthropic在2025年末調查了其內部132名工程師，進行了53次訪談，並分析了20萬份Claude Code記錄。員工報告生產率提高了50%。隨着工程組織和Claude使用的增長，他們聲稱每位工程師每天的拉取請求增加了67%。Anthropic工程師在60%的日常工作中使用Claude，且Claude執行更多自主任務。

CircleCI分析了跨數千個團隊的2800萬個CI工作流。工作流吞吐量增加了59%，但中位數團隊的主分支吞吐量下降了7%。構建成功率降至70.8%，為五年低點。存在的代碼比以往任何時候都多，但到達生產的更少，CI正在成為瓶頸。

哈佛商學院研究人員研究了78名使用AI執行非專業領域任務的工人。AI幫助所有人平等地進行頭腦風暴，但在執行上，技能與領域相差甚遠的工人比領域專家表現差13%。AI似乎在規劃中縮小的差距在交付中再次出現。

METR在2026年5月對349名技術工作者的調查——這是在實驗設計崩潰後進行的——發現自我報告的生產力價值增益為1.4到2倍。但METR自己的研究人員，即最瞭解他們在2025年記錄到的感知偏差的人羣，報告了該調查中任何子組中最低的增益。

實踐中的情況

這是一個對某些讀者來説會很熟悉的場景。

工程師活動指標在表面上看起來很棒。拉取請求在增加，代碼提交量上升，速度點在以團隊多年未見的步伐被關閉。領導團隊很高興，工程師們感覺更高效了。然後有人——很可能是項目經理——問為什麼六週前標記為“進行中”的路線圖項目仍然在進行中。

每個人都同時意識到：功能時間線實際上沒有改變。

發生的情況是，AI大幅降低了開始工作的成本，但生產就緒的打磨仍然是一個挑戰。初稿函數、樣板代碼、腳手架、以及為不熟悉的代碼編寫測試解釋都變得顯著便宜。但交付的瓶頸從來不是這些任務。它們是產品決策、設計審查、QA、合規、基礎設施、發佈流程。當你加快編碼速度時，你最終會將更多進行中的工作塞到相同的下游瓶頸處。CircleCI關於2800萬個工作流的數據在某種程度上就是這種情況在大規模下的寫照：功能分支上大量活動，而主分支的吞吐量持平或下降。

這不僅在彙總數據中是一種模式。Anthropic Claude Code的一名工程總監在2026年6月的一次演講中明確指出了這一點：編寫代碼、編寫測試和重構在她的團隊中已經很少成為瓶頸，但瓶頸並沒有消失。驗證、代碼審查和安全取代了它們的位置。她特別指出了CI。隨着團隊生成更多代碼，構建系統和CI管道可能難以跟上。這是一個運行着世界上AI加速程度最高的工程組織之一的團隊，卻遇到了與CircleCI數據描述的相同的約束牆。天花板不再是代碼編寫速度，而且實際上從來就不是。

Anthropic發現27%的AI輔助工作本來不會發生，這有利有弊。有些工作確實有價值，比如原型探索為實際決策提供信息，文檔得以真正編寫。有些則是沒有人優先考慮過的工作，因為它根本不重要。現在它正消耗審查週期和CI資源，因為構建它變得幾乎免費，而審查、測試和維護它卻沒有。

能力-信心差距

HBS研究確定了一個值得精確命名的具體機制。在他們的框架中，AI縮小了新手和專家之間的信心差距。它讓每個人平等地獲得計劃、解釋和初稿。但它沒有縮小能力差距。當一個後端工程師用AI輔助構建前端功能時，他們產出的東西看起來正確。問題隱藏在表面之下，在他們不知道要質疑的決策和他們不知道要測試的邊緣情況中。

早期的METR結果表明，這甚至適用於在自己的領域內有經驗的專業人士。AI並沒有讓他們變得無能，實際上讓他們感覺比他們的產出所證明的更有能力。而正如METR後續研究的崩潰所表明的那樣，一旦開發者將AI深度整合，他們就失去了在沒有它的情況下工作的能力，正如研究人員所稱的自動化偏見。

這是應該令工程領導者擔憂的部分。你無法修復你看不到的問題。如果你團隊中的每個工程師都真誠地相信他們的生產力提高了50%，而你的交付日期卻沒有變化，那就存在一個沒有人認為存在的問題。

如何使人工智能原生開發可持續

使代碼審查更嚴格，而不是更快。AI生成的代碼輕鬆通過表面檢查——乾淨的格式、一致的約定、沒有檢查器警告——這正是它危險的原因。問題在於審閲者瀏覽差異時不會發現的那種。

我一直稱之為“合理懷疑審查”。做法是從懷疑而非信任開始。問題不是“這看起來正確嗎？”而是“這裏可能有什麼問題是我從差異中看不出來的？”具體來説，模型做出了哪些在輸出中不可見的假設？它在哪些邊緣情況下會靜默失敗？哪裏耦合了作者可能沒有考慮到的東西？

這更慢。這正是關鍵所在，而且它也不是無限可擴展的，因此需要將自動化用於不需要判斷的事情，並將人類注意力集中在需要判斷的地方。

Claude Code團隊的方法是一個很好的指示：讓AI處理風格、檢查、錯誤捕捉和測試生成作為第一遍，但將安全敏感代碼、信任邊界和任何涉及法律風險的內容直接交給領域專家。劃分不是“AI審查較小/低風險更改，人類審查較大/高風險更改”，而是“AI處理表面正確性，人類負責重大判斷”。這是一項有意義的區別。許多團隊在做前者時以為自己在做後者。

調整你的CI以適應新的故障模式。CircleCI的構建成功率跌至五年低點，而吞吐量卻激增，這表明大多數團隊尚未更新其管道以捕捉AI生成代碼的破壞方式。AI生成的代碼失敗方式與人類生成的代碼不同。它更可能局部正確但架構不一致，通過單元測試但失敗集成測試，尊重函數簽名但違反這些函數所圍繞構建的假設。集成測試、契約測試和架構適應度函數可以在管道中強制執行系統約束，它們會比檢查器或類型檢查器捕捉到更多此類問題。如果AI生成的代碼違反你的模式，構建應該在審閲者打開差異之前捕捉到它。這解決的是你的審查問題和基礎設施問題。

在功能標誌後面發佈並積極監控。接受你無法在部署前捕捉到所有問題。不要完全依賴於合併前質量——證據表明這比感覺上更難評估——而是部署給1%的用户，觀察儀表板，並在出現問題時快速回滾。這種方法還迫使投資於可觀察性，這獨立於AI問題也會帶來回報。

要求為AI輔助代碼編寫人工編寫的測試（直到AI能夠自信地生成確定性測試）。特別是針對邊緣情況和邊界條件的人工編寫的測試。編寫測試的紀律迫使開發者思考行為，而不是表面地接受輸出。如果工程師無法編寫測試，他們可能不夠理解代碼，不足以發佈它。這是一個有用的信號，而不是失敗狀態。

保護有意的知識共享時間。Anthropic研究發現，導師制正在悄然侵蝕，因為Claude取代了工程師們曾經互相進行的對話。這是數據中的長期風險。架構決策記錄、輪流系統演練、高級和初級工程師一起解決問題的結對會議——這些與詢問AI相比感覺效率低下。它們正是團隊建立共同理解的方式，這種理解可以防止同樣的錯誤以更格式化的代碼每六個月被重造一次。

測量問題

那麼，這是否意味着我們停止使用AI？不。使用AI，並在它明顯有助於繁瑣任務、原型設計、探索性工作以及任何你可以快速驗證的事情上積極使用。在範圍良好、可獨立驗證的工作上，收益是真實的。

但如果你試圖衡量生產率的實際提升，請謹慎對待自我報告的數據。實際結果——功能交付、事件數量、代碼審查週期時間——才是最重要的。而迄今為止的數據表明，AI正在改變工作的性質，但尚未從根本上改變我們交付的速度。它改變了瓶頸的位置，但沒有消除瓶頸。而忽視這一區別的團隊最終會生成大量永遠不會交付的代碼。

解決方案不是更少使用AI，而是更聰明地使用它——並誠實面對我們仍然需要解決的瓶頸。