この取り組みはコードの下書きにとどまらない。DPE.orgに掲載されたUberの開発者生産性に関するセッション概要では、ソフトウェア開発ライフサイクル全体を対象に、巨大なモノレポを理解するコーディング支援のカスタマイズ、大規模コード移行向けのエージェント型システム、AIを使ったテストやコードレビューのワークフローが挙げられている 。
ただし、最終的な制御点はレビューにある。コスロシャヒは、AI生成コードはリポジトリに追加される前に社員がチェックすると説明している 。Uberが使っているのは、作業を作り、準備するエージェントであって、無監督で本番開発を任せる仕組みとしては語られていない。
一方、The Pragmatic Engineerは、Uberの開発者の84%がエージェント型コーディングの利用者だと報じた。これはCLI型エージェントを使っているか、IDE内で単純なタブ補完よりも自律的な依頼を多く行っている開発者を指す 。同じ報告では、IDEベースのツール内で生成されたコードの65〜72%がAI生成だったともされている
。
つまり、これらは同じものさしではない。自律エージェントによるコード変更、エージェント型ワークフローの利用率、IDE内でAIが下書きしたコード量を別々に見ている。実務上の読み方は、AIがコード作成を助ける範囲はかなり広い可能性がある一方で、最終的に取り込まれる変更のうち自律エージェント由来として数えられる割合は別の指標だ、ということになる 。
ただし節約だけではない。コストの一部は、人件費からAIツール、エージェント、計算資源へ移る。報道によれば、Claude Codeの利用急増で、Uberは2026年分のAIコーディング予算を想定より早く使い切り、Claude CodeやCursorといったツールを使っている 。この話だけでAI投資全体の採算を判断することはできないが、ソフトウェア開発能力が「人、エージェント、ツール、インフラ」の組み合わせとして計画されつつあることは示している。
最近の報道では、生成AIとエージェント型AIは、カスタマーサポート、ドライバーのオンボーディング、エンジニアリング開発ライフサイクルの一部にも適用され、一部のワークフローで人手による介入を減らしているとされる 。
これは採用抑制との関係でも重要だ。サポート対応を早める、オンボーディングを簡素化する、社内サービスの問題診断を助けるといった効果が出れば、以前なら人員増で解消していたボトルネックを、同じ人数またはより少ない追加人員で処理できる可能性がある 。
現時点のUberの姿は、「エンジニア不要」ではなく「監督付きAI開発」に近い。エージェントはコードの下書き、変更案の準備、移行作業、テストやレビュー支援を担うが、AIが書いたコードは人間が確認してから取り込む 。
影響が大きいのは、既存職の即時削減よりも、追加採用の伸び方だろう。AIツールが実際の開発フローで安定した効果を出し続けるなら、Uberは以前なら採用で補っていた開発能力の一部を、エージェントやツールでまかなえる 。
ただし、AIツールの利用率やAI生成コードの比率は、品質、信頼性、保守性、長期的な開発コストまで含めた正確な生産性向上を、そのまま証明する数字ではない。Uberの事例が示しているのは、AIが開発組織の人数計画に入り込み始めたことと、その運用がまだ人間の判断に強く依存していることだ。