What is GitHub Copilot?

GitHub Copilot is the AI coding assistant built into GitHub, meaning into the platform where a company's code already lives: suggestions in the editor connected to the repository, chat about the code, automated pull request comments, and an agent that, once assigned an issue, opens a pull request with its proposed change on its own. It should not be confused with Microsoft Copilot, the umbrella for the assistants inside Microsoft 365 and Windows: the two products share a commercial name and little else. What really sets it apart from the other assisted-development tools is not technical but organizational. It is switched on as a per-seat license on the GitHub organization a company already has, often inside a Microsoft contract already signed, so the slow part of adoption, procurement and vendor qualification, has usually been done by someone else already. That is why in many companies it is the first, and sometimes the only, tool of this family that reaches production.

What it does

It is an agent harness like the others, with one peculiarity: it has three surfaces rather than one. There is low-latency completion while typing, the surface with the widest penetration; there is conversational interaction about the repository; and there is the agentic layer, which works autonomously on a task and hands back a pull request to review. That last layer puts it on the same ground as Claude Code and Cursor, which start from different places: the first from the terminal, the second from the editor. Copilot starts from the platform, and that shows in where the agent's work enters the process, the pull request, exactly where the team already discusses and approves changes.

What the buyer actually decides

Features and commercial plans change every quarter, the decisions do not. The first is where the code runs: suggestions are generated by remote models, so repository context leaves the company perimeter, and retention and processing terms should be read before the pilot, not after it. The second is training: the business and enterprise offers state that customer code is not used to train the models, while on individual plans interaction data is used for training unless the user opts out, which means a developer using a personal license on a corporate repository is a governance hole rather than a contractual detail. The third is the provenance of what gets generated. The vendor does address it by contract, but on precise conditions: the business and enterprise offers include an intellectual property indemnity that holds only if the filter suppressing suggestions matching public code is on and if the suggestion is used unmodified. Those are two conditions an internal policy has to verify, not assume.

When to choose it, when not to

It makes sense when the work already lives inside GitHub and the expected value is spread across many people rather than concentrated in a few complex tasks: it is the tool you roll out to two hundred developers without an adoption program. It is a less natural choice when a team needs an agent that is extensible and programmable against its own context, where Claude Code or Cursor remain more mature, and when the codebase does not sit on GitHub, because half the advantage evaporates. In every case the evaluation criterion is not how much code it generates, but what review and testing discipline accompanies it.