Lesson 1 of 8 · 16 min read
Getting Started with GitHub Copilot: Core Concepts and Interaction Modes
GitHub Copilot is not a single button or a single kind of assistance — it's an AI collaborator you reach through several distinct interaction surfaces, each suited to a different kind of work.
1. What Is GitHub Copilot? Orienting to the Core Interaction Surfaces
GitHub Copilot is not a single button or a single kind of assistance — it's an AI collaborator you reach through several distinct interaction surfaces, each suited to a different kind of work. Across this course you'll work with four of them: inline completions, chat, edit mode, and agent mode.
Completions are the always-on baseline: Copilot watches what you're typing and offers to continue it. Chat is conversational: you ask questions about your code and get answers back. Edit mode takes an instruction and applies it as a transformation to code you already have. Agent mode goes further still, carrying out multi-step, project-wide work on your behalf.
GitHub's own materials sometimes summarize a version of this progression with the shorthand Ask / Edit / Agent. That's terminology you may encounter in GitHub's documentation and elsewhere; this chapter uses "chat" (or "Copilot Chat"), "edit mode," and "agent mode" instead — its own usage here, not a claim about how every later chapter renders these terms. Current GitHub documentation, re-verified in August 2026, does continue to list edit mode and agent mode as distinct, named capabilities — so whichever terms you see, the underlying surfaces are durable, current features rather than something that has since been merged or retired.
The next four sections take each surface in turn, starting with completions. Section 6 later consolidates exactly which IDEs support which surface, and Section 8 maps out where deeper material on billing, agentic capability, review, MCP, and prompting lives in later chapters.
2. Inline Completions: Copilot's Foundational Suggestion Mechanism
Inline completions — often called ghost text — are GitHub Copilot's foundational suggestion mechanism. As you type, Copilot watches the code you're writing, and after a brief pause, it displays dimmed text at your cursor that continues what you were typing. Accept it with Tab, or keep typing past it to dismiss it.
This is Copilot's baseline surface: it's the one interaction mode still available even in an editor that supports nothing else, such as Neovim. You'll see exactly what that looks like — and where completions stop being the only surface available — in the cross-IDE matrix in Section 6.
3. Chat Mode: Conversing with Copilot About Your Code
Chat mode is Copilot's conversational surface. It's integrated directly into your IDE and can see the files you currently have open, letting you have a back-and-forth conversation about your codebase rather than just receiving suggestions as you type. GitHub's own materials sometimes label this surface Ask mode as part of an Ask/Edit/Agent progression — that's terminology you may run into in GitHub's documentation, but this chapter uses "chat" and "Copilot Chat" instead.
In practice, this means you can ask Copilot to explain a function, generate tests for it, point out edge cases you might have missed, or draft a CI/CD pipeline configuration — all without leaving your editor.
Because chat reads what's currently open, keeping the relevant file in view before you ask about it matters — you'll rely on this directly in this chapter's activities. (How to phrase requests well, and what other context Copilot can draw on beyond open files, is covered later in the course.)
Chat's place alongside edit mode and agent mode as a distinct, named capability continues to hold in current GitHub documentation.
4. Edit Mode Across IDEs, and Visual Studio's Separate Copilot Edits Feature
Edit mode takes an instruction you give it and applies that instruction as a transformation to code you already have, rather than starting a conversation (chat) or writing new code from a blank cursor (completions).
Here's the detail worth being precise about: GitHub's own canonical cross-IDE feature matrix, re-verified as of 2026-08-26, supports edit mode in exactly two editors — VS Code and JetBrains. Visual Studio is explicitly marked unsupported for edit mode in that matrix.
That doesn't mean Visual Studio has nothing comparable. Visual Studio has its own, separately branded feature called GitHub Copilot Edits (available in VS 2022 17.13+ and VS 2026), offering a similar multi-file diff/preview/accept/rollback workflow. The important distinction is that GitHub's own matrix does not classify this Visual Studio feature under its 'Edit mode' category — the two are namesakes for similar workflows, not the same product capability under one label.
Microsoft's current guidance also steers Visual Studio users toward GA agent mode (Section 5) for autonomous multi-file edits, rather than treating Copilot Edits as the primary tool for that job.
If you've seen older material describing Visual Studio as supporting edit mode 'with some limitations,' treat that as superseded — the current, verified picture is the two-editor / two-feature split described above, not a single feature with varying limitations.
5. Agent Mode: Multi-Step, Project-Wide Automation in the IDE
Agent mode is the fourth core surface: a local, synchronous automation mode that runs directly in your IDE and can carry out multi-step, project-wide work — not just a single suggestion or a single instructed edit, but a sequence of changes toward a goal you describe.
Of the four surfaces, this one has the broadest current reach: current GitHub documentation shows agent mode generally available across VS Code, Visual Studio, JetBrains, Eclipse, and Xcode. Neovim is the sole unsupported editor for agent mode.
One thing to flag now and set aside: there is also a separate, cloud-hosted agent surface, distinct from the local IDE agent mode described here. It is not the same feature, and this chapter does not cover what it can do, who's eligible for it, or how it's billed — a later chapter covers that in full.
6. Cross-IDE Feature Matrix: What Works Where
Now that you've met all four core surfaces, here's the consolidated picture of where each one is actually available, based on GitHub's own canonical feature matrix — plus one newer capability, Agent skills, listed here for availability only.
Completions: the baseline surface
Completions are the baseline surface. This course's evidence establishes that concretely for Neovim, the clearest case: current documentation shows it offers completions and nothing more, with no chat, edit mode, agent mode, or Agent skills, because it lacks a UI to display chat at all. That's a confirmed floor for one IDE, not a documented claim that completions are available wherever Copilot runs generally — this course's evidence doesn't establish anything that broad. Chat support is more IDE-and-version-sensitive than a single static table can capture reliably, so for chat specifically, check GitHub's current live feature matrix for your own IDE rather than relying on a table here or elsewhere in this chapter.
The matrix
The table below covers the three surfaces where cross-IDE support genuinely varies and is fully confirmed for this chapter: edit mode, agent mode, and Agent skills.
Legend: Yes = supported · No = not supported · GA = generally available · Preview = supported in preview.
| Surface | VS Code | JetBrains | Visual Studio | Neovim | Eclipse | Xcode |
|---|---|---|---|---|---|---|
| Edit mode | Yes | Yes | No (own Copilot Edits feature — see Section 4) | No | No | No |
| Agent mode | Yes | Yes | Yes | No | Yes | Yes |
| Agent skills | GA | Preview | GA | No | No | No |
Agent skills availability
Agent skills is a brand-new capability with no prior book baseline. Current documentation shows it generally available in VS Code and Visual Studio, in preview in JetBrains, and unsupported in Eclipse, Xcode, and Neovim. This chapter only tells you where it's available; what it actually does is out of scope here.
Agent mode's reach
Agent mode, by contrast, has the broadest confirmed reach of the surfaces in the matrix — generally available everywhere except Neovim.
Keep this table handy for Activity 1, where you'll look up your own IDE's row before setting up the reference project.
7. Setting Up the Shared Reference Project and Making Your First Copilot-Assisted Change
Throughout this course, you'll work in one shared, evolving reference project rather than a series of disconnected exercises. Each later chapter adds to it: a plan-selection decision in Chapter 2, the Chapter 3 delegated workflow, a review pass in Chapter 4, an MCP server attachment in Chapter 5, deliberate context assembly in Chapter 6, and a capstone in Chapter 8. What you build here is the foundation all of that sits on.
Before you start, pick an IDE. VS Code or JetBrains is recommended, since both support all four core interaction surfaces — completions, chat, edit mode, and agent mode. One difference worth knowing now: Agent skills, the newest capability covered in Section 6, is generally available in VS Code but only in preview in JetBrains. A second gap is concrete rather than abstract: Chapter 4's path-specific custom-instructions mechanism applies in-editor only in VS Code and Visual Studio, so a JetBrains learner should know the shape of that gap before choosing.
Other IDEs are fine too; Activity 1 asks you to record exactly what your chosen IDE supports so you know where any gaps are.
If you're considering Neovim, its completions-only ceiling isn't limited to this chapter: Chapter 6's chat-based activities need chat, and Chapter 5's interactive Agent-mode MCP session, Chapter 3's local-Agent-mode fallback, and a Chapter 8 implementation done with agent mode all need agent mode — surfaces Neovim doesn't support — so most Neovim users end up pairing it with a second IDE well before the course ends. (Copilot's cloud agent is a separate surface whose availability depends on your plan rather than your IDE; Chapter 3 covers it in full.)
This section does not restate the procedure; Activity 1 carries the actual setup steps.
8. Course Map: Where Billing, Agent, Review, MCP, and Prompting Topics Live
This chapter gave you the foundational vocabulary and your first working setup. Several topics you might expect to see here are covered fully in later chapters instead — naming them now, without teaching them, so you know where to look.
| Topic | Owning chapter |
|---|---|
| AI Credits billing model, plan tiers, allowances | Chapter 2 |
| Cloud agent capabilities, eligibility, billing | Chapter 3 |
| Copilot code review | Chapter 4 |
| MCP server configuration | Chapter 5 |
| Context definition and mechanisms; prompt-composition technique | Chapter 6 |
| Legacy premium-request billing | Chapter 7 (optional reference) |
Each entry is a pointer only — this table doesn't tell you anything about what those topics cover, only where to find them when you get there.
Activity 1: Set Up the Shared Reference Project and Confirm Your IDE's Copilot Surfaces
Goal: Get the reference project running with GitHub Copilot enabled, and know exactly what your IDE supports before you build on it.
Steps:
-
Install or enable GitHub Copilot in one supported IDE: VS Code, JetBrains, Visual Studio, Neovim, Eclipse, or Xcode.
-
Set up the shared reference project. It needs five things:
- a manifest or config file for your language's tooling (for example
package.json,pyproject.toml, orgo.mod— whatever your language normally uses) - at least two source files spanning two concerns (for example, one module plus a caller, or one module plus a small helper)
- a test exercising each of those files
- a linter configured for your language (a formatter alongside it is optional but welcome)
- a local Git repository tracking all of it
Starting from scratch: create a new project directory, run
git init, add the manifest for your language, write a small module plus a second file that calls it or a small helper, add a test for each using your language's usual test tooling, and configure a linter (for example ESLint, Ruff, orgolangci-lint). This takes only a few minutes.Already have a small personal project of this shape? Use it instead — a manifest, at least two source files across two concerns, tests, a linter, and version control is all that matters, not where the project came from.
(Two source files rather than one, because Chapter 4's path-scoped instructions and Chapter 8's capstone change both need more than one file to act on.)
- a manifest or config file for your language's tooling (for example
-
Run your language's standard install-and-test command (for example,
npm install && npm test,pip install -e . && pytest, orgo test ./...) and your linter, and confirm both complete cleanly. This is what "running" means for this activity — don't move on to Activity 2 until it does. -
Using Section 6's cross-IDE matrix for edit mode and agent mode — together with its statement that completions are the baseline surface illustrated by Neovim's completions-only ceiling, and its pointer to check GitHub's live feature matrix for chat support — record which of completions, chat, edit mode, and agent mode your IDE supports.
-
If your recorded chat entry for your chosen IDE is negative, decide now whether you'll use a second IDE with chat support for Activity 3's chat exercise, or record the blocker and note which later activities it affects. If you're using Neovim specifically, that gap goes further than chat alone: Chapter 6's chat-based activities need chat, and Chapter 5's interactive Agent-mode MCP session, Chapter 3's local-Agent-mode fallback, and a Chapter 8 implementation done with agent mode all need agent mode — neither of which Neovim supports. (Copilot's cloud agent is a separate surface gated by plan rather than IDE, and is covered in Chapter 3.) Decide now whether you'll pair Neovim with a second IDE for those later activities too, since this is the point in the course where you can see the full downstream cost at once.
Expected outputs:
- A running reference project meeting the five requirements in Step 2 (manifest, two source files, a test for each, a linter, Git), with its install-and-test command and linter both passing cleanly, and GitHub Copilot enabled in your chosen IDE.
- A short written record (checklist or table) of which surfaces your IDE supports, checked against the current feature matrix.
Hints:
- Neovim showing only completions is expected behavior, not a misconfiguration.
- Visual Studio and JetBrains support different subsets of the four surfaces — reread Section 4 and Section 6 before assuming parity between them.
Checkpoint: Your edit mode and agent mode entries should match Section 6's table for your chosen IDE. Your completions entry should reflect Section 6's baseline-completions statement (completions as the floor surface, illustrated by Neovim's completions-only ceiling), and your chat entry should reflect a check of GitHub's current live feature matrix rather than restating this chapter's table. Your install-and-test command and your linter should both complete without errors. A mismatch on edit mode or agent mode sends you back to Section 6; a failing setup means the project isn't ready for Activity 2 yet.
Activity 2: Make Your First Change with Inline Completions
Goal: Practice the ghost-text completion workflow directly on the reference project.
Steps:
- Open a file in the reference project and start writing a small, well-scoped function or test.
- Pause typing to let a completion suggestion appear as dimmed ghost text; accept correct suggestions with Tab and reject incorrect ones by continuing to type past them.
- Commit the resulting small change to the reference project.
Expected outputs:
- One committed code change produced with the help of at least one accepted inline completion.
Hints:
- Completions appear after a brief typing pause — give Copilot a moment before deciding a suggestion isn't coming.
Checkpoint: A commit should exist containing a completion-assisted change. Be ready to point to which specific lines came from an accepted completion versus lines you typed yourself.
Activity 3: Use Chat to Extend and Explain Your Change
Goal: Practice chat mode by having Copilot discuss and extend the change you just made with completions.
Steps:
- Check your Activity 1 record for whether your chosen IDE supports chat.
- If it does, open Copilot Chat in the same IDE session, with the file from Activity 2 still open — chat reads what's currently open, so this matters. Ask Copilot to explain the function you just wrote, then ask it to generate a test or identify a missing edge case for it.
- If your chosen IDE's chat support is negative, follow the decision you made in Activity 1: either open Copilot Chat in a second IDE that supports chat, with the equivalent file open, and complete the same exchange there, or record the blocker and note which later activities it affects, then stop here.
- Apply the resulting test, or your own adaptation of it, as a second change to the reference project.
Expected outputs:
- A brief record of the chat exchange — the explanation you got, plus at least one follow-up request — completed either in your original IDE or a second IDE with chat support.
- A second commit adding the chat-suggested test or edge-case handling, or, if no IDE with chat was available, a recorded blocker naming which later activities it affects.
Hints:
- Keep the relevant file open in your editor before asking chat about it.
Checkpoint: A second commit should exist containing a chat-derived addition, or, if chat was unavailable in every IDE you used, a recorded blocker naming which later activities it affects. If you have the commit, confirm it came from chat, not from completions or edit mode; if you have the blocker record instead, confirm it names the affected activities and matches your Activity 1 chat-support record.
Activity 4: Edit Mode vs. Visual Studio's Copilot Edits, and Using the Course Map to Locate Later-Chapter Ownership
Goal: Confirm you can separate GitHub's canonical edit mode from Visual Studio's own, separately branded Copilot Edits feature, and confirm you know where the topics this chapter didn't teach actually live.
Part A: Edit Mode vs. Copilot Edits
Steps:
- For VS Code, JetBrains, and Visual Studio, state plainly whether GitHub's edit mode is supported.
- For Visual Studio specifically, name the feature it does have for multi-file diff/preview/accept/rollback, and state what Microsoft currently recommends instead for autonomous multi-file edits.
- Write one sentence a teammate could reuse to correctly describe the difference without conflating the two.
Expected outputs:
- A short written answer set covering all three IDEs plus the Visual Studio distinction.
Hints:
- Don't describe Visual Studio as supporting edit mode 'with limitations' — that claim is superseded by the current feature matrix.
Checkpoint: Your answer should not describe Visual Studio as supporting GitHub's edit mode. If it does, reread Section 4 and revise.
Part B: Using the Course Map to Locate Later-Chapter Ownership
Steps: 4. Without Section 8 open, match each of these six topics to its owning later chapter from memory: AI Credits billing and plan tiers; cloud agent capabilities; Copilot code review; MCP server configuration; prompting and context technique; and legacy premium-request billing. 5. Open Section 8, check your matches against its course map, and correct any mismatch.
Expected outputs:
- A completed six-item topic-to-chapter matching record, checked against Section 8's course map.
Checkpoint: All six topics should point to the chapter that Section 8 names. A mismatch means rereading Section 8 before moving on.
Reference Project Continuity — Chapter 1
Starting state: no reference project exists yet. You have GitHub Copilot access, but you haven't used it in an IDE.
By the end of this chapter, you'll have a running, Copilot-enabled reference project — a small, realistic multi-file project: a manifest/config file, at least two source files spanning two concerns, a test for each of those files, a linter, and a local Git repository, all confirmed running via a single install-and-test command and linter run (Activity 1). It will contain at least two committed changes: one produced with the help of inline completions (Activity 2), and one produced with the help of chat (Activity 3). Alongside the code itself, you'll have a documented record of which Copilot surfaces your chosen IDE supports (Activity 1).
This is the baseline every later chapter builds on: Chapter 2 has you choose a plan for this same project, Chapter 3 runs its delegated workflow against it, Chapter 4 reviews changes made to it, Chapter 5 attaches an MCP server to it, Chapter 6 practices deliberate context assembly against it, and Chapter 8's capstone draws all of that together. Nothing here is throwaway — treat the setup and the first two commits as work you'll return to, not a one-off exercise.