Automation: the cloud coding agent

This chapter is about a Copilot surface that does not run in your editor at all: the cloud coding agent. It works on GitHub, asynchronously, while you do something else, and it hands its work back as a pull request.

The work that fits this surface is the backlog kind: short follow-up issues on your own app (orders-service, the course’s illustrative order-management API your squad owns) - a validation edge case, a small report endpoint product asked for. None of it is hard, none of it is risky, and all of it is well enough scoped to write a sentence about. That combination - low stakes, clear boundaries, your own app - is the profile where you give Copilot the longest leash this course gives: work proceeds without you driving it.

The same Copilot, a different surface

Copilot is one assistant wearing several surfaces; the cloud coding agent is the one that runs outside your editor. It reads supported repository instructions and skills, so the rules and skills travel with the work. What does not automatically travel is anything local: an IDE setting or a local MCP server (a tool connection configured on your machine) does not carry over, and organization policy still matters.

That changes the rhythm completely. In the IDE you and Copilot share a keyboard; the loop is tight and synchronous. On GitHub the loop is async: you describe a task, walk away, and come back to a finished proposal. The judgment from the modes chapter - match autonomy to stakes - is exactly what tells you this backlog is safe to run that way. Cheap to fix, easy to undo, no downstream consumers.

What this chapter covers

Clearing the backlog by handing each issue to the cloud agent and reviewing what comes back:

• Assign · hand an issue to Copilot - the places you can kick off async work, and how to write an issue that stands on its own.
• Pull requests · it proposes, you merge - the pull request it opens on its own branch, and iterating on it without leaving GitHub.
• Environment · copilot-setup-steps.yml - the one config file that shapes how it runs, and who is allowed to turn it on.

By the end the follow-up backlog is clear, and you have seen the proposes-you-decide loop stretched to its async limit - the agent working on its own, you reviewing on your schedule.