English for GitHub Copilot

“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.

Navigating Nuance: Beyond Basic Completion

For non-native English speakers particularly, mastering the specific terminology surrounding AI code completion tools like GitHub Copilot can feel daunting. It’s not just about understanding what it does; it’s about communicating effectively within a technical workflow – during code reviews, Slack discussions, and pull request descriptions. A lot of the nuance lies in how you frame suggestions, address potential issues, and describe the behavior of these intelligent assistants. Often, simply saying “it suggested this” isn’t enough to convey the level of confidence or caution needed.

One frequent scenario is receiving a code review comment suggesting a change – perhaps a refactoring for improved readability, or an adjustment to handle edge cases. Instead of reacting defensively (“Why are you changing my code?”), a more professional response might be, “Thanks for flagging this potential issue. Copilot’s suggestion to extract this logic into a separate function aligns with our team’s approach to maintainability and reduces the risk of errors in the long run.” Notice the use of phrases like “flagging,” “aligns with,” and “reduces the risk.” These aren’t just polite words; they demonstrate an understanding of the broader technical context. Similarly, when describing a change you’ve made based on Copilot’s suggestion in a PR description, stating “Copilot suggested this improved error handling” is better than simply saying “I fixed a bug.”

Another critical element is recognizing and appropriately addressing instances where Copilot produces inaccurate or misleading suggestions – often referred to as “hallucinations.” It’s vital to be transparent about these situations. A helpful approach might be, “Copilot generated this code snippet, but it appears to be based on an outdated library version. I’ve updated it to reflect the current best practices and ensure compatibility.” Avoid blaming Copilot directly; focus on the factual issue and your corrective action. This demonstrates critical thinking and responsible use of the tool.

Finally, when prompting Copilot effectively – crafting clear and specific instructions – is key to getting useful suggestions. Vague prompts yield vague results. Being precise with your requests significantly improves the quality of the output.

Here’s an example demonstrating how Copilot might be used in a simple Python script:

# Example: Using Copilot to generate a function for calculating the factorial of a number

def factorial(n):
  """Calculates the factorial of a non-negative integer."""
  if n == 0:
    return 1
  else:
    result = 1
    for i in range(1, n + 1):
      result *= i
    return result

This simple example demonstrates how Copilot can accelerate the development process. Remember, effective communication and critical evaluation are just as important as the tool itself.