What Are Cloud Coding Agents? Async PR Bots Explained

// In plain English

A normal AI coding assistant lives inside your editor. You type a request, watch it edit files on your own machine, approve each step, and steer it when it drifts. It's a pair programmer sitting at your keyboard — you're both looking at the same screen the whole time.

A cloud coding agent (also called an async or background agent) works the opposite way. You hand it a task in plain words — "add pagination to the users API and update the tests" — and it goes off to a fresh remote machine, clones your repository, does the work on its own, and comes back later with a finished pull request for you to review. You don't babysit it. You delegate, walk away, and check the result when it's ready.

Think of the difference between a colleague who pulls up a chair next to you (synchronous — you work together, in real time) and a colleague you assign a ticket to on a Friday (asynchronous — they go away, do it, and the work shows up as a PR on Monday). Local agents are the chair-puller. Cloud agents are the ticket-taker. Same underlying model intelligence, completely different working relationship.

// Why it matters

Local AI coding assistants are powerful, but they hold one of your hands hostage: while the agent is thinking and editing, you're watching it. For a quick fix that's fine. For a stack of routine chores it's a bottleneck — you can only run one conversation at a time, and your attention is the rate limit.

Cloud coding agents break that bottleneck. Because each task runs on its own remote machine, you can fire off several at once and let them work in parallel while you do something else entirely. The payoff is real for a specific kind of work:

• Parallelism. Kick off five independent tasks before lunch — bump a dependency, fix a flaky test, add a small endpoint, write missing docstrings, migrate a config — and review five PRs after. None of them needed your attention while they ran.
• Hands-off delegation. The well-scoped, boring-but-necessary tasks that you keep postponing are exactly what an async agent is good at. You describe the outcome, not the steps.
• Clean, reproducible environments. Every task starts in a fresh sandbox built from your repo and a setup script. No "works on my machine" drift, no half-applied edits polluting your working tree, no risk to your local files.
• A reviewable artifact. The output is a normal pull request — a diff, a description, passing or failing CI — that drops straight into the review workflow your team already uses. Nothing new to learn on the receiving end.

Who should care? Anyone with a backlog of small, independent tasks; teams that already live in a pull-request review culture; and developers who want to multiply throughput on routine work without multiplying the number of editors they're staring at. If your day is mostly deep, exploratory work on one hard problem, a local agent you steer closely is still the better tool — async shines on the known and the parallel, not the uncertain.

// How it works

Under the hood a cloud coding agent runs the same agent loop a local one does — read the task, plan, edit files, run commands, observe the result, repeat — but it does the whole loop on a remote machine with no human in the seat. The lifecycle has five stages, and understanding them is the key to using these agents well.

Provisioning the sandbox

When you submit a task, the platform spins up an isolated virtual machine, clones your repository into it, and runs a setup step to install dependencies and get the project into a runnable state. This is the part people underestimate: if the agent can't install your packages, start your database, or run your tests, it's working half-blind. Most platforms let you pin this with a config or setup script — and a repo guide file like an AGENTS.md or CLAUDE.md tells the agent how your project is built, tested, and structured. Good setup is what separates a reliable async agent from a flaky one.

Working without you

Inside the sandbox the agent edits files, runs your build, executes the test suite, reads the failures, and fixes its own mistakes — looping until it believes the task is done or it gets stuck. Because no human is approving each step, it leans on whatever signals it can check itself: a passing test, a clean type-check, a successful build. The richer those signals, the better the result. An agent with a real test suite to grade itself against produces far better diffs than one editing in the dark.

Handing back a pull request

When it finishes, the agent pushes its work to a branch and opens a pull request: the diff, a written summary of what it changed and why, and the CI status. From here it's an ordinary code review. You read the diff, leave comments, and either merge it or send it back — and many platforms let you reply on the PR to trigger another async round that addresses your feedback.

// Cloud agents vs local agents

These two modes aren't rivals — most serious developers use both, picking the one that fits the task. The trade is control versus throughput. A local agent gives you tight, mid-task steering; a cloud agent gives you parallelism and hands-off delegation. Here's how they line up.

Tools like Claude Code, Cursor, GitHub Copilot, OpenAI Codex, and Gemini CLI increasingly offer both a local, interactive mode and a cloud, background mode. The line between "editor assistant" and "async agent" is blurring into a single product with two gears — you shift between them based on whether you need to steer or just delegate.

// Good async tasks vs bad async tasks

The single biggest predictor of success with a cloud agent is task selection. Because you can't steer mid-flight, the task has to be one the agent can finish — and verify — on its own. A simple heuristic: a good async task is well-scoped, verifiable, and self-contained. If any of those three is missing, do it locally where you can intervene.

Concrete examples of good async tasks: bump a dependency and fix the breakages, add a small CRUD endpoint with tests, increase test coverage on one module, fix a specific reported bug with a reproduction, migrate a deprecated API call across files, or write missing documentation. Each has a finish line the agent can recognize.

Examples of bad async tasks: "redesign the auth system," "figure out why the app feels slow," or "make the UI nicer." These need judgment, exploration, and back-and-forth — exactly the steering an async agent can't take mid-task. Run those locally, or use the async agent only after you've made the hard decisions and the remaining work is mechanical.

// Common pitfalls

Async agents fail in different ways than local ones, precisely because nobody is watching. Most problems trace back to one of these:

• Broken environment setup. If the sandbox can't install dependencies or run tests, the agent works blind and its diff is a guess. Invest in a reliable setup script and a repo guide file before you scale up — this is the number-one cause of bad async results.
• Vague task descriptions. Because you can't course-correct, the task description is your only steering. "Fix the login bug" is a coin flip; "users with expired sessions get a 500 instead of a redirect to /login — fix the handler and add a test" is a task the agent can actually finish.
• Rubber-stamping the diff. The whole point is that you didn't watch the code get written — so you must read it before merging. An agent can produce a confident, green-CI PR that quietly does the wrong thing. Review like you would a new hire's first PR.
• No way to verify. An agent with no tests to grade itself against has no feedback loop. On repos with weak test coverage, async results are noticeably worse — the agent literally can't tell if it succeeded.
• Over-parallelizing dependent work. Two async tasks that touch the same files produce conflicting branches. Keep parallel tasks independent, or you'll spend the time you saved untangling merge conflicts.

// Going deeper

Once the basic delegate-and-review loop feels natural, a few deeper themes shape how well async agents work in practice.

Verification is the real bottleneck — and it shifts to you. An async agent is only as trustworthy as the signals it can check itself against and the rigor of your review afterward. As you delegate more, your own time moves out of writing code and into reviewing it. Teams that win with async agents are usually the ones that already had strong tests, CI, and a healthy code-review habit; the agent amplifies that culture rather than replacing it.

Iterating on a PR. The first async result is rarely the last word. Most platforms let you comment on the pull request — "good, but also handle the empty-list case" — and trigger another async round that builds on the existing branch. This turns a one-shot delegation into a slow, asynchronous conversation conducted entirely through the PR, which is a different rhythm from the live back-and-forth of a local agent.

The sandbox is a security boundary, not just convenience. Running on an isolated remote machine means a misbehaving or prompt-injected agent can't touch your laptop, your local credentials, or unrelated repos. But it raises new questions: what secrets does the sandbox get, what can it reach on the network, and who can read its logs? Scope its access to exactly what the task needs and no more — an agent that can run arbitrary commands is a powerful thing to point at production credentials.

Where this is heading. The same model can run interactively or in the background, and the industry is converging on products that do both — a single agent you steer for hard problems and delegate to for routine ones. The skill that's becoming valuable isn't writing every line yourself; it's knowing which mode a task belongs in, scoping work so an agent can finish it, and reviewing the result well. Start small: pick one boring, well-tested chore, delegate it, and review the PR critically. That single loop teaches more than any amount of reading.