Как эффективно управлять Software Factory в масштабе Uber

Оригинал опубликован Uber Engineering в X. Автор поста: @udaykiran.

Введение

AI-инструменты в Uber уже встроены во все этапы разработки ПО. Более 70% pull request связаны с локальными или облачными агентами. Инженеры создали более 3 600 agent skills по всему жизненному циклу разработки ПО, а число запусков agent skills превышает 30 тысяч в день.

На конференции AI Engineer 2026 мы рассказали о нашем видении Software Factory, а также о строительных блоках и управляемых агентах, которые создаём для всего жизненного цикла. По мере движения к этой модели всё большая доля сессий запускается не людьми, а автоматизированными managed agents: они занимаются code review, self-healing CI failures, доводят E2E PR до завершения с visual validation, триажат on-call alerts, отлаживают входящие баги и выполняют разные задачи по сопровождению кода с human reviews/escalations.

Как показано на рисунке 1, с февраля по август 2026 года число weekly active users во всех agentic-предложениях среди всех наших сотрудников, инженеров и не инженеров, выросло в 7 раз, а weekly agentic requests — в 9,4 раза. При этом общий расход на AI относительно стабилизировался с апреля благодаря оптимизациям по всем направлениям.

Поскольку adoption, состав workload и обновления моделей постоянно меняются, для изоляции собственных оптимизационных улучшений нужно держать одну модель фиксированной: поведение меняется с каждым обновлением и с каждой модельной семьёй. Мы сделали это на промежутке с февраля по июль: стоимость 1 000 model requests снизилась почти на 34% от пика, а стоимость сессии — на 52% от июньского пика.

В этой статье мы показываем, как думаем о нашей software factory: четыре слоя, в которых выполняются agent sessions, формулу стоимости, с помощью которой раскладываем расходы, то, как измеряем каждый член формулы, и то, как оптимизируем эти члены на каждом слое.

Все цены и vendor metrics в этом сравнении основаны на публично доступной информации; улучшения cost efficiency получены за счёт более умного роутинга внутренних workload Uber внутри стандартной tier-pricing. Хотя конкретные сокращения затрат, которые мы измеряем, уникальны для нашей среды, и ваши результаты будут зависеть от кодовой базы, размера команды и agent workflows, сама методология benchmarking реальной работы и оптимизации accuracy/cost применима универсально.

Software Factory и её формула стоимости

Четыре слоя использования агентов

Мы организуем использование AI в четыре слоя: от самых специализированных до самых общих. Как показано на рисунке 3, чем выше слой, тем больше у нас контроля над стоимостью, качеством и выбором модели.

Формула стоимости

Для любого из слоёв выше стоимость agentic session можно разложить на следующие члены, которые мы можем измерять и оптимизировать независимо.

Первые два члена отражают adoption & engagement, которые мы хотим продолжать растить по всей пользовательской базе: независимо от того, используют ли люди инструменты интерактивно или агенты выполняют задачи от их имени. Три средних члена дают возможности для оптимизации: это работа, которую агент делает “для себя” сверх исходного запроса инженера. Именно туда уходит основная часть наших усилий. Сюда входят механизмы, которые помогают агентам быстрее планировать, сокращать нежелательные ходы или ошибки, оптимизировать входные токены и многое другое.

Как мы измеряем

Ниже полный набор метрик, которые мы отслеживаем еженедельно и ежемесячно, чтобы прогнозировать и планировать усилия на коротком и длинном горизонте.

Рычаги оптимизации

В следующих разделах мы подробно разбираем ключевые рычаги, которые использовали для оптимизации каждой части формулы стоимости. Некоторые из них влияют на одну или несколько строк формулы.

Оптимизация Price / Token

Цену токена задаёт vendor. Мы выбираем, какая модель выполняет какой workload. На всех слоях наших managed agents мы выбираем модель, которая является Pareto efficient для конкретной нагрузки. Для нас Pareto efficient означает cost/completed task, output quality и model reliability.

Benchmark-driven model selection

Выбор модели происходит в четыре шага, одинаковых для каждого managed agent, которого мы запускаем.

• Собрать benchmark из реальной работы агента.
• Запустить агента на harness, который обслуживает любую модель, frontier или open-weight, через единый интерфейс.
• Перейти на то, что является Pareto optimal, и продолжать двигаться дальше. Frontier сдвигается каждые несколько недель.

Дальше мы постоянно улучшаем производительность workload, используя агрегированные инсайты от managed agents для тестирования и внедрения разных стратегий model routing.

Например, мы используем uReview, который выполняет AI code review для всех pull request. Его benchmark построен на реальных pull request с известными багами, разделёнными на easy, medium и hard. Мы считаем precision, recall и F1 по этим багам, а также cost per review, latency, timeouts и noise. Как показано на рисунке 5, смена моделей улучшила F1 и резко снизила cost/PR. Пунктирная линия на графике — Pareto frontier. Всё ниже и левее неё проигрывает чему-то более дешёвому или более качественному.

На тысячах реальных PR в наших больших monorepos мы также внутри Uber поддерживаем Uber SWE Benchmark, который прогоняет frontier и open-weight модели на разных типах задач. Мы используем его для выбора моделей во всех SDLC-managed agents.

Default model selection

В интерактивном интерфейсе unit cost токенов остаётся фиксированной; однако можно стратегически управлять распределением токенов между моделями. На это главным образом влияют две default settings: initial session model и subagent model.

Default setting для subagent оказался самым сильным рычагом, и его значимость продолжает расти. Доля сессий, запускающих subagents, стабильно увеличивается, потому что новые возможности моделей позволяют эффективнее оркестрировать multi-agent work. Поскольку subagents выполняют чётко определённые задачи с заданными inputs и часто не требуют frontier-level reasoning, мы по умолчанию отправляем их на более слабую и более экономичную модель, сохраняя возможность ручного override. Основная модель отвечает за декомпозицию задачи и оценку, а subagents выполняют работу.

Оптимизация Tokens / Request

Каждый turn заново отправляет полную историю разговора, project context и tool results. Всё, что уменьшает payload на запрос, компаундится на протяжении всей сессии.

Defaults

Все interactive harnesses используют единый wrapper для installation management, configuration, authentication и cost visibility. Две стандартизованные настройки по умолчанию напрямую снижают расход токенов на запрос:

• Automatic compaction запускается на 400k токенов даже для моделей с context window 1M: этот порог балансирует качество модели против cache bursts и повторяющейся стоимости input tokens. Наши измерения показывают заметное снижение fleet-wide input tokens per request.
• Reasoning effort по умолчанию установлен на Medium: output tokens, включая internal reasoning tokens, тарифицируются на primary models с множителем относительно input tokens; эта настройка напрямую снижает расходы в самой дорогой категории токенов. Для большого класса задач Medium reasoning даёт хороший баланс cost vs quality.

Prompt caching strategy

Стратегия prompt caching определяется экономикой provider prompt cache reads and writes. Поскольку каждый turn заново передаёт полный conversation history, кеширование предшествующего контекста позволяет не платить полную стоимость повторно: последующие reads стоят всего 0,1x от стандартного input token rate. Однако premiums за запись отличаются: 5-minute cache entries стоят 1,25x, а 1-hour entries — 2x. Поэтому выбор оптимального TTL (Time-to-Live) зависит от длины пауз между ходами. Доступные TTL options включают 5 минут и 1 час у Anthropic®, а также 30 минут у OpenAI®.

Поскольку инженеры часто оставляют interactive sessions idle больше чем на 5 минут, мы перешли с default 5-minute TTL на окно в 1 час. Раньше такие частые паузы инвалидировали prefix cache и заставляли заново строить контекст по полной цене. Sub-agents, напротив, сохраняют 5-minute cache TTL, потому что их выполнение ограничено одной короткой задачей.

Executing MCP Tools via the Shell

В Uber все MCP (Model Context Protocol) interactions проходят через единый gateway. Эта точка входа охватывает более 1 000 MCP servers, включая внутренние и third-party SaaS MCP, и даёт централизованную аутентификацию и policy enforcement.

Однако стандартный MCP загружает все tool schemas прямо в каждую сессию, независимо от того, понадобится ли инженеру хоть один из этих инструментов. Например, при более чем 100 установленных tools такой preload добавлял примерно 50K-70K токенов schema overhead к initial prompt, а затем этот overhead заново отправлялся на каждом context turn.

Чтобы убрать это context bloat, мы ввели два взаимодополняющих механизма оптимизации:

• CLI tool resolution: заменяет direct MCP integration, позволяя модели выполнить shell command. CLI динамически находит и вызывает нужный tool через gateway во время вызова, устраняя Uber MCP schemas из session context. Все 1K+ MCP tools из нашего внутреннего MCP gateway проецируются как CLI commands.
• Tool search: масштабируется на тысячи tools, позволяя модели искать каталог tools и загружать только нужные on demand. Этот подход снижает token usage для tool definitions и сохраняет высокую точность выбора даже при росте библиотеки tools, предотвращая деградацию, связанную с большими наборами инструментов.

Code-mode

Когда tools вызывают функции напрямую как shell commands, модели могут batch multiple actions внутри одного script. Это особенно полезно для chatty tool protocols. В стандартных MCP workflows каждое действие требует отдельного model turn: отправить request, загрузить raw response в context window и последовательно обработать результат. Например, один SQL query требует отправить запрос, 2-5 раз опросить status и получить output. Code-mode превращает всё это в автоматизированный Python loop, удерживая промежуточный polling вне активного контекста модели. Как показано на рисунке 8 слева, модель участвует в polling loop, и каждый response попадает в её context. Справа loop выполняется в subprocess, и назад возвращается только summary.

Мы измерили это, запустив 5 одинаковых SQL queries через оба пути в одной сессии:

Первые три строки показывают главный вывод: даже для минимальных result sets, намного ниже лимитов размера response, code-mode снижает token usage более чем на 50%. Эти выигрыши возникают не из-за обхода больших data payloads, а из-за устранения лишнего overhead: schema initialization, multi-turn polling и избыточного пошагового reasoning.

В bulk workflows эффект компаундится: loop, который раньше был бы N model turns, становится одним script, а экономия вырастает более чем до 90%. Развернув более 25 pre-built code-mode skills для самых часто используемых MCP servers, мы добиваемся того, что стандартные workflows по умолчанию идут наиболее экономичным путём.

SaaS MCPs

Управлять third-party software оказалось значительно сложнее, чем внутренними серверами. Vendors проектируют MCP servers так, чтобы раскрыть полные возможности продукта, потому что не могут предугадать usage конкретного клиента. Например, workspace suite объединяет 49 tools в одном server и требует около 22K токенов schema; messaging и project tracking vendors поставляют 34 и 46 tools соответственно. Загрузка двух-трёх vendor servers заставляет агента нести больше schema overhead, чем весит файл, который нужно отредактировать, ещё до того, как пользователь введёт prompt.

Чтобы решить это, мы пропускаем SaaS MCP servers через наш MCP gateway тем же способом, что и внутренние MCP. Мы также экспонируем все эти MCP как CLI, которые может вызывать любая agentic surface. Дополнительно мы пишем dedicated skills внутри code-mode plugin для каждого server, чтобы инкапсулировать типовые workflows. Это открыло эффективные agentic workflows во многих SaaS vendors.

Optimizing Requests / Turn

Незаземлённый agent проваливается медленно, а не дёшево: он снова и снова отправляет растущий context window, чтобы поискать ещё в одном месте. Более богатая информация upfront остаётся самым сильным рычагом снижения этого search overhead.

Context Engineering

В огромной кодовой базе и data ecosystem Uber, включающей сотни миллионов строк кода и тысячи таблиц, агенты тратят большинство ходов на поиск информации, а не на генерацию кода. Чтобы решить это, мы спроектировали AI Context Graph: единую сеть с 24 миллионами nodes и 80 миллионами edges, охватывающую 86 node types и 117 edge types. Она интегрирует данные из более чем 30 внутренних систем, включая services, engineering teams, incident logs, pull requests, architectural design docs, deployments, datasets и historical table usage queries, и позволяет любому agent задавать запросы к ней на natural language.

Grounded agent запросил historical usage, нашёл конкретную таблицу, которой пользовались более 50 аналитиков, и дал ответ за 38 секунд. Ungrounded agent, напротив, не видел эту таблицу: он 20 минут исследовал service code, запустил 2 subagents, получил 3 errors и в итоге неверно заключил, что dataset нельзя запросить.

Visibility & Education

Здесь рычаги — visibility и feedback loops, которые помогают инженерам и агентам быстрее сходиться к правильному результату.

The Status Line

Мы добавили live cost counter в status line harness: он отслеживает текущие расходы по конкретному harness и по всем harnesses для каждого пользователя.

Visibility and Spend Tiers

Чтобы не вводить жёсткие caps, мы реализовали real-time spend tracking и automated nudges:

• Statusline live counter. Стоимость текущей сессии всегда видна в терминале.
• Harness pool. Один общий tier для всех interactive harnesses, а не отдельные бюджеты на tool. Для managed agents используются отдельные tiers.
• Slack nudges. Alerts на 50/80/100% ожидаемого расхода, чтобы инженеры успевали планировать.
• Easy approval flows. Manager sign-off для tier upgrades с быстрым распространением изменений.
• Cost check skill and tips. Dashboard skill для on-demand cost breakdown и live status line coaching.

Это позволяет инженерам самостоятельно оценивать ROI задачи и одновременно снижает риск runaway expenses.

Session Analysis Dashboard

Хотя status line показывает общий расход сессии, ему не хватает видимости cost drivers и конкретных efficiency steps. Общие рекомендации дают high-level principles, но не могут оценить индивидуальные developer workflows. Session analysis dashboard закрывает этот разрыв, анализируя session artifacts напрямую.

Он встроен прямо в runtime и не требует setup или opt-in. Запуск cost dashboard skill анализирует все session traces пользователя по локальным и удалённым cloud sandboxes во всех harnesses, которыми он пользуется. Вместо агрегированной метрики он отмечает 16 конкретных anti-patterns по сессиям, связывая каждый с финансовым impact и targeted remediation. Среди категорий:

• Suboptimal model routing: простые multi-turn sessions выполняются на Opus, хотя Sonnet легко справился бы.
• Context window bloat: большие MCP payloads, например responses на 40KB, остаются в context и повторно тарифицируются на последующих turns.
• Cache expiration inefficiencies: возобновление сессий после долгих пауз, когда истёкший prompt cache заставляет заново строить prefix по полной цене.
• Prompt initialization overhead: preload 100 000 токенов system instructions и tool definitions до любого пользовательского input.

Что дальше?

Текущие инициативы в работе:

• Рост fleet managed agents: для каждого нового agent мы следуем единой roadmap: определяем target outcome metrics, собираем evaluation benchmarks и находим Pareto-optimal model. Этот системный подход должен поднимать каждый этап SDLC выше по factory maturity model.
• Dynamic Model Routing: мы расширяем benchmark coverage на разные programming languages, code repositories и agent modalities. Эффективный model routing сильно зависит от comprehensive evaluation, потому что возможности моделей сильно различаются.
• Углубление интеграции context graph: мы открываем graph query capabilities для более широкого набора autonomous agents.
• Развитие session analytics в real-time developer guidance: переходя от периодического batch detection anti-patterns к continuous trace monitoring, мы хотим давать персонализированные real-time efficiency recommendations прямо инженерам.
• Continuous Skill Improvement: мы работаем над автоматическим способом записывать papercuts из agent skill executions и auto-generate skill updates из собранных traces.

Заключение

Управление растущими расходами на AI coding и их сдерживание — тоже решаемая инженерная задача. Устраняя wasted, zero-value token consumption, а не полагаясь только на более низкие unit prices или downgrade tooling, мы масштабировали usage в 7 раз и одновременно снизили unit costs по всем метрикам, сохранив или улучшив output quality.

Ключевой стратегический сдвиг — переход от interactive developer workflows к fully managed agents. Перенос SDLC workloads в managed environments даёт полный контроль над model routing, execution harnesses и operational spend. Оптимизация fleet специализированных managed agents, каждый из которых связан с dedicated evaluation benchmarks и Pareto-efficient model, по природе более cost-effective и scalable, чем оптимизация отдельных terminal sessions среди тысяч инженеров.

Благодарности

Это коллективная работа многих инженеров, которые создают самые эффективные блоки для реализации Software Factory в масштабе Uber, одновременно следя за ROI каждого потраченного токена. Мы хотим поблагодарить core team, участвовавшую в разных направлениях Software Factory: Abhishek Bhatia, Adam Huda, Aditya Patel, Alok Srivastava, Ameya Ketkar, Anil Purohit, Atakan Kandemir, Ben Chou, Brandon Barker, Danielle Yim, Deepanshu Mehndiratta, Gaurav Gill, Israel Marban, Jason Varbedian, Karen Xu, Lei Shi, Mager Mager, Meghana Somasundara, Peng Liu, Preet Inder, Qiushen Wang, Rush Tehrani, Shesh Patel, Shiven Tripathi, Shubham Gupta, Stas Khalup, Ting Chen, Tse-Shi Wang, Ty Smith, Vikram Hullukunte, Weiqiang Wang, Will Bond.

Также благодарим Johannes Gehrke, Mattie Toia, Sumanth Sukumar и Praveen Neppalli Naga за leadership.

Anthropic® — registered trademark Anthropic PBC. Claude Code™ и Claude® — trademarks Anthropic, PBC. OpenAI® и её логотипы — registered trademarks OpenAI®.