Using GitHub Copilot

Copilot is fast, and speed is exactly what makes it dangerous when you stop reading. The assistant predicts plausible code from what is in its context. Plausible is the trap, because plausible code compiles, looks idiomatic, and passes a glance, while quietly doing the wrong thing.

Consider a developer, Maya, who is wiring a new endpoint. She types a function name, Copilot offers a tidy block that calls an HTTP client, and she presses Tab three times to accept it. It looks right. The build is green. The pull request merges. Two days later the staging deploy fails because the suggestion imported axios-retry, a package the repo has never used and never installed. Copilot had seen that pattern in thousands of other projects and offered it as the obvious next line. The real cost was the broken build, the hour of confusion, and the dependency now half-wired into the codebase, which dwarfed the few seconds of typing it saved.

This happens often enough to plan for. Automated linters and scanners catch the bulk of issues, yet studies of AI-generated code put hallucinated dependencies, package names that do not exist or were never approved, at roughly 1 in 5 samples. A green check tells you the code ran in the pipeline, and correctness, safety, and intent are separate questions you still have to answer.

The payoff of using Copilot well is real. It removes the boilerplate, the repetitive edits, and the first-draft scaffolding that drains attention. The reader who keeps control gets that speed without the slow-motion failures. Control comes from three levers: the context you supply, the scope you set before it writes, and the diff you review before you keep anything. The next section breaks down the surfaces those levers act on.

Copilot is a set of surfaces that share a model and differ in how much they touch your code without asking. Knowing which surface you are in tells you how much review the output needs.

• Inline completion. As you type, Copilot predicts the next lines from the code around your cursor. You accept with Tab. This is the lowest-risk surface, but the most likely to slip an unwanted import or pattern past you because acceptance is a single keystroke.
• Next Edit Suggestions (NES). Instead of only completing where you type, NES reads your recent edits and predicts the next change and its location, including a deletion or an edit elsewhere in the file. It is built for the ripple of a rename or a signature change.
• Ask mode. Chat answers a question and may propose a snippet. It does not modify files. Use it to understand code or weigh an approach before any change.
• Edit mode. Chat applies a change to the files you name and shows an inline diff you approve before it saves. You keep the final say on each hunk.
• Agent mode. Chat reasons across the project, edits multiple files, runs terminal commands, checks the output, and loops until the task passes or it needs you. It surfaces risky commands for confirmation.

The distinction that decides success is matching the surface to the size of the task. A one-line fix wants inline completion or edit mode, where the diff is small and you read all of it. A change that genuinely spans several files and needs commands run wants agent mode. Reaching for agent mode on a trivial edit is the common error, because it turns a glance-sized change into a sprawling diff you now have to audit.

Beyond the editor sits the cloud coding agent. You assign a GitHub issue to Copilot, mention @copilot in a pull request, or start it from the agents panel on GitHub.com. It then runs in an ephemeral GitHub Actions environment, explores the repo, makes changes on a branch, runs tests and linters, and opens a pull request. The tasks are capped (one repository, one branch and PR per task), the environment-setup step is time-limited, and it cannot bypass your branch protections. Across all of these surfaces, the constant is the custom instructions file, which the next section puts to work in a real task.

Maya needs to change one behavior in a real repo. The function parseDate() in src/lib/dateParser.ts throws on an empty string, and the signup form needs it to return null instead so the field can stay optional. She wants the change, a test, and nothing else.

1. Set the rules once. Before touching anything, she opens .github/copilot-instructions.md and confirms it says the project uses Vitest, forbids new date libraries, and ships a test with every behavior change. Now she does not have to repeat that in every prompt.
2. Pick the right surface. This touches one file plus its test, a job that fits edit mode, so she stays out of agent mode. She attaches dateParser.ts and dateParser.test.ts with # references so chat reads the real code.
3. Scope the prompt. She writes: "In dateParser.ts, make parseDate return null for an empty string instead of throwing. Keep the existing valid-input behaviour unchanged. Do not add any new dependency. Add one test for the empty-string case." The constraint about valid input matters, because it tells Copilot what must stay the same.
4. Read the diff. Copilot proposes a two-line guard at the top of parseDate and one new test. The diff is small, so Maya reads every line. The guard returns null before the existing parse path runs, and the valid-input branch is untouched. She accepts.
5. Verify. She runs npm test. The new empty-string test passes and the existing tests stay green, confirming the change is behavior-preserving for valid input.
6. Commit small. One focused commit: the guard and its test. The reviewer sees a five-line diff with an obvious intent that reads as exactly the bugfix it claims to be.

Contrast that with the version where she had skipped the scope and typed only "fix the date handling." Copilot, with room to interpret, would likely have refactored the parser, swapped in a date library, and rewritten two callers. Every line might look reasonable, and the diff would now be sixty lines she has to defend in review. Same model, same repo. The difference was the context and the scope she set before it wrote. That gap between a tight prompt and a loose one is where most of the pitfalls live.

Each of these feels like progress in the moment, which is why they slip through.

• Tab-accepting on autopilot. Completion is one keystroke, so a long suggestion goes in unread. The fix is to treat a multi-line completion like a pull request: read it before Tab, and be suspicious of any import line you did not expect.
• Agent mode for a one-liner. A trivial change becomes a multi-file diff because the agent found "related" work to do. The fix is to size the surface to the task and use edit mode for anything you could describe in one sentence.
• Merging on the green check. A passing pipeline confirms the code ran, while its correctness stays an open question. The fix is to read the diff and the dependency list of any coding-agent PR before approving, and to ask "what does this code assume, and is that safe?" as the review question that earns its keep.
• Re-teaching the same rule. Correcting a convention in chat every session wastes the correction. The fix is to write it once into copilot-instructions.md or AGENTS.md so every future prompt inherits it.

Two genuine edge cases need judgment. The hallucinated dependency. Copilot will sometimes import a package that does not exist or was never approved, and it will look completely ordinary in the diff. When Maya sees an unfamiliar import, the rule is to treat a confident name as unverified and check it against the project’s manifest and the registry before accepting.

The large coding-agent PR. A 2026 reality is that the cloud agent can return a diff bigger than you can carefully read in one sitting, so review capacity is now the bottleneck, ahead of raw code volume. The handling is to scope issues so the resulting PR stays small, and to push back with a @copilot comment asking it to split the work when a PR grows past what one reviewer can hold in their head. These habits get harder, and more valuable, the moment a team shares the repo, which is the last section.

A solo developer can carry the project’s conventions in their head. A team cannot, and Copilot will happily generate code in five different styles unless the rules live somewhere durable. The artifact that fixes this is a versioned instructions file, checked into the repo so it travels with the code and shows up in review like anything else.

A lead, Priya, sets the team up this way. She commits .github/copilot-instructions.md with the framework choices, the forbidden dependencies, the test runner, and the house naming. For a large monorepo she adds nested AGENTS.md files so the backend folder and the frontend folder each carry their own rules, with the nearest file taking precedence. Because these are plain Markdown under version control, a change to the conventions arrives as a reviewed pull request the whole team can see, rather than living as a private setting in someone’s editor.

The second artifact is the review discipline around the coding agent. GitHub enforces part of it: the person who created an issue cannot be the final approver of the agent’s pull request, so a peer or a designated reviewer has to sign off. Priya leans into that. Her team keeps coding-agent PRs under 400 lines, a size repeatedly linked to roughly 30-40% faster review cycles, and the PR description records that Copilot wrote it and what the issue asked for, so a reviewer reads with the right expectations.

Security validation runs automatically on the agent’s output before a human sees it. Copilot runs CodeQL for vulnerabilities, checks newly added dependencies against the GitHub Advisory Database, and scans for exposed secrets, and these checks are on by default. They are a floor that the human read still has to build on, because they catch known patterns and miss the wrong-but-plausible logic only a reviewer notices.

The durable principle, whatever the team size: Copilot proposes, you decide, and the deciding happens on the diff. Start with one small thing. Write a single copilot-instructions.md for one repo this week, keep your next few Copilot changes small enough to read in full, and let the habit grow from there.