The Software Factory Runs in the Cloud. Local Is the Exception.

Most coding agents today run on one laptop. It works for now because it fits the old way of working: each developer working on their own tasks. But it’s changing now. As we move from local development to software factory, its actually economics that forces the software factory to run in the cloud. 

The Economics Only Work on a Fleet

Uber's account of running a software factory gives the clearest explanation of the transition from local development to a software factory. To build an efficient software factory, you’ll need some capabilities like model router, spend control, and execution harnesses. In order to control those across all teams, they need to be working on managed (cloud) agents

A growing share of their sessions now start without a human at all, handling code review, self-healing CI failures, end-to-end pull requests with visual validation, on-call triage, and routine maintenance.

What makes those sessions cheaper is specialization. A managed agent does one job, so you can test it and pick the model that fits that job best. Their code review agent, uReview, was run against real pull requests with known bugs and measured on how many bugs it caught, how often it flagged things that weren't bugs, and what each review cost. Switching models caught more real bugs for less money per review. Every managed agent then gets priced by outcome: cost per merged pull request, cost per review, cost per alert, cost per cleanup.

None of those decisions or optimizations are possible on a laptop. There's no way to test an agent that does whatever a developer happens to ask today, nor o way to route a narrow task to a cheaper model when the task isn't narrow, and no unit of work to divide the cost by. The interactive, multiplayer session is the layer where you control the fewest of them, which is exactly why the work is moving off it.

The Limit: One Laptop Can Only Ask One Person

Shipping software has always taken more than one person's judgment. But, an agent running locally on a laptop can only ask the person sitting at it. That's fine when the question is about code structure, something the developer should be an expert in. What happens when the question belongs to someone else, though?

For example:

All of it lands on the developer regardless, because the developer is the only person the agent can reach when developing locally.

To fix this, the factory needs to run a session that can reach whoever owns the decision. Without being able to reach the right stakeholder, an agent may guess at the answer. To find the right person, that means the software factory has to know which team owns the service being changed, how critical it is, and who signs off at that level of risk. None of that is in GitHub, Jira, or your cloud provider. It's a map of your organization that someone has to build and keep current. Normally, this falls on the platform team.

What can remain local?

Cloud software factories won’t necessarily take everything in the SDLC and run it remotely. There are a few parts of the SDLC that can stay local.

Planning is the most obvious one. Before anything becomes a tracked workflow, someone is exploring an idea and talking it through with an agent, and that doesn't need a factory around it.

Picking up a stopped session is the other. When an agent pauses mid-task and needs a correction, the developer should take over directly.

Local isn't gone. But it does become the exception rather than the norm.

The Rules Have to Live in One Place

When the agent ran on your laptop, the rules ran with it. Your setup, your model, your sense of what was ready to ship, none of it written down anywhere.

The factory can't infer any of that, which makes it the platform team's job to deliver: the engineering context in a shape agents can use, the registries of agents and skills and MCP servers, which actions are allowed and when, where a human signs off, and what the whole thing returns.

That only works if it lives in one place the agents read from. A platform team can't configure a thousand laptops, and shouldn't have to, because a rule written once should apply to every agent run that touches the service it covers. Cloud execution is what makes that possible. The agent is already running somewhere the platform team controls, so it picks up the current rules at the start of every run instead of whatever was copied into a repo six months ago.

The Factory Doesn't Own the Model or the Harness

A cloud agent, simplified, is three things: the model, the harness around it, and the runtime the harness runs on.

The harness is the loop. It decides which tools the model can call, what goes into context, and when a turn ends. The runtime is the compute it runs on and the boundary around that compute.

The work in the factory is everything around the run. Which agents are allowed to run, who owns them, what context they get before they start, what they can access, and what evidence comes back for someone to approve.

An Example of a Factory

Anthropic published the AI-native SDLC playbook, which is how they build software internally. Work moves through intent, spec, plan, build, test and deploy, with each stage owned by an agent and each stage producing one markdown artifact committed to git. Merging that artifact triggers the next stage, so nothing waits on someone having capacity to pick it up.

We showed how to take that factory to the cloud.

Salary Plus a Token Budget Is the Wrong Prediction

There's a prediction going around that a developer's compensation will soon have two parts: the salary, and the AI budget they're given to spend. I think that's wrong.

It only makes sense if the developer is the one spending it, sitting at the machine while the agent works. Most of that work won't run there in the future. It runs in the factory, on its own, and reaches the developer as a notification: approve this, adjust that, keep going. The person doesn't even start most sessions anymore, so an allowance attached to them no longer makes sense.

What shifts with it is where the developer's time goes. Less of it upstream writing the code, more of it downstream deciding whether what came back should ship, which is harder judgment than it sounds.

So the unit changes. People get salaries. Factories get tokens, because the factory is what the work runs through when nobody's laptop is involved, and a budget attached to a factory can stop a run at dispatch instead of showing up on an invoice.

FAQ

How does the cost of local execution compare to cloud? Local can't be measured the same way. Uber tests each managed agent against its own real work, picks the model that fits that job, and prices the agent by outcome: cost per merged pull request, per review, per alert. An interactive session has no fixed job and no unit of work to divide cost by.

Can a local setup move to cloud later? Yes. Vercel ran its first factory agents through a local CLI to catch friction quickly, then moved onto managed infrastructure once several steps ran reliably. Local for exploring, cloud once it's trusted.

Does Port replace the agent's model or harness? No. Port works with the runtime already running the agent. What Port owns is what happens around the run: which agents are allowed, what context they get, what's checked before they start, and what comes back for approval.

{{from_manual_to_autonomous_engineering}}