Cloud Dev Environments Were Never Going to Work for AI Agents

Here is a take the industry does not like: cloud development environments, the tools companies like GitHub, Coder, and Microsoft have spent years building, were never the right foundation for AI agents. The popular argument goes that agents are just a new kind of developer, so the same tools should work for both. This piece argues the opposite. The design choices that make a cloud dev environment great for a human make it actively bad for an agent. Products that try to serve both will lose to products that pick a side.

If you are building a platform for AI agents, treat this as a checklist. How fast does your infrastructure create a new workspace? If it takes more than a few seconds, your agents are waiting instead of working. Can it run hundreds or thousands of sessions at the same time without costs growing in a straight line? Does it give you a clean API as the main interface rather than as an afterthought? Can you replay a session from the same starting point and get the same result every time? If most of those answers are no, you may be building on infrastructure that was designed for a different problem.

What Cloud Dev Environments Were Built to Do

Cloud development environments (CDEs) were designed around one assumption: a human is at the keyboard. That single assumption shaped every part of the product.

The first priority was responsiveness. Developers notice lag. CDEs are built to make everything feel instant: cursor movements, file saves, code suggestions. Delivering that feel requires a long-running container with a warm cache, storage tuned for fast reads, and a session that remembers your state between logins. That is the right call for a human. It is an expensive call for an agent that does not care.

The second priority was keeping your environment alive for a long time. A developer's workspace is meant to last days or weeks. Logs pile up, partial builds accumulate, and terminal history stacks up. The architecture is designed to hold all of that cheaply over a long period. Agents do not need any of it.

The third priority was one person per workspace. CDEs assume a single user, a single set of login credentials, and a single set of editor plugins. Agent workloads need to run hundreds of isolated sessions simultaneously. That assumption breaks immediately at the agent scale.

To be fair, the counter-argument has real weight. Companies like Coder have made a reasonable case that running a single platform for both humans and agents reduces complexity for infrastructure management teams. Microsoft's ongoing investment in GitHub Codespaces signals the same bet at an institutional scale. For teams already paying for these products, the unified argument is currently winning in the marketplace.

What Agents Actually Need

The requirements list for the agent infrastructure differs, and the gap is not small.

Startup speed. An agent fleet running hundreds of sessions simultaneously cannot wait several seconds for each workspace to come online. The only number that matters is the gap between "create a new workspace" and "it is ready to use." CDEs are roughly ten times slower than what serious agent workloads require.

Short sessions, by design. Agents spin up, do their work, and shut down. The infrastructure should be built around that pattern, not around long-lived state preservation. Paying monthly subscription rates for workloads that run for minutes is as much a pricing mismatch as a technical one.

Reproducible results. When you run the same agent task from the same starting point, you should get the same result every time. This matters for testing, regression checks, and debugging. CDEs do not promise that. Their state model is the product of accumulated history, not a clean baseline.

APIs are the primary interface. Agents do not use an IDE. They talk to their environment through code. The main interface should be an API that handles workspace creation, file operations, and event streaming. In most CDEs, the API is a secondary feature added on top of the editor. That order of priorities is backward for agent workloads.

Density. Fifty human developers working at the same time is a good day for a CDE. Five thousand concurrent agent sessions is the baseline expectation for a serious agent platform. The architectural choices that make one of those affordable make the other expensive.

The Two-Audience Problem

Infrastructure history has a recurring pattern. When a product tries to serve two audiences with genuinely different needs, it ends up mediocre for both.

Think about analytics software that tried to serve business users and engineers at the same time. Or email clients that tried to work for personal use and enterprise compliance. Or mobile frameworks that tried to bridge native and web. Each time, the two audiences pulled the product in opposite directions. The compromises needed to satisfy one group created new problems for the other. Eventually, the product that picked one audience clearly won.

CDE vendors are in exactly this position. They have an established base of human developers and the platform teams supporting them. They also want to capture the growth in AI agent infrastructure. Those two goals require different session models, different primary interfaces, and different identity systems. You cannot optimize for all of them at once without making everyone unhappy.

The products that will win in agent infrastructure are the ones that made a deliberate early choice to build for agents first, treating human access as a secondary surface rather than the core design constraint.

How CDE Vendors Could Adapt

This argument does not end with CDE vendors simply losing. It ends with a different shape for the market.

The most logical path for a CDE vendor is to stop competing to be the core platform for agents and become the human-facing layer on top of an agent-native filesystem. The CDE handles what it is actually good at: the editor experience, plugin compatibility, login systems, and long-lived sessions for human developers. The agent-native layer handles workspace state, forking, deduplication, and programmatic access.

Agent-native filesystems that expose standard protocols like WebDAV and FUSE already make this composition possible today. A CDE vendor that wanted to serve agent platforms could mount sessions from an agent-native system through either protocol, present them in their existing editor interface, and stop competing on the parts they were never going to win on.

This would reduce the market status of the CDE. It would not reduce its usefulness. Companies that move toward this model early will be in a better position than those that wait for an acquisition to resolve it.

Where This Argument Could Be Wrong

It could be. The contrarian case is not guaranteed.

CDE vendors have real advantages that agent-infrastructure startups do not. They have enterprise contracts, security certifications, and years of trust built with platform teams. Coder's unified-substrate argument carries genuine commercial weight with buyers who are skeptical of adding new vendors. Microsoft's investment in Codespaces is a serious institutional commitment, not a side experiment. An acquisition could also collapse the whole debate before it plays out in the market. A CDE vendor that buys an agent-native filesystem and ships it as a built-in feature could close the gap faster than any startup could widen it.

The architectural argument is probably right. The market outcome is less certain. If the misalignment between CDE design and agent requirements compounds slowly enough, a larger player may resolve it before it becomes your problem. If it compounds fast, the cost of building on the wrong substrate grows every quarter you wait.