當我們平台團隊在2025年初在每個儲存庫中採用AI程式碼輔助工具時，我預期能提高生產力。我沒有預期的是，最有價值的教訓來自失敗，而不是成功。在審查了約4,200個AI在撰寫程式碼中發揮了有意義作用的合併拉取請求後，所呈現的畫面與我閱讀的大多數廣告材料相矛盾。這項技術背後的經濟動力是不可否認的，隨著在人工智能基礎設施上投下的6440億美元美元賭注正在重塑資本如何流動通過硅谷及更遠的地方，但使用這些工具發送生產軟體的日常現實比任何演講會提出的都更加混亂、更加微妙，並且最終更加有趣。這就是我們所學到的，我們所改變的，以及我們希望在我們開始之前有人能告訴我們的事。

產出數據是真實的，但具有誤導性

我們內部數據顯示，一旦AI輔助成為標準實踐，個別開發者交付的程式碼行數增加了26至55%。聽起來像是一個明確的勝利，在狹窄的語境中確實如此。程式碼模板生成、測試基礎架構、API客戶端包裝以及常規的重構工作都從小時縮短到分鐘。我們團隊一名初級工程師在三天內重寫了一條傳統的ETL流程，而在我們之前的工 作流程下，這項工作需要六週才能完成。

但程式碼的數量並非正確的指標，而且我們幾乎立刻就知道了。到了第四個月，我們的事件率相比前一年上升了31%。回滾次數增加了。解決問題的平均時間變長了。當我們深入調查事後分析時，一個模式浮現出來：這些回滾很少是AI產生程式碼本身的災難性錯誤。它們是微妙的整合失敗，是模型無法預知的邊界情況，以及由於接受在系統其他地方違反了非書面規範的本地有效建議而累積的複雜性。

METR 進行的一项廣泛流傳的研究發現，有經驗的開發者在熟悉的程式碼庫上使用 AI 助手時，實際速度反而慢了 19%，儘管他們認為自己快了 20%。METR 對於 AI 開發者生產力的隨機控制試驗的發現 在我們將綠地工作與成熟服務的維護分開後，與我們自己的數據觀察相符。生產力故事完全取決於背景，而AI擅長的背景並非大多數高級工程師花費時間的背景.

人們沒有警告我們的審查瓶頸

AI 的普及給我們帶來的最大運營變化是代碼審查的全面重構。當開發者能在二十分鐘內產出八百行看似合理的代碼時，瓶頸立刻且永遠轉移到必須審查代碼的人身上。我們的高級工程師在三個月內開始過勞。審查隊列變長。PR（Pull Request）積壓數日。人們開始蓋章通過變更，因為體量讓仔細審查變得不可能。

我們最終透過倒轉工作流程解決了這個問題。現在要求作者透過錄製的影片（長度不超過五分鐘）向審稿人展示任何使用AI輔助所做的變更，解釋程式碼的作用、為何選擇這種方法，以及他們如何進行人工驗證。影片要求聽起來官僚，但它達成了兩件事。它迫使作者真正理解他們生成的程式碼，這彌補了一個危險的知識差距。並且它為審稿人提供了一個尊重他們時間的起點。審稿速度在六週內恢復正常，合併的程式碼品質也顯著提升。

究竟什麼有效

經過一年的實驗，少數實踐將受益於AI工具的團隊與那些被其輸出淹沒的團隊分開。這些都不是革命性的，但為了能夠一致地應用它們所需的紀律，結果成為了區分點。

在生成前嚴格的規範比提示工程技巧更重要。在呼叫助理前寫下詳細的接受標準、類型簽名和範例輸入的工程師，比那些用自然語言描述他們意圖的工程師得到顯著更好的結果。這個模型是一個字面意思的協作夥伴。給它模棱兩可的指示，它將產生模棱兩可的程式碼，而且通常很自信。

先測試後開發的工作流程對任何非簡單的變更來說都變成了必須的。在產生實現之前先寫測試完成了類型系統單獨完成的事情：它限定了搜索空間並提供了一個客觀的信號來判斷輸出是否正確。那些跳過這個步驟的團隊最終結果是調試看起來合理的代碼，但在生產環境中靜默失敗。

將 AI 辅助與建築邊界處的強制性人類檢查點結合，防止了系統設計逐漸脫節的緩慢漂移。我們要求人類編寫任何跨越服務邊界、定義新的公共 API 或修改認證或授權邏輯的代碼。在這些區域，模型被允許建議，但不能主導。僅僅這一規則就避免了數次本會無此規則就發布的險些失誤。

對於可觀察性的投資已經多倍收回成本。當你無法完全信任倉庫中每一行程式的來源時，你需要能夠快速在生產環境中偵測問題。我們在年中的後半段加倍了在追蹤、結構化記錄和警報上的支出。這筆花費是顯著的。若不這麼做，後果將會是災難性的.

突然間變得更寶貴的技能

觀察我們團隊在十二個月內的適應過程，揭示了在AI輔助環境中哪些工程技能會累積增強，哪些則會衰退。這一現象顛覆了一些長久以來關於什麼樣的開發者才強大的固有認知。

仔細且快速地閱讀程式碼成為團隊中最寶貴的技能。能夠掃描300行的差異並識別出兩個可疑區塊的工程師，其生產力是僅依靠測試來捕捉問題的工程師的十倍。除錯技巧也獲得了價值，因為AI產生的錯誤通常呈現出不熟悉的形態，難以抵抗標準的故障排除啟發法。

系統設計與架構判斷變得更加重要，而不是越來越不重要。這個模型可以產生你要求任何個別組件，但它無法告訴你你的系統實際上需要哪些組件，它們應該如何互動，或哪些妥協是值得做的。那些蓬勃發展的工程師是那些能夠在腦中掌握整個系統，並指導人工智能朝向符合一致整體的實現方案的人。

相反地，記住 API 語法、背誦框架慣用語法，或快速輸入模板程式碼的能力，在一夜之間幾乎變得毫無價值。以這些技能建立身份的工程師調整得最困難。一直將這些視為建構軟體真正工作的附帶工作的工程師幾乎沒有注意到變化

我會對過去的自己說什麼

如果我可以向2025年1月推出這些工具的版本的我發送一條信息，那將是這樣：技術不是難點。難點是圍繞一種根本不同的生產功能，重新建立你團隊的審查流程、品質標準和技能發展途徑。贏得這次轉型的團隊不是那些擁有最佳模型或最聰明提示的團隊。它們是那些將AI輔助視為嚴肅組織變革並相應投資的團隊。其他人正在發行更多沒有人完全理解的代碼，累積一種傳統重構無法償還的債務，並且只在最壞的時刻發現了這種代價。