How we stopped working for our agents - Islo<br>Like most teams in early 2026, we started with agents on our own machines. Each of us had Claude Code or Cursor open all day. You’d paste a Linear ticket, ask the agent to implement it, review its output in the same session, manually run the app to check nothing was broken, then push and open a PR. The agent was a local tool, like a compiler, and it ran when you told it to, on your laptop, in your terminal.

This worked well enough that we started leaning on it for everything: implementation obviously, but also “review this PR for me,” “check if this change breaks the CLI,” “write the migration and verify it runs.” The agents were plenty capable, but we were still the glue between them. Every task required a human to start it, watch it, and decide what to do with the result. We were working for our agents as much as they were working for us.

The first thing we tried to move off our laptops was implementation, which in hindsight was the naive choice. We deployed an agent that could take a Linear ticket end to end: boot a sandbox, read the issue, explore the codebase, write code, run tests, open a PR. The initial thing was impressive enough that we immediately started talking about what to automate next, but we hadn’t paused to notice what happened after the PR was opened.

What happened was that we reviewed it carefully and we noticed that the reviews were taking longer than they used to. Agent-generated code looks plausible at a glance, but the design decisions are often wrong in ways that take real effort to catch. An agent will pick an approach, hit a wall, and then spend twenty tool calls forcing it to work instead of stepping back and choosing a different design. The result is code that passes tests but is built on a bad idea, and reviewing that is harder than reviewing a bug, because you have to understand the alternative the agent didn’t consider. We were spending more time reviewing and manually verifying agent output than we had spent writing the code ourselves. The bottleneck hadn’t disappeared; it moved from writing to verification. Time spent reviewing bad code went up, engineers’ happiness went down.

We went back to square one and asked a question that felt counterintuitive at the time: what if implementation is the wrong first thing to automate?

It’s all about the right environment

We looked at off-the-shelf review tools first. A PR opens, an agent reads the diff, posts comments. But these are glorified diff checkers. They see the changed lines and nothing else. They’ll catch style nits and obvious single-file bugs, but they’ll never say “this is going to break the CLI” because they have no context beyond the diff.

Consider a PR that changes the timeout field on sandbox creation from seconds to milliseconds, for consistency with another internal API. The backend code is updated, tests pass, the diff looks correct. But the CLI sends --timeout 30 meaning 30 seconds, which is now 30 milliseconds. The frontend sends timeout: 300 meaning 5 minutes, which becomes 300 milliseconds. Nothing crashes. Sandboxes just time out almost instantly and users get cryptic errors. The bug is a silent semantic shift across three repos, and no test in any of them catches it. A diff-based reviewer sees a clean backend change and moves on.

We were already using agents to review PRs on our own machines, and they didn’t work like that at all. Given a proper workspace, the agent ran grep -r to find callers of the changed function, checked out related PRs in other repos, read the API docs, opened the SDK source to verify the contract still held. It was doing exactly what a good human reviewer does, except faster and more systematically, as long as it had access to the right files. The workflow was great. It was just manual, and it only ran when someone remembered to kick it off.

So we needed to give the reviewer the same kind of environment it had on our laptops, but running on its own. Coding agents behave like developers, not like CI jobs: they install packages, start databases, modify system config, leave files around. Two agents on the same machine step on each other the same way two developers sharing a single laptop would. So each agent gets its own sandbox: an isolated machine with its own filesystem, its own processes, full root access, and no way to interfere with anything else running in the system.

The next problem is that provisioning a machine from scratch (installing dependencies, cloning repos, compiling Rust binaries, running database migrations) adds up to 20-30 minutes before the agent can do anything useful. So instead of setting up every time, we use snapshots to freeze a fully prepared sandbox’s disk state and restore it in seconds when a job starts. We maintain a code snapshot called islo-code with all repos cloned, dependencies installed, and toolchains ready, rebuilt on a schedule by CI so it stays current with main. The reviewer boots into a...