The last year of localhost

Background agents humming across a software assembly line can't run on a laptop. What's blocking your team is the thing that's been broken all along: your development environment. @stevekaliski wrote about @stripe's Minions merge over a thousand agent-authored pull requests per week. @rahulgs wrote about how @RampLabs' background agent accounts for 57% of all merged PRs. Last week, Ona authored 88.5% of the PRs we merged on main. What these teams share isn't a special agent harness or a smarter model. They standardized their development environments years ago. Stripe had cloud-based devboxes before GPT-3 existed. Those investments predated the agent era by years, and now they're paying compound returns. The end of localhost We started Gitpod (now Ona) five years ago to move software development to the cloud. To do for dev what Figma did for design. We set out to solve the 'works on my machine' problem: dev environments drift out of sync with production, with CI, with each other. Every team has slightly different setups. Onboarding takes days, sometimes months. Debugging local environment issues is a full-time job for some platform engineers. We believed the answer was cloud development environments, and we said it over and over. Between 2020–2022 it felt like we were right. @swyx agreed, Hacker News didn't. Then it felt like we were too early. @redmonk's "year of the cloud development environment" was becoming the new "year of the Linux desktop": always right in theory, never in practice. Cloud development environments solve real problems: environment drift, onboarding time, reproducibility. But for most developers, local setups were good enough. Apple's M1 closed the performance gap, and the pull of "just use my laptop" was strong: zero latency, years of customization, a workflow that felt like identity. The case for CDEs was real, but never urgent enough to force a move. As with so many things, AI changed that. Fleets of agents humming across a software assembly line don't fit on a laptop. Each agent needs its own isolated, fully provisioned environment with access to internal services and production-grade toolchains. Development is finally moving to the cloud, for a reason nobody originally expected. This time for real: with four years of delay, localhost is going to end. Cloud development environments are a prerequisite for agents Look at the companies leading the background agent wave and trace their dev infrastructure history. Stripe built its remote development environment years ago. As Soam Vasani described, every Stripe engineer gets an EC2 devbox with a Sorbet server, full monorepo checkout, and rsync from their laptop. Standardized, reproducible, managed centrally. When Stripe built Minions, their one-shot coding agent, they didn't need to figure out where the agent runs. The answer already existed: the same environment every engineer uses. Same dependencies, same test suite, same credentials and network access. That's how they went from prototype to thousands of merged PRs per week in months. The agent infrastructure was a thin layer on top of years of environment investment. Ramp followed a similar path, building their own background agent on standardized environments and running it across their codebase. Same pattern: environment standardization first, agents on top. The inverse is equally telling. We talk to teams that have already wired agents to their issue trackers, automatically assigning tickets and generating code. The agent can read the codebase, maybe even compile it. But it can't run the application, execute tests against real services, or validate its own work. It produces code that looks right but hasn't been tested. The gap between "generates a diff" and "opens a merge-ready PR" is the development environment. The companies moving fastest on agents already have a standardized, reproducible environment layer. Everyone else is discovering they need to build one first. Done right, this is a major infrastructure project before you even deploy your first agent at scale, let alone manage day-two operations. Why git worktrees break and localhost can't do what agents need If you're a developer productivity engineer at a company with a monorepo, tasked by your frenetic CEO to get to the same % of PRs merged by background agents as Ramp, you've probably started with git worktrees. You want to run three agents in parallel, so you create three git worktrees. Each worktree gets its own branch, its own checkout, its own agent. In a monorepo, this breaks immediately. Each worktree needs its own dependency install, its own running services, its own database instance. The filesystem is shared but the runtime state is not. You end up with port conflicts, shared caches corrupting each other, and a machine that grinds to a halt. We hear this constantly from teams: three worktrees running simultaneously and the laptop becomes unusable. The problem is amplified by what monorepo environment setup looks