GitHub Copilot: The Complete Guide

Most developers meet GitHub Copilot as an autocomplete that finishes the line they were already typing. That is the smallest thing it does, and treating it as the whole product is why so many teams conclude that AI assistance is a marginal convenience.

Copilot is now a set of distinct tools that happen to share a subscription: inline suggestions in your editor, a chat interface with access to your codebase, an agent that edits multiple files while you supervise it, a separate agent that runs on GitHub’s infrastructure and opens pull requests, a terminal agent, and a review system that comments on diffs. These behave differently, fail differently, and suit different work. Knowing which one to reach for is most of the skill.

This guide maps the whole surface area. It is the pillar of Cluster 1 — GitHub Copilot Fundamentals, and every section links to the lesson that covers that topic properly.

What GitHub Copilot actually is

GitHub describes Copilot as “an AI coding assistant that helps you write code faster and with less effort.” That is accurate but unhelpfully broad, because it flattens six quite different tools into one sentence.

A more useful framing is to think of Copilot as four layers, ordered by how much autonomy you hand over:

Nearly every complaint about Copilot resolves to using the wrong layer. Asking inline suggestions to architect a module produces plausible nonsense. Handing a subtle concurrency bug to the cloud agent wastes a round trip. The layers are not a quality ladder where higher is better — they are different tools.

What Is GitHub Copilot and How Does It Work? covers the underlying model in more depth, including how context is assembled and where the abstraction leaks.

Who it is for

Copilot is aimed at people who already write software. That sounds obvious, but it has a practical consequence: the product assumes you can tell correct code from convincing code. Every layer above delivers output that looks finished. Only some of it is.

That makes Copilot most valuable to:

• Working developers doing routine implementation, test writing, and refactoring — where the shape of the answer is known and typing it is the cost.
• DevOps, platform and cloud engineers dealing with configuration languages whose syntax is tedious and whose semantics are unforgiving.
• Engineers working in unfamiliar codebases, where chat’s ability to explain existing code is worth more than its ability to write new code.
• Technical leads and engineering managers who need to evaluate what to adopt, what to restrict, and what it will cost.

It is least valuable — and most dangerous — to someone who cannot yet review what it produces. Copilot will happily write code that runs, passes a naive test, and is wrong in a way that only surfaces under load six months later.

How it works, conceptually

Copilot sends context to a large language model and turns the response into suggestions, chat messages or file edits. The interesting part is context: what gets sent, and what does not.

Depending on the surface, context can include the file you are editing, other open files, the surrounding project structure, a repository index, files you explicitly attach, your custom instructions, and the conversation so far. The model sees a snapshot assembled at that moment — not your whole repository, and not your runtime behaviour.

Three consequences follow, and they explain most day-to-day behaviour:

1. Copilot cannot know what it was not shown. If a convention lives in a file that is closed and unindexed, expect suggestions that violate it.
2. Copilot has no execution feedback unless a tool provides it. Inline suggestions never run your code. Agent mode can, if you let it run your test command — which is precisely why agent mode catches errors that autocomplete cannot.
3. Output is probabilistic. The same prompt will not reproduce the same result. Any tutorial that shows you “what Copilot said” is showing you one sample, not a specification.

Why context is the lever

If you take one operational idea from this guide, take this: you have far more control over Copilot’s output through context than through phrasing.

Prompt-engineering advice tends to focus on how you word a request. That matters at the margins. What matters more is whether the model can see the type definition, the existing implementation of the same pattern elsewhere in the repository, the test that describes expected behaviour, and the convention your team settled on two years ago.

A concrete example. Two developers ask for the same thing in the same words:

• Developer A has one file open, no repository custom instructions, and the relevant interface defined three directories away in a file that has never been opened this session.
• Developer B has the interface file open, a repository instructions file naming the language version and test framework, and the neighbouring module that already implements this pattern visible in the workspace.

They will get materially different answers, and neither of them typed a better prompt. This is why the highest-return configuration in the entire product is a repository custom instructions file — a one-time cost that improves every subsequent interaction for the whole team.

It is also why “Copilot does not understand our codebase” is usually a solvable complaint rather than a verdict.

Code completion

Inline suggestions are the layer most people know: ghost text appears ahead of your cursor, Tab accepts it, Esc dismisses it.

What is worth knowing is that completion quality is largely a function of what you have already written. A descriptive function signature, a docstring stating the contract, and nearby type definitions do more for suggestion quality than any prompt phrasing, because they are the context.

Next edit suggestions are a separate feature: rather than only completing at the cursor, Copilot predicts where your next edit is likely to be needed. If you rename a parameter, it will often propose the corresponding changes further down the file. It is supported in VS Code and Visual Studio, and in public preview in JetBrains, Eclipse and Xcode.

The failure mode specific to this layer is subtle. Completions are accepted with a single keystroke, dozens of times an hour, which makes them the layer where unreviewed code most easily accumulates. A suggestion that is 90% right and 10% wrong is more dangerous than one that is obviously broken, because the obviously broken one gets deleted immediately.

Two habits address this. First, read the suggestion before pressing Tab rather than after — accepting and then evaluating is a different cognitive act, and a worse one. Second, be suspicious of long multi-line completions in particular: the longer the suggestion, the more decisions it made on your behalf without stating them.

GitHub Copilot Code Completion Explained covers accepting partial suggestions, cycling alternatives, and the review habits that keep completion from quietly degrading a codebase.

Copilot Chat

Chat is where Copilot becomes useful for work that is not typing. It is available in supported IDEs, on GitHub.com, in GitHub Mobile, and in Windows Terminal.

The three jobs it does best are, in order:

1. Explaining code you did not write. This is the most undervalued use. Point it at an unfamiliar function and ask what it does, what it assumes, and what breaks it.
2. Generating code with a stated contract. Not “write a function to handle users”, but a specific signature, specific error behaviour, and specific tests.
3. Reviewing your own work before anyone else does. Asking “what edge cases does this miss” is cheap and frequently productive.

Chat supports slash commands for common operations, chat variables (#file, #selection, #project) that pull specific context into a prompt, and chat participants (@github, @terminal, @vscode) that scope a question to a domain. The exact set differs by IDE — VS Code has the widest support.

Chat has one important advantage over completion that is easy to miss: it lets you state constraints. Inline suggestions infer what you want from what you have typed. Chat lets you say “do not change the public signature”, “use the standard library only”, or “this must remain O(n)” — and those constraints actually shape the result.

The corresponding discipline is to keep sessions focused. A long chat thread that has wandered across four topics carries all four into every subsequent answer, and the earliest detail starts dropping out as the context window fills. Starting a fresh conversation for a new problem is not wasteful; it is how you stop the model reasoning from stale premises.

GitHub Copilot Chat: Complete Beginner’s Guide is the full tutorial, with a working library of prompts for debugging, refactoring, testing, Git, shell and DevOps work.

Agent mode

Agent mode is the point where Copilot stops proposing and starts doing. In supported IDEs, it takes a goal, decides which files are relevant, makes edits across multiple files, runs tools, and iterates on the result — pausing for your approval as it goes, particularly before running terminal commands.

The mental model that works: agent mode is a capable engineer who has just joined your team, has read your repository, and has no idea which parts of it are load-bearing. It is fast, literal, and needs supervision.

It is well suited to:

• Mechanical refactors that span many files
• Adding a feature that follows an existing pattern in the codebase
• Writing a test suite for existing code
• Fixing a failing test where the failure is legible from the output

It is badly suited to:

• Anything where the requirements are still being decided
• Subtle correctness work — concurrency, numerical precision, security boundaries
• Changes in code you do not understand well enough to review

The variable that most determines whether an agent-mode session goes well is not the model — it is how precisely the task was scoped. “Improve the error handling in this service” produces sprawl: the agent touches files you did not expect, makes defensible-but-unwanted choices, and hands you a diff too large to review carefully. “Replace the bare except: blocks in payments/ with specific exception types, preserving existing log messages” produces a diff you can actually read.

The rule of thumb: if you cannot describe what the finished diff should contain, the task is not ready for an agent. That is not a limitation of the tool so much as a reminder that delegation requires a specification, whether the delegate is a model or a person.

Agent mode is supported in VS Code, Visual Studio, JetBrains IDEs, Eclipse and Xcode, and is included on every plan, including Copilot Free.

GitHub Copilot Agent Mode Explained covers the approval model, permissions, and a worked example of scoping a task properly.

The cloud agent

The Copilot cloud agent is a different thing that is easy to confuse with agent mode, largely because it used to be called the coding agent.

The cloud agent runs in its own ephemeral development environment powered by GitHub Actions — not on your machine. You assign it work from GitHub.com, from an issue, from VS Code, or by mentioning @copilot on a pull request. It researches the repository, plans, implements, and opens exactly one pull request per task for you to review.

The practical differences:

The cloud agent has a hard session limit of 59 minutes, cannot work across multiple repositories in one task, and only works with repositories hosted on GitHub. It is available on all paid plans, and on the free Student plan, but not on Copilot Free. On Business and Enterprise, an administrator must enable it first.

GitHub Copilot Cloud Agent vs Agent Mode resolves the terminology properly and gives you a decision table for choosing between them.

IDE support

Copilot’s feature set is not uniform across editors. VS Code consistently gets features first; other editors follow at varying speed.

The practical reading: if you are evaluating Copilot’s agentic features and you work in Neovim, you are evaluating a completion tool. If you work in VS Code, you are seeing the product as intended.

How to Install GitHub Copilot covers setup for each supported environment, plus authentication and troubleshooting.

Copilot CLI

Copilot CLI brings an agent to the terminal. It is a genuine agent, not a command-suggestion tool: it reads and edits files, runs commands under a permission model, manages sessions, and can create pull requests.

# Install with npm (requires Node.js 22 or later)
npm install -g @github/copilot

# Authenticate
copilot login

# Start an interactive session
copilot

Inside a session, slash commands drive most functionality — /plan to draft an implementation plan before coding, /review to run the code review agent, /model to switch models, /permissions to change how much it can do without asking, and /undo to roll a session back. It is included on every plan, including Copilot Free.

Copilot CLI gets a full cluster later in the Academy. For now, 50 GitHub Copilot Commands, Actions, and Developer Workflows covers the commands worth knowing on day one.

Models

Copilot is not a single model. You choose which model handles a request, or let auto model selection choose for you.

The practical advice is less exciting than the model discourse suggests: for most everyday coding, the default is fine. Reach for a heavier reasoning model when a task genuinely requires holding many constraints at once, and a faster model when you are doing something mechanical and want throughput. Model choice consumes AI credits at different rates, so it is also a cost decision.

Custom instructions and prompting

The highest-leverage configuration in Copilot is the least glamorous: telling it your conventions once, rather than restating them in every prompt.

Custom instructions are persistent instructions prepended to Copilot’s context. They work at repository scope (checked into the repo, so the whole team gets them), at personal scope, and — on Business and Enterprise — at organisation scope. A good repository instructions file states the language version, the test framework, the error-handling convention, and anything a new engineer would get wrong on their first day.

Prompt files are reusable Markdown prompt templates stored in the workspace and invoked by name, for tasks you repeat.

Agent skills are folders of instructions and supporting resources that teach an agent to perform a specific task well.

On prompting itself, the single most useful principle is that specificity beats politeness. Compare:

The second is not longer for its own sake. It names the framework, the shape of the response, the validation library, the error behaviour, and the test expectation — five decisions that the first prompt leaves to chance.

GitHub Copilot Best Practices for Beginners develops this properly, with the reasoning behind each principle.

Code review

Copilot code review produces AI-generated review comments on a diff. It runs on GitHub.com and in supported IDEs, and it is included on every plan — though on Copilot Free it is limited to “Review selection” in VS Code.

It is genuinely useful as a first pass, in the same way a linter is: it catches the obvious things cheaply, so human reviewers spend their attention on design and correctness. It is not a substitute for human review, and treating it as one is a good way to merge something confidently wrong.

The most productive habit is to run it on your own pull request before requesting review, so the noise is removed before a colleague looks.

Two things to calibrate. It is good at local, mechanical observations — an unhandled error path, an off-by-one, an inconsistent null check — and weak at the questions human review exists for: is this the right abstraction, does it belong in this service, will it be maintainable by whoever inherits it. And because it comments on the diff rather than the system, it cannot tell you that a change is correct in isolation but wrong given something happening elsewhere.

Used as a first pass it saves reviewer attention. Used as the review, it launders unreviewed code through a process that looks like review.

Agents and MCP

Model Context Protocol (MCP) is how Copilot reaches tools and data it does not have built in — an issue tracker, a database, a documentation system, an internal service. You configure MCP servers, and their tools become available to Copilot. MCP is included on every plan.

Alongside it sit custom agents (named configurations with their own instructions, tools and MCP servers) and third-party coding agents (external agents running under the same protections as the cloud agent, currently in public preview and excluded from Free and Student).

This is Cluster 7 territory, and it is genuinely advanced. It is listed here so you know the ceiling exists, not because you should configure MCP servers in week one.

What changed recently

Copilot’s shape has moved enough in recent releases that older tutorials are actively misleading. If you last looked at the product a year ago, these are the changes that invalidate what you knew:

• The coding agent is now the cloud agent. Same feature, new name. Articles using the old term are not wrong about behaviour, but the UI will not match.
• Billing is usage-based, denominated in AI credits. The earlier “premium requests” framing is gone. Paid individual plans now split included usage into fixed base credits plus a variable flex allotment.
• Copilot Max exists. A $100 USD per month individual tier above Pro+, aimed at sustained high-volume agent use.
• Copilot Student is a distinct plan, not merely a discount, and it includes the cloud agent that Copilot Free does not.
• The agent surface expanded to include custom agents, agent skills, third-party coding agents, and a desktop GitHub Copilot app for managing agent sessions.

Plans

Every plan includes a monthly allowance of GitHub AI Credits. For paid individual plans that allowance comes in two parts: base credits, matched 1:1 with your subscription price and fixed, and a flex allotment, a variable amount on top that GitHub can adjust as model economics change. Base credits are spent first. Credits do not carry over between months.

The short version of the decision:

• If you are a student, verify your status — Student is free and includes the cloud agent.
• If you are an individual developer, Pro is the sensible default.
• If you routinely hand agents multi-file work, Pro+ buys premium models and more credits.
• If you need governance — organisation instructions, content exclusion, policy management, audit logs — you need Business or Enterprise, not a bigger individual plan.

GitHub Copilot Plans Comparison has the full matrix, including which models each tier reaches.

Security

Three security considerations matter from day one.

Secrets. Copilot’s context is assembled from your files. If a secret is sitting in a file, it can end up in a prompt. Use environment variables and secret managers, keep credentials out of the repository, and never paste a real token into chat to “check the format”.

# Placeholder only — never commit a real token
export EXAMPLE_TOKEN="replace-with-your-token"

Generated code is unreviewed code. Suggestions can include injection-prone string building, missing input validation, permissive defaults, and outdated cryptographic practice — because such code exists in abundance in the material these models learned from. The /security-review command in Copilot CLI and Copilot code review both help, but neither replaces knowing what you are looking at.

Agent permissions. Agentic surfaces can run commands. The permission prompts are not bureaucracy; they are the control point. Copilot CLI offers permission modes and OS-level sandboxing precisely because “allow everything” is a choice with consequences.

Organisations get further controls on Business and Enterprise: content exclusion to keep specified files out of Copilot’s context, organisation-wide policy management, and audit logs.

Limitations

Being clear about these is more useful than enthusiasm:

• It does not know your system. Copilot has never seen your production incidents, your traffic patterns, or the reason that odd workaround exists.
• It is confidently wrong. There is no signal in the output distinguishing a correct answer from a fabricated one. Confidence is not calibrated.
• It cannot verify its own work unless a tool in the loop runs your tests.
• Output is not reproducible. The same prompt gives different results.
• It is weakest exactly where the stakes are highest — concurrency, security boundaries, financial calculation, anything requiring precise reasoning about state.
• Sessions and context are bounded. The cloud agent stops at 59 minutes; long chat sessions lose earlier detail unless compacted.
• Rate limits and credit allowances are real. GitHub applies rate limiting to protect capacity, and included credits run out.

A useful way to hold all of this: Copilot is excellent at the parts of programming that are transcription — turning a decision you have already made into syntax — and unreliable at the parts that are judgement. Most tasks are a mixture, and the skill is noticing which parts of the current task are which.

Getting started

The shortest path to something real:

1. Get access. Copilot Free requires only a GitHub account. Students should verify for the free Student plan.
2. Install it in your editor. In VS Code the extensions install themselves on first use; other IDEs use their own marketplace.
3. Authenticate, and confirm the status indicator shows Copilot is active.
4. Write a descriptive function signature in a real project and see what completion offers.
5. Open chat and ask it to explain something you did not write. This is where the value becomes obvious fastest.
6. Run the code. Test it. This step is the entire discipline.

How to Get Started with GitHub Copilot walks the whole thing end to end, including a small project you build and run.

Best practices

Condensed, with the reasoning in Lesson 13:

• Give context deliberately. Open the relevant files. Attach what matters. Write repository custom instructions once and stop repeating yourself.
• Specify the contract, not the vibe. Inputs, outputs, error behaviour, and the test you expect to pass.
• Work in increments. A request that changes three things is three requests.
• Review as if a stranger wrote it, because one did.
• Test what you accept, especially when it looks obviously correct.
• Keep secrets out of context, always.
• Constrain agent permissions rather than approving everything to move faster.
• Stay able to do it yourself. The skill you stop practising is the skill you lose, and reviewing generated code requires exactly the skill generating it would have.

Where this fits in the Academy

This guide is Lesson 1 of Cluster 1. The remaining twelve lessons go deeper on each area:

After Cluster 1, the Academy roadmap continues into IDE workflows, language-specific technique, DevOps, the CLI, prompting and models, agents and MCP, and enterprise security.

Frequently asked questions

Is GitHub Copilot free? There is a free tier. Copilot Free gives individuals limited access — 2,000 completions a month, models through auto selection only, and no cloud agent. Verified students get considerably more at no cost through Copilot Student.

Does Copilot write code that works? Often, for well-specified small tasks. It also produces code that runs and is wrong. The distinction is not visible in the output, which is why review is non-negotiable.

Will Copilot replace developers? It changes what the job consists of. The work moves from typing implementations toward specifying, reviewing and integrating them — which requires more judgement, not less. Someone has to know whether the generated code is right.

Can Copilot see my private code? Copilot sends context from your workspace to process a request. Business and Enterprise plans add content exclusion, which keeps specified files out of that context entirely. For details on data handling, GitHub’s Copilot Trust Center is the authoritative source.

What is the difference between agent mode and the cloud agent? Agent mode runs in your editor while you watch. The cloud agent runs on GitHub’s infrastructure and returns a pull request. Lesson 9 covers this in full.

Which model should I use? The default, until you have a reason not to. Model choice matters less than context quality, and it consumes AI credits at different rates.

Next steps

If you are new to Copilot, continue to What Is GitHub Copilot and How Does It Work?, then work through the cluster in order.

If you already use Copilot for completions and want the leap in value, go straight to Copilot Chat and then Agent Mode.

If you are evaluating Copilot for a team, start with the plans comparison — the governance features, not the credit allowances, are usually the deciding factor.