GH-300: Code Completion

Code completion is the fastest GitHub Copilot experience to learn and one of the easiest to misuse. Inline suggestions can save keystrokes, finish repetitive code, infer patterns from nearby implementations, and sometimes propose the next edit before the developer explicitly asks. The speed can create a false impression that completion is a low-risk feature. In reality, every accepted suggestion becomes part of the codebase and deserves the same engineering judgment as code typed manually.

For the current GH-300 exam, code completion sits inside the broader objective of using Copilot in the IDE, understanding its suggestion lifecycle, improving productivity, and validating AI output. The exam language is broader than old autocomplete mental models: GitHub now describes inline suggestions and next edit suggestions, and model choice can vary by supported editor and plan.

Know what inline suggestions are optimizing for

Inline suggestions predict useful code edits from the context available in the editor. They can complete a line, generate a block, or propose a change at another relevant location. That makes them highly effective for repetitive patterns, boilerplate, tests, data transformations, and code that follows an established local convention.

They are not automatically optimizing for your organization’s architecture, security model, performance constraints, or long-term maintainability. The model sees evidence in the context and predicts a plausible continuation. If the surrounding code contains a poor pattern, the completion may reproduce it efficiently.

Inline completion is optimized for the next useful edit, not for explaining every design alternative. That is why it can feel strong on boilerplate, repetitive transformations, local conditionals, and test scaffolding while being a poor venue for architectural debate. If you need to compare approaches, understand an unfamiliar subsystem, or justify a security decision, move to Chat or another workflow that gives the model room to reason and gives you room to inspect the answer before code is inserted.

Give the completion better local context

Completion quality improves when the file communicates intent. Descriptive names, clear types, focused comments, nearby examples, and coherent function boundaries give Copilot stronger signals. A short comment that states an invariant can be more valuable than a vague request because it becomes part of the immediate coding context.

Open files and repository context can also matter depending on the IDE and feature. The practical workflow is to expose only useful context, then judge whether inline completion is the right surface. If the task requires discussion, architecture trade-offs, or broad repository exploration, Copilot Chat or an agent workflow may be better.

Context engineering for inline completion is often simple and local. Meaningful variable names, a clear function signature, nearby type information, existing tests, and a concise comment about the intended behavior can make the next suggestion substantially better. By contrast, a long explanatory comment that contradicts the code can steer Copilot in the wrong direction. The developer’s job is to make the current state of the codebase legible to both humans and the assistant.

When a suggestion repeatedly misses a project convention, look for reusable repository instructions or examples rather than restating the same rule in every comment. The objective is not to maximize tokens around the cursor. It is to expose the most relevant constraints at the point where the model generates the next change.

Use comments carefully

Developers often steer completion with comments such as `// validate the token and reject expired sessions`. This can be effective because it expresses intent close to the code. But comments should describe the requirement, not ask the model to invent security policy. A completion can satisfy the comment syntactically while missing an organizational rule.

Treat comments as one layer of context. For complex work, pair them with tests, types, existing helper functions, or explicit prompt context. Prompt engineering fundamentals provide a useful mental model: specify the goal, relevant context, constraints, and output expectations even when the interface is an editor rather than a chat box.

Accepting a suggestion is an engineering decision

Copilot makes acceptance frictionless by design. That is useful for flow, but the developer remains responsible for correctness. Read the suggestion before accepting it, especially when it touches authentication, authorization, data access, concurrency, cryptography, parsing, financial calculations, or destructive operations.

Then validate after acceptance. Compile or type-check the code, run relevant tests, inspect edge cases, and compare unfamiliar APIs with authoritative documentation. A suggestion that looks reasonable can call a nonexistent method, use a deprecated pattern, or subtly invert a condition.

Fast acceptance can hide risk because generated code often looks idiomatic. Review imports, error paths, boundary conditions, authentication assumptions, data handling, and compatibility with the project’s supported versions. For library calls, verify that the API actually exists in the version the repository uses. For database or network code, inspect timeouts, retries, transaction behavior, and resource cleanup rather than stopping at syntax.

A useful habit is to predict the test that could falsify the suggestion before accepting it. If Copilot writes a parser, identify malformed input. If it writes authorization logic, identify a user who should be denied. If it writes concurrency code, identify a race or failure path. This shifts completion from passive code generation to active engineering review.

Understand next edit suggestions

Modern Copilot experiences can predict edits beyond the cursor. That changes the mental model from line completion to local code transformation. The system may infer that a rename, signature change, or newly added field implies edits elsewhere and propose them.

These suggestions can accelerate refactoring, but they can also spread a mistaken assumption across multiple locations. Review the diff, not just the highlighted fragment. The wider the proposed change, the more the workflow begins to resemble an automated edit rather than autocomplete, and the stronger the case for tests and human review.

Next edit suggestions extend the idea of completion beyond the immediate cursor by anticipating related edits. They can be useful after a rename, signature change, or local refactor because the next logical modification may be elsewhere in the file or project. The productivity gain is real, but so is the risk of accepting a chain of correlated assumptions. One wrong early change can make later suggestions look internally consistent while moving farther from the intended design.

Review each step against the original goal and run the appropriate tests frequently. If the work becomes architectural or spans many files with dependencies, switch to a planning or agent workflow where the change can be scoped explicitly. Inline acceleration is strongest when the developer already understands the desired local transformation.

Use model choice as a trade-off, not a ritual

GitHub allows supported users to choose among available models for inline suggestions in some IDE configurations. The list changes over time. A model that performs well for one language or task may not be the best for every repository.

For GH-300, avoid memorizing a static model list. Understand the operational decision: model choice can affect quality, latency, and behavior, while the surrounding product still applies Copilot context construction and policy controls. Changing the inline-suggestion model also does not necessarily change other Copilot surfaces.

Model selection can affect latency, capability, and sometimes the shape of suggestions, but changing models should follow a reason. If completion struggles because the file lacks relevant context, a larger model may still guess poorly. If a simple repetitive edit works well with a faster option, switching to a heavier model can add delay without practical benefit. Start by diagnosing the task and context before escalating model capability.

For GH-300 scenarios, treat model choice as one variable among prompt clarity, repository context, task scope, and review. The model does not replace tests, documentation, or secure coding practices, and a better model cannot compensate for an ambiguous requirement that the developer never supplied.

Public-code matching changes what you may see

GitHub checks suggestions for matches to public code. Depending on organization or account policy, matching suggestions can be blocked or presented with a reference. Code referencing can show repository and license information for supported matches after a suggestion is accepted.

This feature reduces one class of uncertainty but does not eliminate intellectual-property review. Developers still need an organizational policy for third-party code and should not assume that the absence of a match proves originality. Responsible use of GitHub Copilot keeps human review, licensing concerns, and organizational policy central to those judgment calls.

Know when completion is the wrong tool

Inline completion is strongest when the desired change is local and the surrounding context already contains the pattern. It is weaker for open-ended architecture, multi-file migrations, ambiguous bugs, broad dependency upgrades, and tasks where the developer needs an explanation before changing code.

In those situations, switch surfaces deliberately. Use Chat for exploration and explanation, plan or agent workflows for broader tasks, code review for independent feedback, and tests for behavioral verification. Productivity comes from choosing the right interaction mode, not forcing every task through ghost text.

Use completion for a narrow next step; use Chat when you need explanation or comparison; use a planning workflow when the task needs decomposition; use an agentic workflow when several files, tools, or commands must be coordinated. Choosing the wrong surface creates unnecessary friction. Trying to perform a repository-wide migration one ghost-text suggestion at a time is inefficient, while invoking an autonomous workflow for a one-line guard clause adds overhead and risk.

GH-300 preparation should therefore include tool-selection scenarios. Ask what information must be gathered, how many files may change, whether tests or commands must run, and how much human review is needed. The best Copilot experience is not the most automated one; it is the mode whose control level matches the task.

Practice the lifecycle, not keyboard shortcuts

GH-300 preparation should include real editor sessions, but memorizing accept/dismiss shortcuts is less valuable than understanding the lifecycle. Start with clear code, observe the suggestion, inspect the context that likely influenced it, accept only what you understand, and validate the result. Then intentionally create ambiguous or incomplete context and notice how suggestion quality changes.

The GH-300 skills and domains places inline suggestions beside Chat, CLI, agents, privacy, and prompt engineering. Code completion is only one surface, but it is an excellent place to learn the core discipline that applies to all of them: context shapes output, policy shapes availability, and the human owns the final code.

A useful practice drill starts with a partially written function and a small test file. Accept one suggestion, inspect the diff, run the tests, then deliberately reject the next suggestion and improve the surrounding context before asking again. The goal is to experience how completion quality changes with the code state and to build the habit of verifying after each meaningful change rather than after a long chain of acceptances.

Also practice a stop condition. If the task expands into a cross-file refactor, security-sensitive change, or architecture decision, pause completion and move to a more appropriate Copilot surface or a human design step. Efficient Copilot use depends as much on knowing when to change modes as on accepting good suggestions quickly.