Uber 的 AI 轉向，與其說是「用機器取代工程師」，不如說是一套更務實的算盤：讓既有員工做出更多產出，從而降低新增人力的速度。2026 年，Uber 一邊增加 AI 投資，一邊放慢招聘；執行長 Dara Khosrowshahi 表示，自主代理現在約產出 Uber 10% 的程式碼變更，但這些程式碼在合併進儲存庫前，仍會由人類員工審查 [10]。
核心邏輯：不是少做事，而是少靠新增人力擴張
Uber 目前並未把 AI 包裝成工程師的完整替代品。它的做法更像是在「控制」人力增長速度，同時用 AI 拉高每位員工的產出 [10]。Khosrowshahi 曾表示，希望員工透過 AI 把產出提高 20%、30%、50%，甚至 100% [
10]。
這會改變科技公司的招聘公式。過去需要更多工程產能，常見做法是招更多人；現在 Uber 嘗試把部分增量產能交給 coding agent、開發者工具、GPU 與流程自動化來補上。Khosrowshahi 也談過更長期的可能性：未來某些「新增工程人力」或許可由 AI 代理與 GPU 取代；但就目前而言，Uber 仍把人類工程師放在流程中，負責判斷與把關 [5][
10]。
AI 在 Uber 工程團隊實際做什麼
最大變化不是 AI 從不會寫程式變成會補幾行，而是它從「自動完成」變成軟體交付流程裡更主動的參與者。Uber 技術長 Praveen Neppalli Naga 表示，公司已經大力投入 AI coding；95% 的 Uber 工程師每月使用 AI 工具，而內部 AI 代理每週大約產出 1,800 項程式碼變更 [13]。
但這不代表 AI 寫什麼就直接上線。Uber 最重要的控制點仍是人類審查：Khosrowshahi 說，AI 產生的程式碼在加入儲存庫前，會先由員工檢查 [10]。
Uber 的開發者生產力投資也不只限於「生成程式碼」。一場 Developer Productivity Engineering 會議介紹，Uber 正在軟體開發生命週期的各個層面投資 AI，目標是協助開發者「更快交付高品質成果」；範圍包括為大型 monorepo 客製化 coding assistant、用代理式系統處理大規模程式碼遷移，以及導入 AI 驅動的測試與程式碼審查流程 [14]。
真正的賭注是「代理式開發」
對 Uber 來說，戰略重點不只是讓工程師在 IDE 裡拿到更好的建議，而是把更多工作交給能「接任務」的工具：理解專案脈絡、處理較大的工作單元、產出程式碼，甚至準備好待審查的變更。
The Pragmatic Engineer 的內部觀察報導指出，84% 的 Uber 開發者屬於代理式 coding 使用者，也就是使用命令列代理，或在 IDE 中提出比單純 tab 補全更具代理性的請求 [8]。同一報導也提到，在 IDE 型工具內，65% 至 72% 的程式碼由 AI 生成 [
8]。
這些數字不能和 Khosrowshahi 提到的 10% 直接畫上等號。10% 指的是自主代理產出的程式碼變更；65% 至 72% 則是 IDE 工具內生成的程式碼比例 [8][
10]。換句話說，AI 可能已經協助草擬大量程式碼，但最後被歸因為「自主代理完成並合併」的變更比例，仍是另一個較窄的指標。
為什麼這會降低招聘需求
如果工程師能在同樣人力規模下交付更多成果，Uber 就能在不等比例增加員工的情況下擴大產出。這正是「AI 投資增加、招聘放慢」背後的經濟邏輯 [10]。
不過，成本並沒有消失，只是換了形式。報導指出，Uber 對 Claude Code 的使用量大增，導致 2026 年 AI coding 預算比預期更早用完；也有報導提到 Uber 使用 Claude Code、Cursor 等工具 [2][
3]。這類預算說法應視為報導中的案例，而非 Uber 全部 AI 支出的完整帳本；但它清楚反映出一個取捨：軟體產能越來越像是由人、代理、工具與算力共同組成的組合。
AI 也進入營運流程，不只寫程式
Uber 多年來已在叫車定價、司機與乘客配對等領域使用 AI [20]。較新的報導則指出，生成式 AI 與代理式 AI 也被應用到客服、司機上線流程，以及部分工程開發生命週期，減少某些營運流程中的人工介入 [
11]。
這點很重要，因為生產力故事不只發生在工程師寫程式的速度上。如果 AI 能協助診斷內部服務問題、簡化客服流程，或減少司機 onboarding 裡的手動步驟，瓶頸就不只是在 coding 工作流內被削減，也可能在更廣的營運環節中被移除 [11]。
對工程師意味著什麼
目前證據指向的是「受監督的 AI 工程模式」，不是「沒有工程師的工程團隊」。Uber 正讓代理草擬、準備並推進更多工作，但 AI 寫出的程式碼仍需由人類員工審查後才合併 [10]。同時，Uber 公開或被報導的數字更能說明採用率與程式碼活動量，未必能完整證明經審計後的精確生產力增幅。
實際影響是，Uber 正努力讓每位工程師擁有更大的槓桿。架構設計、技術判斷、審查、除錯與正式環境品質，仍需要工程師負責；但草擬、遷移、測試與重複性實作，會有更多部分交給 AI 系統處理 [10][
14]。
對招聘而言，壓力最可能落在「新增人力」上。只要 AI 工具在真實工作流中的效率提升能持續，Uber 就能繼續投資工程產能，同時比過去少增加一些新員工 [10]。
