Uber 如何用 AI 代理放慢增聘、寫出更多程式碼

這會改變招聘公式。過去需要更多軟體產能時，常見做法是增聘更多工程師；現在，Uber 可以嘗試用 AI 編碼代理、開發者工具、自動化與算力補上一部分產能。Khosrowshahi 也談過較長期的可能性：未來某些新增工程人力，可能改由 AI 代理與 GPU 等運算資源來補足。不過，現有報導仍顯示 Uber 今天採取的是「人在回路中」的模式，而非完全放手讓 AI 自行上線 。

AI 在 Uber 工程團隊做什麼

關鍵變化在於，AI 不只是補字或自動完成程式碼，而是開始成為軟體交付流程中的主動參與者。Uber 技術長 Praveen Neppalli Naga 表示，公司已大力投入 AI 編碼；95% 的 Uber 工程師每月使用 AI 工具，內部 AI 代理每週約產生 1,800 次程式碼變更 。

這項開發者生產力工程，不只涵蓋寫程式本身。Uber 的 Developer Productivity Engineering 相關分享指出，公司正把 AI 應用到整個軟體開發生命週期，包括針對大型單一程式碼庫（monorepo）調整編碼助理、用代理型系統處理大規模程式碼遷移，以及導入 AI 輔助測試與程式碼審查流程 。

但最後的控制點仍是審查。Khosrowshahi 表示，AI 產生的程式碼會先由員工檢查，才會加入儲存庫 。換句話說，Uber 是用代理產生與準備更多工作，而不是把正式工程交付變成無監督自動化。

「10% 程式碼變更」不等於「10% 程式碼」

Uber 對外出現的 AI 數字，衡量的是不同層面的事情，不能混成同一個指標。

Khosrowshahi 提到的 10%，是指由自主代理產生的程式碼變更 。另據 The Pragmatic Engineer 報導，Uber 有 84% 開發者屬於代理型編碼使用者，也就是使用命令列代理，或在整合開發環境（IDE）中提出比單純補字更具代理性質的請求；同一報導還指出，在 IDE 型工具內，有 65% 至 72% 的程式碼由 AI 產生 。

這些數字可以同時成立，因為它們分別衡量自主代理產生的變更、開發者對代理型工作流的採用，以及 IDE 工具中的 AI 生成程式碼。實務上的重點是：AI 可能協助草擬了相當大比例的程式碼，但真正歸因於自主代理、並完成審查合併的變更比例，是另一個問題 。

這如何降低招聘需求

如果工程師能在同樣編制下交付更多工作，Uber 就能在不以相同比例增聘的情況下擴大工程產能。這正是公司增加 AI 支出、同時放慢招聘的經濟邏輯 。

但成本並沒有消失，只是轉移了。除了薪資與人力成本，Uber 也要支付 AI 工具、代理系統與運算資源。關於 Uber AI 編碼導入的報導指出，Claude Code 使用量激增，讓公司 2026 年 AI 編碼預算比預期更早用盡；Uber 使用的工具包括 Claude Code 與 Cursor 。這應被視為工具需求快速上升的切面，而不是完整的 AI 成本帳本。它說明的是：軟體產能正愈來愈像一個組合題，包含人、代理、工具與基礎設施。

AI 也進入營運流程

Uber 的 AI 策略不只限於工程。Khosrowshahi 表示，Uber 多年來已使用 AI 為叫車行程定價，並媒合司機與乘客 。較新的報導則指出，生成式 AI 與代理型 AI 也被用於客服、司機上線流程，以及部分工程開發生命週期，在一些工作流中減少人工介入 。

這點重要，因為編碼以外的效率提升，同樣可能降低招聘壓力。若 AI 能加快客服處理、簡化司機 onboarding，或協助診斷內部服務問題，Uber 就能在不按過去比例增加人手的情況下，移除部分營運瓶頸 。

對工程師意味著什麼

Uber 目前展示的是「受監督的 AI 工程」，不是「沒有工程師的工程」。AI 代理可以草擬程式碼、準備變更、支援遷移、協助測試與審查工作流；但 AI 寫出的程式碼在合併前，仍由人類員工審查 。

最可能受到影響的是新增人力需求。只要 AI 工具能在真實工作流中穩定帶來效率，Uber 就能用較少的增聘，換取原本需要更多工程師才能支撐的產能成長 。

仍然要保留一個關鍵但書：採用率、AI 生成程式碼比例與程式碼變更數，並不自動等於精準的生產力增幅。真正的衡量還包括品質、可靠性、維護成本與長期工程負債。Uber 的案例顯示 AI 已經進入大型科技公司的核心開發流程，但它更像是在重畫工程團隊的分工邊界，而不是簡單宣告人類工程師出局。