A bug report usually sits in a tracker for days before anyone opens the file it belongs to. The fix itself, once someone sits down to write it, is often the shortest chapter of the whole story. What eats the calendar is everything around the fix: cutting a branch, writing a message that explains why the change exists, pushing it, opening a pull request, describing the diff well enough that a reviewer does not have to reverse-engineer your intent, waiting, then working through the comments and pushing again. None of those steps is hard. Stacked up, they slice a working day into fragments too small to think in.

That fragmented middle is exactly where the coding agent in GitHub Copilot is aimed. The official framing is worth taking literally, because it sets expectations in the right place: this is not the chat box in the editor waiting for your next question, it is a role that picks up a task and carries it to the end on its own, in the background, while you get on with something else.

Hand over an issue, get a pull request back

The mechanics are plain. Assign an issue to Copilot, or start a task from the agent panel on any page. It begins with the issue title, the body and whatever comments already exist, explores the repository inside a temporary development environment of its own, works out a plan, makes the edits, and opens a pull request. When it finishes it adds you as a reviewer and fires a notification, so the handoff lands somewhere you will actually see it.

That environment is driven by continuous integration, which means the project's tests and linters can run before you ever look at the result, and the workspace can be prepared first using the setup steps the repository already spells out. If a test only passes with a database and a couple of background services alive, that preparation is not left to guesswork.

One detail trips people up when the requirements shift. Comments added to the issue after the assignment are not picked up. Follow-up requests belong in the pull request it opened. Leave a note there and it starts a fresh session to handle it, and because the context from earlier sessions on the same pull request is kept, the second request usually lands faster and with fewer misreadings than the first. The same channel works when a continuous integration run fails: hand it the failure and it investigates, then pushes the repair.

Reviewing its own work before anyone else sees it

The tiring part of reviewing machine-written changes is not that they are obviously broken. It is that they look like they run, while no person on the team would have written them that way. The official setup answers this by having the coding agent review its own patch with the code review capability before the pull request opens, then iterate on the feedback it receives. By the time you are added as a reviewer, one pass has already happened.

The same workflow runs code scanning, secret scanning and dependency vulnerability checks. A dependency with a known issue, or a string in the diff that looks like a credential someone committed by accident, gets flagged before the pull request becomes visible rather than after a reviewer stumbles across it.

Putting the team's habits into a config file

A short prompt leaves a lot of room for judgement on the spot, and judgement on the spot does not always match how the team actually works. Custom agents exist to pin that part down. Add a configuration file to the repository and you can specify the order in which a class of task should be done. A performance agent, for instance, can measure first, change the code second, measure again to prove the change did something, and only then open the pull request. The same configuration can be shared across an organisation, so separate teams end up following one process instead of several private ones.

On the desktop, sessions sit side by side

Once several tasks are in flight, the difficulty moves to keeping them apart. The desktop app can start work from an issue, a pull request, a single sentence or a previous session, and it can run several agent sessions in parallel. Each session gets its own working tree and branch, so files, conversation and task state stay isolated instead of bleeding into one another. Builds are available for Windows, macOS and Linux; changes can be checked in the integrated terminal and in a browser; and the pull requests it opens still go through whatever review, checks and merge rules the team already enforces.

Coding agent takes a task in the background and walks it through branch, commit and pull request without being steered step by step.

Self-review before delivery iterates with code review first, then runs the code, secret and dependency scans.

Parallel sessions give each desktop session its own working tree and branch, so they never edit the same files at once.

How the pricing works

Individual plans moved to usage-based billing in June 2026, and the line runs from a free tier through Pro, Pro+ and Max. The free tier includes a limited allowance for completions plus a limited amount of chat and agent usage, and it still carries the command line tool and agent mode, so trying it out costs nothing up front. On paid tiers the base allowance maps directly to the subscription price, with a flexible allowance on top that moves with cost; completions and next-edit suggestions are unlimited there and do not draw on the allowance at all. For the exact tiers and figures, the official pricing page is the only source worth trusting.

Writing the code is half the job. The other half is getting the change through review, checks and merge, and this setup takes that half too, which leaves people to show up only where judgement is genuinely required.