Why This Matters

If you cannot explain what a tool is, you cannot use it deliberately. Most Copilot frustrations come from one of two misconceptions: either treating it as a search engine ("it should know the exact API I want") or treating it as an oracle ("it suggested this, so it must be correct"). A precise mental model prevents both.

This lesson gives you that model. After it, every later lesson — prompting, verification, evaluation, architecture — will slot into a framework you already understand.

Concept Explained

GitHub Copilot is an AI pair-programmer. The word "pair" matters: a human pair programmer sitting next to you would suggest code, explain unfamiliar code, write tests, point out bugs, and help you stay unblocked — but they would never replace your judgment about what to ship. Copilot plays exactly that role, except it never tires, it is always available, and its suggestions are based on patterns learned from enormous quantities of public code.

Technically, Copilot is a wrapper around large language models (currently the GPT-5 family from OpenAI, Claude from Anthropic, and Gemini from Google, depending on plan and context) tuned for the developer workflow. GitHub adds a layer of context engineering on top: which files in your repo are relevant, what code you've just edited, what's in your terminal, what's in the issue you're working on. The model never sees your whole computer — it sees a curated snapshot, and it produces a response based on that snapshot.

The most important shift in mindset is this: Copilot does not retrieve answers from a database. It generates them, token by token, based on probabilities. That is its superpower (it can produce code that has never existed before) and its risk (it can produce confident-sounding nonsense). Everything in this course is, at root, about maximizing the superpower and minimizing the risk.

How It Works

A single Copilot interaction has four phases:

1. Context assembly. Copilot gathers signals: the file you have open, the lines around your cursor, recently edited files, attached files, the contents of your active terminal, the issue you mentioned, and any explicit instructions in .github/copilot-instructions.md.
2. Model invocation. The assembled context is sent to a hosted model. With multi-model support, the model chosen is either the one you picked in the dropdown or the one auto-selection picked for you.
3. Response generation. The model emits tokens — text, code, or a mix — one chunk at a time. Streaming makes this visible as the response types itself out.
4. Surface-specific rendering. The response is interpreted by whatever surface you used. Inline completion renders as ghost text. Chat renders as a conversational message. The CLI renders as a proposed shell command or file diff.

That loop repeats for every keystroke (for inline completions) or every message (for chat). When you accept a suggestion, the accepted text becomes part of the next round's context, which is why Copilot often gets noticeably better within a single file as you keep working.

Step-by-Step Tutorial

1. Recognize the three primary surfaces you will touch daily

For most beginners, three surfaces cover 90% of daily use:

• Inline completions — gray ghost text that appears as you type in your editor. Press Tab to accept.
• Copilot Chat — a side panel where you ask natural-language questions and get answers grounded in your codebase.
• Slash commands — short, scoped instructions like /explain, /tests, /fix that do a specific, useful thing.

The other five surfaces (CLI, GitHub.com, coding agent, Spaces, Extensions, REST API) become important later — but they are not where you start.

2. Trigger your first inline completion

Open any source file in VS Code with the Copilot extension installed and signed in. Type a function signature like function greet(name) { and pause for half a second. Gray ghost text will appear proposing the function body. Press Tab to accept, or Esc to dismiss. If you don't like the first suggestion, press Alt (or Option on macOS) + [ and ] to cycle alternatives.

3. Ask Copilot Chat your first question

Open the Copilot Chat panel (Ctrl+Cmd+I on macOS, Ctrl+Enter on Windows/Linux in VS Code). Type a question like "What does this file do?" while your cursor is in any source file. Copilot will read the file and produce a summary. This is the simplest possible use of @workspace scope, which we'll cover in BE-10.

4. Form your 60-second explanation

Write down — in your own words — what you would tell a colleague who asked "what is Copilot?" Aim for three sentences:

1. What it is (AI pair-programmer).
2. Where it lives (editor + chat + CLI + GitHub.com).
3. What it is good and bad at (good at generating plausible code from context; bad at knowing your actual intent and at being correct without verification).

If your three sentences cover those points, you have a usable mental model.

Real-World Example

Imagine you're a junior developer at a logistics company, asked to add a function that formats an address object into a single printable string. You have written similar functions before but not exactly this one. You open the file, type the function signature function formatAddress(addr: Address): string {, and pause. Copilot suggests a body that handles street, city, state, ZIP, and country — including an edge case for missing ZIP codes that you had not thought of. You read it, accept it, then immediately write a unit test to verify the formatting behaves correctly. The function took 30 seconds to draft instead of 5 minutes, and the test took another 30 seconds to scaffold. The 4 minutes you saved go to thinking about edge cases — which is exactly what a good pair programmer frees you to do.

Now imagine the same developer copies a 200-line legacy Bash script into the Chat panel and asks "What does this script do?" Copilot produces a structured summary in seconds — something that would have taken 15 minutes to read. The developer spends the saved time verifying the summary against the actual script, catching two small misreadings. This is the daily rhythm: speed up the draft, slow down the verification.

Example Prompts / Commands / Code

Explain in 3 bullets what this file does, and list any obvious bugs.

// Type this in a .ts file with Copilot enabled:
function sumEven(numbers: number[]): number {
  // pause here — Copilot suggests the body
}

// Expected ghost-text suggestion:
//   let total = 0;
//   for (const n of numbers) {
//     if (n % 2 === 0) total += n;
//   }
//   return total;

/explain

// Highlight a function in your editor, then type /explain in Chat.
// Copilot produces a structured explanation: purpose, parameters,
// return value, side effects, and edge cases.

Common Mistakes

• Treating Copilot as a search engine. It does not retrieve; it generates. Asking “what's the API for X?” will produce a plausible-sounding answer that may not match the real API. Always cross-check against official docs.
• Treating Copilot as an oracle. A confident tone does not imply correctness. The model can be confidently wrong about syntax, parameter order, and behavior.
• Accepting suggestions without reading them. Tab-Tab-Tab is the single biggest source of Copilot-induced bugs. Always read what you accept.
• Assuming Copilot sees your whole project. It sees a curated snapshot. If a function lives in another file you haven't opened, Copilot may not know about it unless you ask via @workspace.
• Pasting secrets into Chat. Even on plans that don't train on your data, prompt content leaves your machine. Never paste API keys, tokens, or credentials. (Covered in BE-32.)
• Expecting Copilot to know your team's conventions. Unless you tell it (via a .github/copilot-instructions.md file — covered in IN-39), it uses generic conventions that may not match your codebase.

Best Practices

• Always read what you accept. Treat every suggestion as a draft from a junior colleague.
• Keep official docs open in a browser tab. When Copilot proposes an unfamiliar API, verify before pasting.
• Use Copilot for the shape of code first; use it for the substance only after verification.
• Write the test before the implementation when you can. TDD with Copilot is covered in IN-33.
• Set your editor to show ghost-text suggestions only after a pause — instant suggestions can be distracting while you're thinking.
• Build the habit of asking “what could go wrong with this?” — both to Copilot and to yourself. Self-checking prompts are covered in IN-30.

Troubleshooting

Practical Exercise

Frequently Asked Questions

Further Reading

• GitHub Copilot product overview
• GitHub Copilot documentation
• About GitHub Copilot
• GitHub Copilot plans and pricing

Official References

• About GitHub Copilot — official
• GitHub Copilot product page
• GitHub Copilot documentation home
• GitHub blog — Copilot

Related lessons: BE-02, BE-03, BE-04