English for GitHub Copilot
Learn the English vocabulary for GitHub Copilot: completions, prompts, and hallucinations, explained for discussing AI-assisted coding clearly.
“Copilot wrote it” is not an explanation a code reviewer should accept — the vocabulary in this guide is what lets a team discuss AI-assisted code with the same precision as human-written code, including naming when the tool got something specifically wrong.
Key Vocabulary
Completion — a suggested block of code Copilot generates based on the surrounding context, offered inline as you type and accepted or dismissed with a keystroke. “That completion looked right at a glance, but it used a deprecated method signature — always worth a second look before accepting, especially in unfamiliar parts of the codebase.”
Prompt (context) — the surrounding code, comments, and open files Copilot uses as input to generate a completion; the quality of a completion depends heavily on how much relevant context is actually visible to it. “The suggestions got noticeably better once we had the type definitions open in another tab — Copilot’s prompt includes nearby open files, so more relevant context in view means better completions.”
Hallucination — a confident but incorrect suggestion, such as a function or library method that doesn’t actually exist, generated because the model is predicting plausible-looking code rather than verifying it against real APIs.
“That’s a hallucination — there’s no fetchWithRetry method on that client. It looks exactly like a real API, which is exactly why it slipped past review without anyone questioning it.”
Inline chat — a conversational interface within the editor for asking Copilot to explain, refactor, or fix a specific piece of selected code, distinct from the ambient autocomplete-style completions. “Instead of accepting the raw completion, I used inline chat to ask it to explain the regex it generated — turned out it didn’t handle the edge case we needed, so I rewrote that part manually.”
Suggestion acceptance rate — a metric some teams track for how often generated completions are accepted versus dismissed, used as a rough (and imperfect) signal of how useful the tool is being for a given codebase or task type. “Our suggestion acceptance rate is much lower on the legacy service than on new services — Copilot has less relevant context to draw from in an older, less consistently structured codebase.”
Common Phrases
- “Did you verify that completion, or did it just look plausible?”
- “Is this a hallucination — does that method actually exist?”
- “Would more context in view improve these completions?”
- “Did you use inline chat to get an explanation, or accept it as-is?”
- “Is the acceptance rate telling us anything useful here, or is it just noise?”
Example Sentences
Flagging an issue in code review: “This completion references a config option that doesn’t exist in our version of the library — it’s a hallucination, not a typo. Worth double-checking anything Copilot suggests when it’s dealing with an unfamiliar or older API.”
Explaining why suggestions have been unreliable: “The completions in this file have been consistently off because there’s almost no relevant context open — the type definitions and the function it’s calling are both in files we haven’t touched this session.”
Describing a workflow choice: “For anything nontrivial, I use inline chat instead of just accepting the raw completion — asking it to explain its own suggestion catches a surprising number of hallucinated details before they make it into a PR.”
Professional Tips
- Say hallucination, not “bug,” when a suggestion invents something that doesn’t exist — it’s a distinct failure mode from a logic error and the review response is different (verify the API exists at all, not just whether the logic is correct).
- Treat every completion as a draft requiring verification, especially around unfamiliar APIs — accepting code because “it looked right” is exactly the failure mode that lets hallucinations into production.
- Mention when you used inline chat for an explanation in a PR description — it gives reviewers useful context on how a piece of generated code was arrived at and what was actually verified.
- Be cautious drawing conclusions from suggestion acceptance rate alone — a high rate can mean the tool is genuinely useful, or that a team is accepting suggestions without enough scrutiny.
Practice Exercise
- Write a sentence explaining what a hallucination is in the context of an AI coding assistant.
- Explain why the amount of visible context affects completion quality.
- Describe a situation where you’d use inline chat instead of just accepting a completion.