Agoda 的工程團隊花了不少時間推廣 AI 程式設計工具，然後做了回顧。結論讓人有些坐不住：
個人開發者效率提升了，但專案整體交付速度沒怎麼動。
這不是 Agoda 一家的問題。Faros AI 整理了跨公司的數據，給出了一組扎心的數字：
高 AI 採用率的團隊，PR 合併量增加了 98%，任務完成量增加了 21%。但與此同時，PR 的審查時間增加了 91%。
產出多了，但 Review 變慢了。兩個效應幾乎互相抵消了。
真正的瓶頸是什麼
Agoda 工程團隊的判斷是：問題出在「程式設計從來就不是軟體交付的主要瓶頸」這件事上。
AI 補全讓寫程式變快了。但寫程式只是流水線裡的一個環節，它前面有需求分析、系統設計、技術方案對齊，它後面有 Code Review、測試、整合、部署。
你把中間那個環節的速度提升三倍，不代表整條流水線快三倍。
當 AI 讓程式碼產出量暴增，「消化這些程式碼」的能力反而成了新的卡點：
- 每個 PR 的程式碼量變大了（AI 生成的程式碼往往不夠精煉）
- Code Review 要審查的東西更多了
- 但高級工程師的時間是有限的
瓶頸從「寫程式慢」轉移到了「審查程式碼慢」，實際交付節奏沒有改善。
更深的問題：Specification
Agoda 的工程師 Leonardo Stern 更進一步，他認為真正的稀缺資源上移了：不是 Review，是 Specification——把模糊的業務需求轉化成清晰可執行的技術規格的能力。
以前，工程師花大量時間寫程式碼，specification 可以模糊一點，因為「寫著寫著就搞清楚了」。
現在，你把一個模糊的需求扔給 AI，AI 會生成「看起來能用」但方向跑偏的程式碼。然後你再回來改 spec，AI 再重新生成，反覆幾輪。表面上程式碼產出量很高，實際上在用程式碼試錯，效率並不高。
高保真的需求規格說明，正在成為核心的工程交付物。不是程式碼本身，是「怎麼描述要什麼」。
Stern 的「灰盒」方法
Stern 提出了一個叫做「灰盒」的工作方式，介於兩個極端之間：
- 白盒：每一行 AI 生成的程式碼都過一遍，你對實現細節完全負責
- 黑盒：AI 寫完直接上線，你對結果負責但不管理過程
- 灰盒：在兩個關鍵點介入——寫精確的 spec、驗證結果是否符合 spec
灰盒的核心邏輯是：你不需要理解 AI 用什麼方法解決問題，但必須能明確說清楚「什麼算解決了」，並且能驗證它確實解決了。
這個方法的本質，是把工程師的時間和注意力集中在「AI 最不擅長的部分」——定義意圖和驗證結果，而不是實現細節。
工程師角色在往哪兒走
傳統的軟體工程師角色假設裡，「寫好程式碼」是核心競爭力。
現在這個假設在動搖。當 AI 能寫出品質尚可的程式碼，工程師的稀缺性來自哪裡？
從 Agoda 這類公司的實踐來看，答案在往這個方向走：
- 能把業務問題轉化成精確技術規格的人
- 能設計有效驗證方案的人
- 能判斷 AI 產出的程式碼是否真正解決了正確問題的人
這不是「寫程式碼的能力不重要了」——而是寫程式碼的能力從稀缺資源變成了基礎門檻，真正的區分度在更上游。
用 Stern 的話說：人類的權威正在從「寫程式碼」向「定義意圖」遷移。這是抽象層級的上移，不是技能的消失。
管理層該怎麼看這件事
對工程管理者來說，Agoda 的研究有一個直接的行動建議：不要用程式碼產出量來衡量 AI 的價值。
PR 數量、程式碼行數、任務完成量，這些指標都會因為 AI 工具而變好看。但如果交付的功能沒變多、沒變快、品質沒變好，這些數字就只是數字。
真正值得追蹤的指標是：功能上線週期、線上缺陷率、從需求到交付的端到端時間。這些數字才能告訴你 AI 有沒有真正幫到團隊，還是只幫團隊在 GitHub 上刷了數據。
下次有人拿 PR 合併量給你彙報 AI 工具的 ROI，可以問一句：那 Review 時間呢？
參考來源：CocoLoop、AI Coding Assistants Haven't Sped Up Delivery Because Coding Was Never the Bottleneck（InfoQ）