Give Your Agent a Computer

Someone DMed me last weekend asking why I'm so vocal and bullish on cloud agents and whether I had any long-form articles to recommend to better understand the shift in development environments -- why moving to the cloud, i.e. getting rid of local dev, is the way.

I don’t know of any good articles out there apart from Amp’s official articles on using Orbs, so this is my own view of the paradigm shift that is underway and why cloud devving is a much better workflow.

Local development is not suited for agentic workflows

One of the biggest issues with using agents is that they are really powerful (well, a good problem to have) and give you the ability to work on many things concurrently. When you do this in local dev, what happens is:

1. You create multiple checkouts of a repository and call it app-1, app-2, app-3 and so on. This way, you don't have conflicts with package managers etc.
2. You use Git worktrees to manage the different branches and ask your agent to manage them for you.

Doing either of these solves the issue of code conflicts when the features you're developing in parallel start impeding on each other's areas in code. But these approaches isolate only the code. What they do not resolve are things like your dev servers and database instances hogging memory and resources.

What if you wanted to run a preview for a website? Do you feel good spinning up localhost:3000, localhost:3001, ... and so on, and keeping track of which port maps to which checkout? What if you are working on features that touch your backend and the schemas start conflicting because of active development?

The obvious answer to this is that the place in which you (your agent) edit your code has to have its own environment, separated from other features you're working on in parallel. This means:

1. When you start working on a feature, ideally you're already in some special computer spun up just for this feature.
2. That computer has access to start all the required dev servers/databases/other machinery for your app to run properly.
3. These development environments should never conflict with one another.

Where cloud agents come in

I have only used Amp's version of cloud agents called Orbs so far, but they're so good that I don't even bother trying out others.

Cloud agents flip the development process upside down. Instead of navigating to your repo checkout locally and then starting an agent, when you start your new thread, the agent itself is already in the repo checkout in a virtual machine (VM) in the cloud.

This means that by default, your agent has a fresh state of the repository to work from, and you can write scripts that prepare the remote machine for development straightaway after it starts up.

I cannot overstate how revolutionary this feels for development.

What would have taken you time in the past to set up effectively for remote development to feel good, Amp has abstracted away incredibly well in the form of Orbs. With Orbs, you can now spin up as many agents as you want and they will all have their own dev server and services that work separately.

You can talk to your agents running in Orbs from your computer, your iPad, your phone. Anywhere you have a browser running, you can now start development. There's no longer a need to have to ssh manually into VMs, figure out which VM contains which work and maintain unnecessary context overhead in your head.

When you switch between threads, you're switching machines and work under the hood directly. This removes the many little papercuts that arise as a result of working on many features in parallel on a single local machine. The days of having to use worktrees in local dev are over.

How I use Orbs

I typically start new threads off in Orbs, which as described above are cloud agents. Most development goes through these Orbs and occasionally, I run things locally when there are some other things I need e.g. other running processes on my computer that I am too lazy to re-setup in Orbs for now/permissions issues/launching GUI programs on my mac. I think of these runners as escape hatches for when cloud agents are not there yet. I would say it's roughly an 80/20 split between cloud/local usage for me right now.

When using local threads (threads running on my computer), I often just write in the orb thread and tell it to use the local runner for whatever needs to happen locally, meaning I don't usually spin up the local thread myself; I just talk to the thread in the cloud and use it as the orchestrator. This flow is nice because it really blurs the lines between local and cloud dev and makes it feel like almost the same thing.

I also have a few VMs running on exe.dev where I've installed and keep the amp daemon running, that I dispatch threads off to as well.

Cloud agents are the biggest paradigm shift in development tools since Claude Code

It's been hard for me to shift towards newer AI tools because I never liked the form factor and workflows they forced upon you. To put this in perspective, I tried to switch from Neovim to Cursor but never did, because I hate being out of the terminal. So it is a big deal to me that I've not felt the need to use the terminal at all since I started using Orbs.

I regularly just tell the threads in Orbs or in my local runner to do things for me through the Amp web app. I open a tab for each active thread I’m working on in Amp and use that as my multiplexer instead of running agents in different tabs or panes in cmux -- it's just so much better.

Once you shift to Orbs, it's like being free from the shackles of local dev, which sounds like hyperbole, but it really isn't.