On this page · 7 min
We build the machines that coding agents run on, so we spend a lot of time watching how people actually work with them.
The same thing comes up every time. Someone has three things to get done, starts an agent on the first one, and then waits. The agent is not slow. There is one computer, and everything has to take its turn on it.
We think that becomes the biggest constraint in software over the next few years. Here is why, and what we built about it.
Agents will write almost all code
99.9% of code will soon be written and maintained by agents.
Everything below follows from that one sentence.
The commits already show it
Developers pushed about a billion commits to GitHub in 2025, a record at the time. By May 2026 the platform was taking in 275 million commits per week, on pace for 14 billion in a year.
More people did arrive. GitHub added 36 million developers in 2025, roughly one every second. That is nowhere near a fourteenfold increase, and the new arrivals work the same way everyone else does now, with an agent open beside the editor.
One computer, three tasks
The obvious answer is worktrees, and on a real stack they do not hold. There is one database. The ports collide. The dev server only comes up in one tree. Put two agents in the same checkout and they write over each other, and then you spend the afternoon working out who did what.
So you run one agent, wait for it, review it, and start the next one. The computer sits idle and you are the bottleneck.
Your laptop was built for one person doing one thing.
The same shape repeats wherever the work outgrows one computer. A product that hands every user an environment. A training run that needs a hundred identical starting states. A team that wants the setup one person got right, twice.
That is a lot of machines
Stop sharing the computer. Give every agent one of its own.
Then count. Millions of developers, several agents each, tens of environments inside a single task, and machines that keep working while their owner sleeps. This is a demand for computers with no precedent, and the machines available today were designed for something else.
What an agent needs from a machine
Nine requirements. Every one of them follows from how an agent actually works, and today's machines miss most of them.
Isolation
An agent runs code that nobody read first.
It needs a real boundary: a kernel of its own, not a namespace on a kernel it shares with strangers.
Speed
One task can spawn tens of environments.
If each takes a minute to appear, the agent spends its life waiting and the whole pattern stops being worth it. Startup has to be measured in milliseconds, so the machine is never the slow part.
Branches
An agent explores. It tries an approach, backs out, tries another, and runs three in parallel to see which one survives.
Booting a fresh machine for each attempt throws away everything the agent already set up. The machine has to fork from where it is now, memory and running processes included, so that a branch starts from the state that took twenty minutes to reach.
A whole computer
An agent has to be able to do anything a developer can do. Install a package, run a database, drive a browser, compile something large.
It should also do the work a developer avoids on a laptop. Millions of simulated writes to prove a migration holds. A full recording of the app under test. Nobody runs that on the machine they use for Slack, and on a machine that exists only for this task there is no reason not to.
Composition
An agent needs the machine to arrive as your machine. The repository checked out, the dependencies installed, the database seeded, the credentials present, the tools and integrations connected, and the application already serving.
Rebuilding that per machine is slow, fragile, and it drifts. So the environment gets composed once and saved whole, and every machine after that starts from the saved state with the services already listening. One prepared computer, stamped out as many times as the work needs.
Memory
Machines go idle, and agents leave them idle constantly.
When one wakes it has to be the same machine, with the same processes, the same memory, and the same open connections. The common workaround today is a script that runs on wake and puts the environment back together, which is an admission that the environment was lost. If the state is gone on wake, the setup happens twice.
Handoff
An agent gets stuck, or does something clever that needs a human decision.
A person has to be able to enter the same machine, mid-task, and pick up the exact state the agent left behind. Not a copy of the branch, the machine itself.
An API
People will not be creating these machines. Software will.
An orchestrator creates a hundred and destroys them an hour later. An agent creates one when it needs help with something. Every operation has to be a call, or a human stays in the loop and the volume never arrives.
Idle
Agents leave far more machines running than people ever would, and asking them to tidy up is the wrong fix.
So waiting has to cost close to nothing. A machine that charges while it does nothing is a machine somebody has to manage, and at a billion machines nobody is managing anything.
The app runs where the agent works
We believe the machine the agent works on should be the machine that serves the result.
The agent edits the software that is already running. You open the URL and the change is there. There is nothing to deploy, because nothing has to move.
This is the part people underestimate. Once the work and the output share an address, reviewing an agent stops being a diff you read and becomes a thing you click.
Who owns the machines
The machine layer should not belong to a model company, and it should not care which agent runs on it.
Code runs somewhere, and whoever owns that somewhere sees it, prices it, and decides which agents are welcome on it. That layer should stay neutral, hosted in a country you picked, on hardware you can own outright.
The tooling moves too fast to bet on. The agent your team runs today is not the one it will run next year, and most teams already run several at once. A machine that takes Claude Code, Codex, an open source harness, or something your team writes next month is a machine you never have to migrate off. A whole computer gives you this for free: any agent that runs on Linux runs here, and no integration is required.
We built them
boxd makes the computers devs and agents work on.
Each one boots in milliseconds, forks from running state in 100 to 200 milliseconds, wakes from idle in under a millisecond with its memory intact, and answers on its own HTTPS URL. Root, a persistent disk, a dedicated kernel, and a bill that goes to almost nothing while it waits. Every operation is available over an API, and the CLI is installed inside every machine, so machines can create machines. Hosted in the EU, and self-hostable as a single binary.
The nine requirements add up to one property. You compose the computer. Pick the tools, the integrations, the data sets and the variables, leave your application running, and save that state as a snapshot. Then create 1, 10, or 100 from it, fork one to branch, roll one back, hand one to a colleague, or leave one serving your users.
Developers get their own. Agents get theirs. Composable computers, for both.
Agents will need billions of machines.
We built them.
