Theory
Local agents run inside your editor while you watch. Cloud agents run in remote sandboxes and work on your codebase while you're doing something else. They're designed for a different mode of work: you hand off a task, go focus on something higher-priority, and come back to review a pull request.
How cloud agents work
The typical flow:
- You describe the task and provide context (a GitHub issue, a Slack message, or a direct prompt)
- The agent clones your repo and creates a branch
- It works autonomously: reading code, making changes, running tests, iterating
- When it finishes, it opens a pull request
- You get notified, review the changes, and merge when you're satisfied
The agent never touches your local environment. You review the PR like any other, with the same quality gates you'd apply to code from a human colleague.
What they're good for
Cloud agents work best for tasks that are:
- Well-scoped: clear input, clear output, clear definition of done
- Low-ambiguity: the agent doesn't need to ask clarifying questions mid-task
- Verifiable: there are tests or other signals the agent can use to know when it's done
Good examples: bug fixes with a clear reproduction, adding tests to existing code, refactoring a well-understood module, updating documentation.
Poor examples: designing a new architecture, tasks requiring judgment calls about product behavior, anything where the requirements are genuinely uncertain.
GitHub Copilot coding agent
GitHub's coding agent integrates directly into the GitHub issue and PR workflow. You can assign an issue to Copilot, and it handles implementation from start to PR. It integrates with Slack and Teams so you can delegate directly from a conversation. You can also trigger it from within VS Code or the CLI.
Other cloud agents (Cursor Background Agents, Devin, OpenHands, Jules) follow similar patterns but with different integrations and model choices.
The right mental model
Think of cloud agents like a capable junior engineer you can delegate to: good for well-defined tasks, needs clear requirements, and requires your review before anything ships. Don't treat them as a black box that produces finished features. They're a way to parallelize work and clear a backlog, not a replacement for engineering judgment.
Practice
Run this in a repository you already know, not a toy project. The point is to feel where the practice helps and where it gets in the way on code that has history.
- Pick one item from your backlog that fits the profile of a good cloud agent task: well-scoped, low-ambiguity, verifiable.
- Write the task as a GitHub issue: describe the problem, provide reproduction steps or acceptance criteria, and link any relevant context (files, related issues).
- If you have access to GitHub Copilot's coding agent or another cloud agent, assign the issue to the agent and observe what it produces.
- If you don't have access yet, do this as a simulation: take the same issue description and run it as a local agent task. Note what clarifications the agent needs that you didn't include in the issue.
- Review the output as if it were a PR from a colleague. What would you comment on? What would you approve?