How Uber engineering built a software factory at hyperscale: Six foundations, agentic SDLC, and cost control

Core context: AI is already part of most daily development work

Uber's scale data is best understood across four dimensions: adoption, throughput, automation scope, and unit economics.

• Adoption scope: From February to mid-August 2026, weekly active agents grew 7x and requests grew 9.4x. Users include both engineers and non-engineers, moving well beyond small-scale AI pilots.
• Development penetration: Over 70% of PRs are attributed to local or cloud agents. This indicates agents are already involved in a large share of real code changes, though Uber has not published the exact attribution methodology, so this should not be read as "70% of code is generated entirely by AI without human oversight."
• Process assets: As of August, Uber has over 3,600 agent skills executing more than 30,000 times daily. Agent capabilities no longer live only in individual chat sessions; they are increasingly codified into reusable organizational workflows.
• Managed tasks: A growing share of sessions are not initiated by humans typing prompts in real time. Code review, CI fixes, alert handling, bug debugging, and code maintenance can be triggered by events or schedules, with humans primarily responsible for goals, approvals, and escalation of anomalies.

The June AI Engineer talk also shared two throughput metrics: Uber reports that lines of code per engineer roughly doubled year-over-year, and more than 250 automated migrations have processed approximately 9 million lines of code. Automated migrations demonstrate organizational value more clearly than generating new code—large-scale dependency upgrades, API replacements, configuration migrations, and mechanical refactors that once required many teams working in phases can now be executed as a unified, batched process.

Lines of code measure output volume, not quality, business impact, or engineering value. Large amounts of low-quality code would also inflate the metric. Uber continues to rely on rollback rates, F1 scores, MTTR, and whether PRs are merged to judge whether agents delivered acceptable results.

Request volume grew 9.4x while total spend did not follow the same slope, indicating declining unit costs. However, "total cost stabilized" does not mean total cost is continuously decreasing. Model versions, task types, and adoption rates are always changing, so directly comparing monthly bills conflates multiple factors.

Uber therefore holds the model constant to examine unit economics: cost per 1,000 requests fell about 34% from the peak, and cost per session dropped 52% from the June high. The latter metric has only been tracked since late May.

These results did not emerge suddenly. Uber notes explicitly that the six-year migration to a monorepo and Bazel laid the groundwork for the software factory. Unified code organization, reproducible builds, dependency graphs, remote execution, and standardized testing allow agents to reliably locate code, modify across repositories, and verify repeatedly. When codebases remain fragmented and builds depend on individual laptops, managed agents cannot easily obtain a stable environment, let alone scale concurrency safely.

Software factory structure: four working layers and six infrastructure components

Uber describes the software factory from two complementary perspectives.

The first perspective is how work gets initiated: from humans directly operating general-purpose agents to systems automatically assigning tasks with clear boundaries. The second is what all agents commonly depend on: models, tools, execution environments, skills, organizational knowledge, and a unified product entry point.

Four working layers: the platform progressively absorbs uncertainty

The first layer is the raw interactive session. Engineers work locally with tools like Claude Code, Codex, or OpenCode, providing their own prompts, context, and process instructions. Task boundaries shift with the conversation, making it difficult for the platform to predict in advance what any given session will ultimately deliver.

The second layer is the interactive session with skills. Engineers still initiate work actively, but repetitive tasks now have shared steps, tools, and acceptance criteria. Individual experience begins to become organizational assets.

The third layer is the general-purpose managed agent. Agents run in a unified cloud environment and can invoke multiple skills. Installation, authentication, permissions, compute, and code environments no longer depend on individual machines, and the platform can observe the cost, latency, and results of every task.

The fourth layer is the specialized managed agent. Each agent corresponds to a stable outcome: Minion generates PRs, uReview performs code review, Conan AI analyzes alert root causes, and Fawkes executes periodic code maintenance. Costs can be calculated per merged PR, per review, per alert, and per cleanup, then evaluated alongside F1, rollback rates, and MTTR.

The closer a layer sits to the fourth, the more the platform can fix inputs, constrain tools, select models, supply context, run benchmarks, verify results, and escalate failures to humans. Open-ended chat leaves uncertainty for engineers to absorb; managed agents require the platform to turn uncertainty into a configurable, observable engineering problem.

Six infrastructure components: making managed agents actually runnable

1. Model Gateway: all model traffic through a single control plane

Uber routes internal applications, coding harnesses, and external use cases through a single entry point compatible with both OpenAI and Anthropic. Engineers use standard clients and only need to provide a project ID; the platform handles the rest.

The gateway has three hard requirements: personally identifiable information must not leave Uber's boundary by default; the latency overhead of new security controls must have a strict ceiling; and every request must be attributable to a specific user, project, and team.

To achieve this, requests first pass through SPIRE-based identity authentication, then a data anonymization layer scrubs over 20 categories of PII. Five dedicated models then perform security and policy checks. Uber reports that the total latency overhead stays under 100 milliseconds.

The gateway also records audit logs and session traces, feeding them into the data lake, benchmarks, and continuous improvement processes. Budget tiering, model cost analysis, and session diagnostics operate uniformly across tools precisely because model calls now carry unified identity and project attribution at this layer.

At the time of the talk, this entry point served over 800 internal projects and handled more than 100 million model requests per day. That figure spans coding and non-coding use cases, frontier and open-source models, and both internally hosted and vendor-hosted models—it should not be added directly to the agent weekly request numbers cited elsewhere.

2. MCP Gateway: unified tool access, then eliminating the token tax of tool catalogs

Uber has thousands of internal APIs, but they do not automatically become agent-callable tools. SaaS platforms like Google, Slack, and Jira each have their own authentication and installation processes.

The MCP Gateway uses an automated crawler to project internal APIs as MCP servers and also centrally hosts third-party SaaS MCPs, handling token exchange, authentication, and policy. Engineers interact with a single entry point and one installation method.

Direct MCP usage then surfaced a new scalability problem: the more tools available, the more schemas get sent to the model. Uber first launched Omni MCP, allowing one MCP to handle discovery and invocation of other tools within the gateway. Next, it projected tools as CLIs so tool definitions and large responses do not remain in context long-term. Finally, it automatically installs a code-mode skill that lets Python scripts handle loops and summarization in subprocesses.

The talk reports that this set of MCP optimizations delivered over 40% savings company-wide. An August article further detailed schema overhead and SQL comparisons; the specific mechanisms are covered later in this text.

3. DevPod: a second-level, isolated, cross-repository workspace for agents

Long-running managed agents require a more stable environment than a local terminal: fast startup, isolation between tasks, the ability to instantiate many copies in parallel, and coverage across Uber's global technical sites.

Uber repurposed its existing cloud-based remote development environment, DevPod, as the execution foundation for agents. Kubernetes balloon pods are pre-created, and repository snapshots and search indexes are prepared in advance. When an agent receives a task, it takes over an existing environment and can begin working within seconds.

The original DevPod was partitioned by technology stack—Go, Java, Android, and so on. With agents, both tasks and engineering roles began to cross repository boundaries. Uber therefore built mega-DevPod, placing multiple repositories into a single unified environment so autonomous coding agents can modify frontend, backend, and shared dependencies simultaneously.

The meaning of "managed" here is specific: the agent's code, dependencies, build tools, search indexes, permissions, and lifecycle are all prepared by the platform, rather than each engineer assembling a makeshift "AI-capable" machine.

4. Skill Marketplace: treating workflows as software products requiring governance

Uber early on saw many engineers repeatedly building the same skills across different repositories. Discovery, installation, and configuration were difficult, and the quality of some skills was inconsistent.

The platform establishes a complete lifecycle for Skills: core and domain Skills are published to a unified marketplace, where they must pass linting and automated review before reaching the quality bar for distribution. Engineers can discover and install plugins with a single command, and the platform auto-configures default Skills based on the engineer's role, letting agents pick the correct workflow without extra setup.

Launching a Skill isn't the end of the process. Uber starts collecting execution traces, user feedback, and ongoing evaluation results, then feeds failures, rework, and friction points back to the Skill authors. This way, improvements are driven by real execution data rather than by authors occasionally hearing complaints.

The June talk reported 2,500 Skills and over 20,000 daily executions; by the August post, those numbers had grown to more than 3,600 Skills and over 30,000 daily executions. This piece uses the more recent figures; the earlier numbers simply show how quickly the marketplace is still expanding.

5. Context Graph: connecting organizational context across dozens of systems

In a large monorepo, agents often can write code but lack crucial context: where a service lives, who owns it, what its dependencies are, and what engineering patterns apply. This information is scattered across code directories, service catalogs, design docs, Jira, incident systems, data catalogs, and past queries. If each of those systems required its own Skill or MCP integration, an agent would burn through a large number of tokens just to piece together the background.

Uber connects these relationships in a single Context Graph. It spans mobile, backend, data lake, design docs, incidents, bugs, teams, and service relationships, and provides unified context for on-call root cause analysis, planning, data analysis, and security scans.

The June talk described the graph as having 40 million entries and 150 node and edge types; the August post instead reports 24 million nodes, 80 million edges, 86 node types, and 117 edge types. Entries, nodes, and edges are not the same unit, so the two sets of figures can't be combined. Where this piece cites exact scale, it uses the August numbers.

6. Cortana: wrapping infrastructure in an interface anyone can use

Models, tools, environments, Skills, and the knowledge graph only accessible through internal platform APIs would still leave the software factory stuck at the infrastructure layer.

Uber built Cortana to bring these capabilities into Slack, the CLI, and the Web. An employee can ask a question in a team Slack channel; Cortana queries the Context Graph, invokes Skills, inspects any codebase, and brings the answer back into the original collaborative setting. Teams can also attach custom Skills and prompts to create a persona that understands the team's specific background.

A month before the talk, Uber had 300 team personas and was seeing more than 20,000 Cortana sessions per day. Those numbers show that the unified interface isn't just for writing code; it also supports business research, data queries, planning, and multi-person collaboration.

These six infrastructure pieces aren't a checklist of independent purchases. The Model Gateway controls how model calls are governed; the MCP Gateway controls how tools are governed; DevPod controls where execution happens; the Skill Marketplace controls which processes are available; the Context Graph controls what background agents have access to; and Cortana controls how all of it reaches real work.

How one feature moves through the full software factory

Only when these six foundations are combined does the software factory actually emerge. In the talk, Uber walked through a complete path using a World Cup feature: when a large stadium lets out, recommend a pickup point that helps passengers leave a crowded area more easily.

The example shows how work gets handed off. Different agents along the same lifecycle consume the outputs of the previous stage, call on specialized environments, and deliver verifiable artifacts to the next stage.

Step one: decide whether it's worth building at all

The team started by discussing the idea in Slack, then invited Cortana into the conversation. Using the Context Graph, Cortana researched past large-scale events, suitable venues, and potential business opportunities.

This step goes well beyond "write code from a one-line requirement." The agent first helps the team understand the problem, find internal data, and build the material for a decision. It also points to the new bottleneck emphasized at the end of the talk: as code becomes easier to generate, teams need to answer "should we build this" much earlier.

Step two: converge on requirements and experiments

The team decided to start with a North America pilot and used Cortana to help shape the Figma designs. The interface would test two button-label versions in an A/B experiment.

The requirements, release scope, experiment variables, and design spec become explicit inputs for downstream agents. Without these constraints, a coding agent is left to guess at product behavior; with them, the system has a way to judge whether the generated result actually meets expectations.

Step three: hand off from product context to a coding agent

Cortana identified which existing pages, backend capabilities, and expected code changes could be reused in the current app, then handed the task to Minion, Uber's cloud-based coding agent.

Minion can run interactively or execute autonomously. It gets a complete mega-DevPod and works on frontend and backend code in the same environment. The handoff includes requirements, design, code context, tools, and a runnable environment—far more than an isolated prompt.

Step four: produce a draft PR only; hold off on CI

Once Minion finishes the code, it stops at a draft PR and doesn't immediately push changes into CI.

This design addresses a scaling concern that's easy to overlook: as agents increase code throughput, the number of unvalidated changes grows too. If every auto-generated diff consumed full CI resources, the software factory would simply shift the bottleneck from engineer time to build queues and test infrastructure.

So Uber first requires agents to run their own validation in a cheaper inner loop, closer to the code.

Step five: push more verification into the inner loop

The inner loop includes the usual static checks, but also catches problems that previously had to wait for CI or human review:

• launch the mobile emulator;
• call a Skill to capture page screenshots;
• compare those screenshots against the Figma spec;
• start the backend staging service;
• verify that the frontend and backend actually connect;
• when something fails, fix it directly and re-run the checks.

Visual verification checks both that the page runs and that the button text, layout, and interactions in each A/B variant match the design input. A correct frontend screenshot with a broken backend endpoint still blocks the change from moving forward.

Step six: enter CI and deeper review only after inner-loop validation

Only after the inner loop is complete does the PR enter the outer loop. CI can still surface errors, and Uber's self-healing CI automatically diagnoses and fixes some of those failures.

Code review is also split into layers: the inner loop uses smaller, faster models for immediate checks; the outer loop brings in stronger models and specialized Skills for deep review. The tiering matches cost, feedback speed, and problem difficulty: small local issues need fast iteration, while pre-merge risk assessment calls for stronger reasoning.

Step seven: hand over the evidence, not just a diff

What often makes reviewers uneasy about an autonomous diff is not knowing what the agent did after producing the first version. So Uber attaches a checklist to the PR: it lists which static checks ran, which emulator validations passed, which frontend-backend integration tests ran, which CI and code review steps completed, and includes screenshots.

Humans no longer just see "these lines were generated by an agent." They see "this change went through these steps, these checks passed, and here's where human judgment is still needed." Human review hasn't disappeared; it now has better evidence, and reviewers can focus on requirements, risk, and anomalies.

This pipeline reveals the core shift behind the software factory: the unit of development is no longer just code files, but a task package that spans requirements, design, implementation, and validation evidence—readable and processable by machines at every stage.

Cost breakdown: how six multipliers apply to the software factory

Uber breaks down total agent spend with a multiplicative formula:

Total cost = number of users × sessions per user × turns per session × requests per turn × tokens per request × price per token

Each of the six terms has a different management goal:

The first two terms represent adoption and engagement. When the software factory works, they should keep growing. Uber focuses on compressing the middle three: the extra work an agent creates beyond what's needed to achieve the user's goal, whether from searching, polling, retrying, or carrying redundant context. The final term is controlled by model selection.

The multiplicative structure amplifies small waste. A tool schema that's never used but is included in every request gets multiplied across turns, sessions, and users. A poorly contextualized task that takes ten turns of searching, each carrying a growing history, inflates both the request count and the token count at the same time.

Uber therefore tracks five layers of metrics: total company-attributed cost, unit economics per tool, request and cost share by model, a breakdown of what drives cost changes, and the resulting cost and quality of hosted agents.

What actually needs optimizing is the cost per outcome: what does it cost to complete a solid review, land a PR, handle an alert, or clear technical debt—and is quality maintained? Looking only at how cheap a million tokens are can't answer that.

Cost method one: let real tasks decide the model mix

Model vendors set token prices; Uber decides which model handles which task. Instead of relying on general-purpose leaderboards, it builds real business benchmarks for each class of hosted agent.

For uReview, for example, Uber built an evaluation set from real PRs with known bugs, then rated each one as easy, medium, or hard. Each model configuration runs in the same harness, which records:

• precision, recall, and F1;
• the actual cost per review;
• latency, timeouts, and output noise;
• whether the task is completed consistently.

Only configurations on the cost-quality Pareto frontier are selected. A Pareto-optimal point means there's no other configuration that is both cheaper and keeps quality constant, or both higher quality and keeps cost constant. Model capabilities shift constantly, so that frontier can move every few weeks—model routing is an ongoing evaluation effort.

Interactive agents use a tiered setup with a lead agent and sub-agents. The lead agent understands the goal, breaks down the task, assigns work, and checks the result, defaulting to a stronger model. Sub-agents get narrower, more clearly specified inputs and default to cheaper models, with an option for manual override.

The full SDLC shows another kind of tiering: inner-loop review needs low latency, so it can use a smaller model; outer-loop review handles deep pre-merge risk assessment, so it uses a stronger model with specialized Skills.

Cheap models only deliver real savings when the task boundary is clear and the result is verifiable. If the lead agent decomposes the task incorrectly, the tools are incomplete, or the system can't determine when a job is actually done, the rework from low-cost calls can easily exceed the price difference between models.

A typical team can start by building a small benchmark around concrete tasks like code review, dependency upgrades, test generation, or Feature Flag cleanup. The benchmark should evaluate whether a result is acceptable — not whether a model's output merely looks clever.

Cost method two: compress requests, tool calls, and blind search

Every agent turn typically resends the conversation history, project context, tool definitions, and tool results. As long as useless information stays in context, subsequent requests keep paying for it. Uber reduces payload from five angles: default parameters, caching, tool protocols, execution patterns, and organizational knowledge.

1. Compress proactively before the long context spirals out of control

Even when a model supports a 1 million token context, Uber's interaction harness triggers automatic compression at 400,000 tokens. Maximum context capacity is not the same as economical capacity. The longer the history, the more expensive each repeated turn becomes — and rebuilding a prefix after a cache miss costs even more.

Reasoning effort defaults to Medium. Output tokens and internal reasoning tokens usually cost more than input tokens, and Medium delivers a good quality-to-cost balance for most everyday tasks. Hard problems can still bump up the reasoning level, but the high setting is no longer the default for every session.

2. Configure cache TTL around real session cadence

Prompt caching can reuse a context prefix that has already been sent. Based on the pricing provided: cache reads cost roughly 0.1× a normal input, a 5-minute cache write costs about 1.25×, and a 1-hour cache write about 2×.

Longer TTL writes cost more, but engineers frequently step away to check docs, wait for a build, or attend a meeting. With a 5-minute cache, those sessions expire constantly, and the next turn pays full price to rebuild the prefix.

Uber adjusted the human-interaction main thread from 5 minutes to 1 hour, while keeping 5-minute TTLs for sub-agents that only handle short tasks. The right approach is to measure real turn intervals first, then set TTL accordingly — rather than forcing every workflow into the same cache duration.

3. Load MCP tools on demand and remove the tool catalog tax

Standard MCP injects the full schema of every installed tool into the context at session startup. Uber measured that installing over 100 tools adds roughly 50K–70K tokens to the initial prompt, and those tokens get resent on every subsequent turn. Stack several large SaaS MCPs and the tool descriptions can end up longer than the file you're trying to edit.

Uber uses two paths to eliminate the fixed tax. The CLI dynamically resolves target tools at call time, so more than 1,000 tools never need to enter the context upfront. Tool search queries the catalog first and only loads schemas that the current task actually needs.

The unified gateway still handles authentication, policy, audit, and metering. What changes is only when the model sees tool definitions — and whether the raw tool response has to stay in the conversation history.

4. Code-mode keeps polling, loops, and large results inside the sandbox

An asynchronous SQL query typically involves submitting a job, grabbing a run ID, polling for status 2–5 times, and then reading the results. Standard tool calling pulls the model into every step, so all that intermediate state lands in context.

Code-mode has the model generate a Python script, and a subprocess handles submission, polling, filtering, and summarization. Only the final summary gets returned to the model. Interaction turns drop from 3–7 down to a single script execution.

Even small result sets save more than half, which shows the gain isn't just from filtering wide tables. Schema initialization, multi-turn polling, repeated state, and step-by-step reasoning all get moved out of the model context. Batch workflows collapse N model turns into a single script run, with savings exceeding 90%. Uber has already deployed 25+ prebuilt code-mode skills for common MCP services.

5. Context Graph gives the agent the right entry point before it acts

An agent without organizational context tends to fail slowly. When it can't find the service owner, data table, historical PR, or incident record, it keeps searching repos, opening docs, launching sub-agents, and retrying tools. Each wrong branch adds a request — and makes the next turn carry an even longer history.

Uber's AI Context Graph connects 30+ internal systems and contains 24 million nodes, 80 million edges, 86 node types, and 117 edge types, covering services, teams, incidents, PRs, architecture docs, deployments, datasets, and historical table usage.

In a side-by-side comparison using the same internal question and the same model, the agent with Context Graph made 4 tool calls and found the correct data table — one used by 50+ analysts — in 38 seconds. The agent without the graph took 20 minutes and 9 seconds, spawned 2 sub-agents, hit 3 errors, and concluded — incorrectly — that the data was unavailable.

That is a single internal case study, so don't assume every task will see the same speedup. But the mechanism it reveals is robust: better background context simultaneously reduces search requests, error branches, idle time, and rework.

A small team doesn't need to build a multi-million-node graph first. Start with the most common lookup failures: service catalogs, code owners, historical PRs, incident records, frequently used data tables, alerts, and deployment logs. The goal is to give agents the right entry point before they start searching blind.

From real-time cost to managed maintenance: closing the feedback loop

A software factory has two feedback loops. The first handles reducing waste within a single session. The second handles improving an automation over the long run.

Session feedback: make waste visible the moment it happens

Uber's terminal status bar continuously shows token count, context usage, current session cost, and reasoning effort. All interaction harnesses share one budget tier; managed agents use a separate tier. Slack alerts fire at 50%, 80%, and 100% of expected spend, and exceeding a tier requires manager approval.

The status bar lets an engineer decide mid-session whether to switch models, compress the context, split the task, or stop a wrong-headed search — instead of discovering the damage when the monthly bill shows up.

A session-level analytics dashboard goes further, reading traces from local and cloud sandboxes to identify 16 categories of wasteful anti-patterns:

• Using an oversized model for simple multi-turn tasks;
• Leaving a 40KB MCP response in the history, where subsequent requests get billed for it repeatedly;
• Resuming an old session after a long pause, only to find the cache has expired;
• Preloading 100,000 tokens of system instructions and tool definitions before the user has even typed a task.

Diagnostics aren't just for individual education. When the same problem keeps appearing, the platform team modifies the default model, TTL, skills, tool gateway, or context provisioning — so the next batch of sessions starts from better defaults.

Maintenance feedback: automated loops need unified scheduling and outcome labels

After feature work ships, the software factory still has to deal with Feature Flag cleanup, dependency upgrades, and recurring maintenance. Uber lets services opt into maintenance skills, but it doesn't let each team spin up its own permanent agent loop.

Periodic tasks go into a unified managed loop. The platform can schedule maintenance for Sunday, when CI capacity is lighter, and can cap the number of automated PRs sent to engineers on Monday morning. That solves two practical problems: background agents can't endlessly compete for build resources, and engineers don't get flooded with low-priority diffs.

Diffs generated by maintenance skills get commented on, merged, or rejected. Those outcomes become real labeled data, feeding back into evaluation and improvement of the skill. Uber also plans to extract recurring, repeatable fix patterns from incident reviews about once a month, turn them into new maintenance skills, and apply them to more services.

That creates a closed loop: incidents surface patterns, the team encodes patterns as skills, the managed loop executes skills, PR outcomes generate labels, and the labels improve the skill. Automation doesn't rely on one perfect prompt; it accumulates organizational experience through controlled operation.

Human review owns goals and exceptions

Even fully managed loops require explicit human responsibility. People decide whether a task is worth doing, whether the requirements make sense, whether the risk is acceptable, and how to handle exceptions that agents can't reliably judge.

The platform handles repetitive execution, environment prep, evidence collection, and common fixes. Humans shift their attention away from step-by-step operations and toward goals, acceptance criteria, and boundaries. PR checklists, screenshots, cost traces, and skill run logs all serve as evidence for this division of responsibility.

New bottlenecks and an adoption guide: from writing faster to system throughput

When agents generate more code, the existing engineering system absorbs new pressure.

First, CI capacity. As automated diffs grow, build, test, and simulator resources may run out first. Uber shifts validation earlier in the pipeline and schedules maintenance work based on available capacity.

Second, experimentation capacity. The product team can generate far more options quickly, but user traffic, experiment cycles, and statistical resources stay fixed. No team can run unlimited A/B tests at the same time.

Third, decision capacity. As implementation costs fall, organizations find it easier to answer "can we do this?" — but they still have to answer "should we do this?" Business value, risk, user experience, and strategic prioritization don't resolve themselves just because code generation got faster.

Uber's practices can be distilled into a phased implementation roadmap.

Step one: build a repeatable engineering foundation

Standardize code organization, builds, testing, dependencies, and remote development environments. If an agent can't reliably reproduce an engineer's build, all subsequent autonomous operation only amplifies environment problems.

Step two: consolidate model and tool access

All model calls go through a unified gateway to gain identity, project, team, and cost attribution. Internal APIs and SaaS tools connect through the MCP Gateway for unified authentication and policy. Without a control plane, budgets, audits, and model routing all fragment.

Step three: start with one measurable result

Pick work with clear boundaries: code review, dependency upgrades, test generation, feature flag cleanup, or alert triage. Define both the unit of output and the quality bar for each — per review, per merged PR, per alert — and tie those to measurable outcomes like F1 score, rollback rate, MTTR, or manual acceptance.

Step four: Turn work into skills before you turn it into agents

Codify the task inputs, steps, tools, and acceptance criteria into a Skill, then govern its quality and versioning through a shared marketplace. Only workflows that are repetitive, have stable boundaries, and produce verifiable results should graduate into always-on, auto-triggered agents.

Step five: Set up the environment and context before the agent runs

Spin up isolated environments ahead of time, and prepare code snapshots, search indexes, and cross-repo capabilities. Connect each task to the right service owner, historical PRs, incident records, and data catalogs. When an agent gets assigned a task, it should already have the correct entry points — not spend ten turns guessing how the org is structured.

Step six: Shift validation earlier — and hand over evidence

Run static analysis, simulators, visual comparison, and frontend/backend integration checks before queuing up full CI. A PR should contain more than code: include a checklist, relevant screenshots, and a record of what's already run so a human can review efficiently and confidently.

Step seven: Write down the six cost factors

Instrument usage separately across users, sessions, turns, requests, tokens, and per-model unit prices. Watch for hidden spending in conversation history, system instructions, tool schemas, polling loops, and large result payloads. Load anything lazily instead of preloading it, and keep the model out of polling loops where a simple script can handle the cycle.

Step eight: Keep selecting models based on real tasks

Build a benchmark set with known answers and known failure modes, and log quality, latency, timeouts, noise, and actual spend for every model candidate. The lead agent, sub-agents, inner-loop reviews, and outer-loop evals don't all have to run on the same model — but every routing decision should be made on demonstrated outcome quality.

Step nine: Centralize control of long-running loops

Periodic maintenance jobs should be bounded by budget, CI capacity, task frequency, and PR volume. Treat comments, merges, rejections, and incident retros as data to improve the Skill itself. Don't let every team run its own unobservable cron-driven agent in a corner.

Step ten: Re-engineer the organizational bottlenecks

Continuously watch CI queue depth, experiment capacity, and review load. Once code generation speeds up, the bottleneck shifts — and the investment focus should move toward verification infrastructure, product decisions, and priority management.

Uber was able to scale agent throughput while holding per-unit cost down because it rebuilt software development as a measurable production system. Models, tools, environments, Skills, knowledge, and product entry points all sit under unified control. Tasks have clear handoffs from intake through ongoing maintenance. Every agent has outcome metrics and an eval set. And every incident of waste or failure eventually feeds back into platform defaults and Skill improvements.

A 9.4x increase in requests with roughly flat total spend is the financial result of that system operating at scale. The deeper change is that engineers no longer have to perform every mechanical step themselves — but the organization has to be far more explicit about what's worth doing, what counts as done, and which risks only a human should judge.