How do you use GitHub Copilot well?

GitHub Copilot, now in technical preview as a Visual Studio Code extension, reads the code and comments around your cursor and proposes the next line or a whole function. Developers who get good results from it tend to do two things differently. They feed it better context, and they review its output with the same care they would give a stranger's pull request.

Both habits follow from how the tool works. Copilot runs on Codex, an OpenAI model trained on public code that continues whatever pattern it sees. It has no idea what your project is for. Everything it knows about your intent comes from the text in the file you are editing.

Give it context it can use

GitHub's FAQ says Copilot works best when code is divided into small functions with meaningful parameter names and good docstrings and comments. That advice is worth taking literally:

• Name things for what they mean. A function called parse_invoice_total(text) tells the model far more than process(s).
• Write the comment first. Describe inputs, outputs and the awkward cases, such as empty input, ties or invalid values.
• Keep related definitions in the same file. Copilot uses only the current file, and long files are trimmed to the few hundred lines before the cursor. GitHub notes that pasting a type declaration into the file you are working on can improve suggestions.
• Work in small steps. Ask for one function at a time. The Codex paper found the model struggles when a description strings many operations together.

Steer, compare and stay in charge

Copilot does not force anything on you. Press Tab to accept a suggestion, keep typing to ignore it, or cycle through alternatives (on a Mac, Option-] and Option-[ move to the next and previous ones). Looking at two or three options is often the fastest way to spot a weak one, because their differences show where the model was unsure.

If a suggestion is close but not right, edit it rather than starting over. The product page says Copilot adapts to the edits you make and picks up your style as you go.

A worked example: comment, suggestion, test

Suppose you need a function that turns a duration such as "1h30m" into minutes. Start with a precise comment and signature:

# Convert a duration string like "1h30m", "45m" or "2h" into total minutes.
# Hours and minutes are optional, but at least one must be present.
# Raise ValueError for empty or malformed input such as "abc" or "1x".
def duration_to_minutes(text: str) -> int:

Copilot will typically offer a body, perhaps a regular expression that captures hours and minutes. Before accepting it, read it with three questions in mind:

1. Does it handle every case in the comment? Check "2h" with no minutes and "45m" with no hours.
2. What happens with bad input? Many quick solutions return 0 for "abc" instead of raising an error.
3. Does it use anything you don't recognize? Look up any unfamiliar library call; GitHub warns that suggestions can rely on outdated ones.

Then write a test. You can ask Copilot to draft one too, since GitHub lists test suggestions among its uses, but decide the cases yourself:

import pytest

def test_duration_to_minutes():
    assert duration_to_minutes("1h30m") == 90
    assert duration_to_minutes("45m") == 45
    assert duration_to_minutes("2h") == 120
    for bad in ["", "abc", "1x", "h"]:
        with pytest.raises(ValueError):
            duration_to_minutes(bad)

If the test fails, you have found the gap between what you asked for and what you got. Fix the code, or improve the comment and ask again.

How do you check code you didn't write?

Read it before you run it, and run it before you trust it. Start by explaining the code to yourself line by line, or out loud. Any line you cannot explain is a line you do not yet understand, and a good place for a bug to hide. Copilot does not test its suggestions, and GitHub says plainly that they may not compile or work.

Next, test behavior rather than appearance. Write cases for the normal path, the edges (empty input, zero, very large values) and invalid input. The Codex paper's main benchmark exists for this reason: generated code that looks correct often fails when it actually runs. Keep these tests in your project so they protect the code after you change it.

Finally, check what tests rarely catch. GitHub points out that public code contains insecure patterns that Copilot can repeat, so look closely at anything that touches user input, files, passwords or databases, and use the security tools you would use for any code. Watch for invented-looking email addresses or keys, which the model can produce from patterns. GitHub also estimates that about 0.1% of suggestions include snippets copied word for word from its training code, so if a suggestion looks like a well-known block of code, find out where it comes from before you ship it. The code you accept becomes your code, and so does the responsibility for it.