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

  1. Write a sentence explaining what a hallucination is in the context of an AI coding assistant.
  2. Explain why the amount of visible context affects completion quality.
  3. Describe a situation where you’d use inline chat instead of just accepting a completion.