Working with Copilot instead of against it
Most developers who dislike GitHub Copilot are using it as a magic button and getting frustrated when the magic misfires. Used well, it is closer to a fast pair programmer that handles the boring 70% — boilerplate, tests, repetitive refactors — so you spend your attention on the hard 30%. The difference between “Copilot is annoying” and “Copilot 10בd me” is almost entirely technique. This guide covers the techniques that matter.
How to guide Copilot’s suggestions
Copilot predicts from context, so your job is to feed it good context.
Write intent-revealing comments. A line like // fetch user, retry 3x on 429, return null on 404 before an empty function reliably produces a strong first draft.
The comment is a prompt.
Keep related files open. Copilot reads your open tabs. If you are implementing a function that consumes a type defined elsewhere, open that file so the model sees the shape.
Name things clearly. A function named validateEmail produces better completions
than doCheck. Good names are themselves prompts.
Use inline chat for refactors. Select code, invoke inline chat, and describe the change — “extract this into a hook” or “add error handling”. It edits in place and shows a diff, which is far safer than accepting blind completions.
Use the chat panel for questions. Ask it to explain an error, summarise an unfamiliar file, or scaffold a new module from a description. Workspace-aware chat can answer questions across the whole codebase.
Tips, tests, and knowing when to stop
The highest-leverage use is tests: open the file under test, then prompt “write unit tests covering the empty input, the error path, and a typical case” — Copilot is unusually good here because the behaviour is already defined by the code. Always read every suggestion before accepting; it produces confident, plausible, sometimes wrong code, so let your tests be the safety net. Turn it off when you are learning a concept, working in security-sensitive code, or when constant suggestions break your flow. Treat it as a fast junior whose work you always review, and it becomes one of the largest single productivity gains available to a developer.