Engineering By Hsin, Head of Product 28 July 2026 繁體中文

Scaling coding agents: five agents, five Linux boxes

Everyone uses a coding agent to write code. Almost nobody talks about how to make coding agents scale. For our team the answer turned out to be two things, and neither of them is a better model: a software quality process the agents actually follow, and one isolated Linux box per agent.

Before the number, the caveat: our team averages roughly 100 commits per engineer per day. That is not a KPI, and we would push back on anyone who made it one. It is a side effect of parallelism — five agents committing small changes produce more commits than one person committing large ones, which says something about commit granularity and very little about output. We mention it only because it is the thing people ask about. The interesting part is the machinery underneath.

Why one laptop stops working

A single coding agent on your laptop is fine. The trouble starts at agent number two.

Two agents on one machine share a filesystem, a package manager, a set of listening ports, a language toolchain, and a browser profile. One agent runs npm install and changes what the other one compiles against. One binds port 3000 and the other's dev server dies. One agent's end-to-end test suite drives a browser that steals focus from the machine you are trying to work on. The failures are not dramatic; they are intermittent, which is worse, because you spend your afternoon deciding whether the bug is in the code or in the environment.

And every one of those agents is running commands on the laptop that has your SSH keys on it.

You can paper over this with containers-per-task, tmux discipline, and a lot of care. What you cannot paper over is that the agents are still contending for one machine's worth of state.

Five agents, five boxes

So we stopped sharing. Each agent gets its own Linux box — real root, real filesystem, real networking — and installs whatever it needs into it. The boxes persist between runs, so the toolchain and the caches are still there tomorrow.

Agent roles and what each installs in its own box
Agent	Lives in its box as	Why it can't share
Engineer	CLI toolchain, compilers, language runtimes	Dependency installs mutate what everyone else builds against
QA	Headless browser, E2E harness, seeded fixtures	Needs to simulate many environments, and to reset them destructively
Reviewer	A clean checkout, no build artifacts	A dirty tree makes "does this actually build from scratch?" unanswerable
DevOps	Deploy credentials, infra tooling	Blast radius — this is the one box you do not want an experiment inside
PM	Issue tracker access, docs, no code	Planning shouldn't be able to touch a working tree at all

The rule that falls out of this is simple: nobody contaminates anybody, and nothing blows up your laptop. The engineer agent can wedge its own box's package manager and it costs the QA agent nothing. When a box does get into a state nobody can explain, you delete it and get a new one — which is a very different afternoon from bisecting your own machine.

The other half: a process, written down

Isolation alone gets you five agents making a mess in parallel. The second half is that each role's job is written down as a skill the agent loads — what it is allowed to touch, what it must produce, and what "done" means for that role.

Ours run as a chain: a PM skill scopes work into issues, an engineer skill implements one issue test-first in its own box, a reviewer skill checks the diff against the issue's acceptance criteria, a QA skill exercises the result end-to-end, and a deploy skill ships it. Each stage has an exit criterion, so an agent cannot advance work by declaring victory.

This is the part that keeps PM and engineering out of each other's way. They are not coordinating through a shared workspace and hoping; they are handing each other artifacts — an issue, a PR, a test report — with a boundary in between. The boxes make that boundary physical instead of aspirational.

What "a box" means here

We built the runtime for this and open-sourced it, so the specifics are ours — but the shape is what matters, and you can reproduce it on other tooling.

A real Linux environment, not a function invocation — an LXC container or a Kubernetes pod, with root, a persistent filesystem, and a routable hostname.
Persistent between sessions. Warm caches and an installed toolchain are most of why the second run is fast. Sandboxes that reset every call throw that away.
Reached over SSH, driven over MCP. The agent gets shell and file tools through a Model Context Protocol server inside the box, so any MCP-speaking agent works without a client library.
Holding an SSH key, not cluster credentials. A compromised agent has a shell in one box, not a path to the control plane.
Disposable. Deleting and recreating is cheap enough to be the first debugging step rather than the last.

Disclosure: we build Containarium, which is the runtime described above. It is Apache 2.0 and self-hostable on a single VM, so you can run this topology without us. If you would rather not run infrastructure, there is a hosted version.

What this doesn't fix

It doesn't make the agents better at their jobs. Isolation removes a class of environment failures. It does nothing about a bad plan, and five agents executing a bad plan in parallel produce five times the cleanup.

Review becomes the bottleneck, and it moves to you. Parallel agents generate more diff than one person can read carefully. That is the real constraint this setup runs into, and we do not think it has a tidy answer yet.

Commit count is a bad proxy and will mislead you. Restating the caveat from the top, because it is the number people latch onto: small commits from parallel agents inflate it structurally. Measure shipped, reviewed, working changes.