GitHub Copilot & AI Coding Assistants

What this course covers

This course is about working with GitHub Copilot and similar AI coding assistants. You will set one up, judge its suggestions, steer it with comments and function signatures, and manage what it can see. This first lesson asks a simpler question. What does the tool do, and how far can you trust what it gives you?

Chapter 1 has four lessons. This one describes the tool and its limits. Later in this chapter you will see how suggestions are produced, how a team weighs adopting an assistant, and a checklist for reviewing each suggestion.

What an AI coding assistant does

An AI coding assistant is a tool inside your code editor. It suggests code, and it answers questions about code. GitHub Copilot is one example. It runs as an extension in editors such as Visual Studio Code and JetBrains IDEs.

You will meet it in two main ways.

• Inline suggestions. As you type, faded text appears ahead of your cursor. This is called ghost text. It might finish the line or offer a whole function. You press Tab to accept it, or keep typing to ignore it.
• Chat. You open a chat panel and ask in plain words. "What does this function do?" "Write a test for this." "Why does this line throw an error?" The assistant replies with an explanation, with code, or with both.

Copilot Chat also has an agent mode that can edit several files and run commands. This course starts with inline suggestions and chat.

In both modes the assistant is predicting. It writes the code that seems most likely to fit, based on patterns it learned from a large body of existing code and text. An inline suggestion is not run or tested before you see it. The next lesson explains this prediction step in more detail.

It works from your project, not from a search

A search engine finds pages that already exist. An assistant writes new code shaped by what is in front of it. That context includes the file you are editing and the code around your cursor. Depending on your editor and settings, it can also include other open files.

Names and comments are part of that context. A function called parse_invoice_date, with a comment saying it returns a date in UTC, gives the assistant far more to work with than a function called fn2.

This cuts both ways. Suggestions can match your style, your variable names and your imports. But the assistant sees only part of your project. It may not know about the helper function in another folder. It may not know your team's rule against building database queries by hand. It cannot know a business rule that lives only in a colleague's head. Where context is missing, it fills the gap with something that looks reasonable.

Where it helps

The assistant does its best work when the right answer is common and easy for you to check. Four kinds of work fit that description.

• Boilerplate. Data classes, config loading, request handlers and repeated mapping code. You know what the result should look like, and the assistant does the typing.
• Unfamiliar APIs. When you are new to a library, a suggestion shows you a likely call. You still confirm it in the library's own documentation.
• Tests. Ask for tests for a function and you get a first set of cases. Check that each assertion tests something real. Then add the edge cases it missed, such as an empty list or a missing value.
• Explaining code. Select a block you did not write and ask what it does. The answer is a fast first read. Check it against the code before you rely on it.

The common thread is that you can tell whether the output is right. When you cannot judge the answer yourself, the assistant's speed does not help you.

Where it misleads

The same prediction that makes suggestions fluent also makes their mistakes hard to spot. Four failure types are worth knowing by name.

• Plausible but wrong code. The code compiles and reads well, but the logic is off. Think of a loop that stops one item early, or a time zone that is ignored.
• Outdated APIs. The assistant learned from code written over many years. It may suggest a function that a library has since deprecated or removed.
• Security issues. Working code can still be unsafe. Examples include building a database query by pasting in user input, which allows SQL injection. Others are turning off HTTPS verification or writing a secret key into the code. Give sign-in, payments and file handling extra review.
• Licensing questions. A suggestion can closely match code in a public repository, and that code has a license. GitHub provides a setting that can block suggestions matching public code. Your organization may set a policy on it, so find out what it is.

The compiler does not catch these problems, and your editor flags only the ones a linter is set up to find. That is what makes them risky.

One more case is worth naming. When the assistant invents something that does not exist, such as a function, package or setting, that is called a hallucination.

A worked example: reviewing one suggestion

Illustrative example: a developer is adding a discount feature to an online shop's checkout service, written in Python. They type a comment that describes what they need. The assistant suggests the whole function, signature included.

# Return the price after a percentage discount (0 to 100).
def apply_discount(price: float, percent: float) -> float:
    return price - price * percent / 100

It reads well, and it runs. Now review it the way you would review a teammate's pull request. Ask what each input could be.

1. What if percent is 150? The price goes negative. The comment says 0 to 100, but the code does not check it.
2. Is a float right for money? The assistant chose float for the price. In Python, print(apply_discount(22.22, 10)) prints 19.997999999999998. The rest of this codebase stores prices as whole cents, which the assistant could not see from this file.
3. Is there an existing helper? A search of the project finds a shared rounding function for money. The team's rule is to use it for all prices.

The developer changes the function to take cents. It now rejects a percent below 0 or above 100, and it calls the shared helper. They add three tests: 0 percent, 100 percent, and 150 percent, which should raise an error. The suggestion saved some typing. The review is what made it correct.

A common misconception: it runs, so it is right

A new user may judge a suggestion by one test: does it compile, and does the normal case work? That test catches syntax errors. It misses wrong logic, missing edge cases and unsafe patterns, because all of those compile too. The discount function above passed that test.

A second form of the same mistake is the belief that the assistant knows your codebase. It knows what is in its context for this request. For inline suggestions, a helper in a file you have not opened may sit outside that context. Chat can search more of the project when you, or the mode you choose, ask it to. It can also read a repository's custom instructions file, if your team has written one. A rule that lives only in a team wiki stays outside unless you bring it in. Later chapters show how to give it more of what it needs.

Review every suggestion like a colleague's code

The working rule for this course is short. A suggestion gets the same review you would give code from a capable colleague who is new to your project. You would not merge their pull request because it looked tidy. You would read it, ask what it does at the edges, and run the tests.

One analogy helps here: a pair programmer who sits beside you and proposes code as you type. The analogy stops at accountability. A colleague can explain their reasoning and answer for it later. A suggestion has no author you can go back to. Once you accept it, it is your code.

In practice, review comes down to four questions.

• Do I understand every line?
• What happens with empty, missing, very large or invalid inputs?
• Does it follow this project's conventions and use our existing helpers?
• Is there anything here I would flag in a security review?

If you cannot answer the first question, hold off on accepting. Ask the chat to explain the code, or write that part yourself.

What to try this week

1. Pick a small task where you already know the right answer, such as a data class or a parsing function. Let the assistant draft it. Compare the draft with what you would have written.
2. Before you accept one suggestion, write down the inputs you tested. Note which ones you would have skipped.
3. Ask the chat to explain a block of code you did not write. Check its answer line by line, and note anything it got wrong.
4. Find out whether your team has a policy on AI-generated code and on the public-code setting. If there is none, ask who decides.

The next lesson looks inside the prediction step: what the model is doing when ghost text appears, and why that explains the failure types above.