Copilot Chat Features

Beyond inline completions, GitHub Copilot offers a chat interface for more conversational, task-oriented interactions within the coding environment.

Copilot Chat. This lets developers ask questions, request explanations of existing code, or ask for help debugging directly within their editor, without leaving the coding context to use a separate general-purpose chat tool.

Common use cases. Developers commonly use Copilot Chat to get an explanation of unfamiliar code, ask for a specific function to be written or modified, generate test cases, or get help diagnosing an error message — all with the current file or project as available context.

Slash commands and context references. Copilot Chat generally supports specific commands or references that let a developer point it at particular files, functions, or the current error, rather than needing to describe everything in plain text each time.

Complementing inline completion. While inline completion is best for quick, in-the-flow suggestions as you type, chat is better suited to more involved requests — explaining a design decision, refactoring a larger block, or working through a bug — where a back-and-forth conversation is more useful than a single suggested completion.

Explaining unfamiliar code. One of the highest-value uses of chat is onboarding: selecting a function nobody on the team remembers writing and asking what it does, what its inputs and outputs are, and what assumptions it makes. The answer is a starting hypothesis rather than documentation — it is derived from reading the code, so it can miss intent that lives outside the file — but it is usually far faster than reconstructing the logic unaided, and it gives you specific claims you can then verify against the code itself.

Generating tests. Asking for tests around an existing function is a natural fit for chat, because the request needs more context and more back-and-forth than a single completion. The assistant can propose cases you had not considered, particularly around boundaries and error paths, and can mirror the conventions of tests already in the project when it can see them. The generated tests still need to be read carefully: a test that asserts the current behavior is only useful if the current behavior is actually correct.

Working through an error. Pasting or referencing an error message along with the relevant code is a well-suited chat task, since diagnosis is inherently conversational — a first hypothesis, a check, a refinement. The assistant can recognize common error patterns quickly and suggest where to look. It cannot observe your runtime state, so it is proposing candidate explanations rather than diagnosing definitively, and the developer still has to confirm which explanation is the real one.

Scoping the context deliberately. The quality of a chat answer depends enormously on whether the assistant can see the code the answer depends on. Pointing it explicitly at the relevant files or selections, rather than asking a general question and hoping the right context is included, is the single most reliable way to improve results. Conversely, dumping in far more context than the question requires can dilute the response, so the goal is relevance rather than volume.

Iterating within the conversation. Chat's advantage over a one-shot completion is that the exchange persists: you can reject an approach, add a constraint you forgot, or ask for a simpler version, without restating the whole problem. Treating the first answer as a draft and steering it — "keep the structure but handle the empty case", "do this without adding a dependency" — usually converges faster than rewriting the original question from scratch.

Where chat falls short. The assistant does not execute code, does not see your data, and has no access to requirements that were never written down. Long conversations can drift, with earlier constraints gradually losing force, and confident explanations of code can still be wrong in ways that read perfectly. For anything consequential, chat output is a lead to verify rather than an answer to trust, and starting a fresh conversation is often better than fighting a drifting one.

Asking for a plan before an implementation. For a change of any real size, asking the assistant to describe its intended approach before writing code is usually worth the extra turn. A proposed plan is far cheaper to read and correct than a finished implementation built on a wrong assumption, and disagreements about approach surface while they are still easy to resolve. It also exposes what the assistant has misunderstood about the requirements — if the plan describes a different problem from the one you have, no amount of well-written code against it will be useful. This is the same decomposition principle that applies to prompting generally, expressed in a coding workflow.

Choosing between the two modes. A practical rule of thumb: if you already know what you want to write and the assistant is only saving you keystrokes, inline completion is the right mode. If you need to understand something, weigh an approach, or make a change that spans more than the cursor's immediate surroundings, chat is the better fit. Most experienced users move between the two continuously rather than committing to either.

Together, inline completion and chat give Copilot two complementary modes of assistance suited to different kinds of coding tasks.