GitHub Copilot Mastery — AI Pair Programming That Ships

Week 1 — meet the tool, get an account, and learn the screen before you learn the prompting.

1. Meet GitHub Copilot — what it is and who makes it

   GitHub Copilot is GitHub's coding assistant wired into your editor, your pull requests and your terminal. It is at its best at the work around the code — completing a line you already knew, explaining a function you did not write, and reviewing a change before a human reads it. It is at its weakest at the problem you have not described: it will generate plausible code for a misunderstood task, at speed, with confidence — and knowing both halves is what separates somebody who uses it well from somebody who trusts it blindly.

   The lesson

   GitHub Copilot is a coding assistant wired into your editor, your pull requests and your terminal made by GitHub. The models behind it are a choice of frontier models behind one subscription, selectable per conversation. None of that matters on its own — what matters is that you know what kind of worker you have hired. At the work around the code — completing a line you already knew, explaining a function you did not write, and reviewing a change before a human reads it is the job you hand it. At the problem you have not described: it will generate plausible code for a misunderstood task, at speed, with confidence is the job you keep.

   Most people come to a course like this expecting a list of magic words. There is no such list. What there is, is a tool that produces code, tests, explanations and review comments inside the editor you already use, and produces it at a speed no human matches — which means the skill is not in writing the prompt, it is in knowing what a good answer looks like so you can tell the difference.

   Here is the first thing to try, worded the way you will word things for the rest of the course:

   PromptCopy

   Review this function and tell me what is wrong with it, line by line. Do not rewrite it yet — just tell me what breaks and what input breaks it.

   Read the answer twice. The first read is for the content; the second is for the shape — did it answer the question you asked, or the question it found easiest? That second read is the habit this whole course is built on.

   Example A review before a rewrite: it forces you to understand the fault instead of accepting a fix you cannot explain.

   Practice Open GitHub Copilot, ask it the one question you would normally put to a search engine about your own field, and write down two things: whether the answer was right, and whether it would have taken you longer to find it yourself.

2. Signing in: what is free, what is paid, and what you actually need

   You do not need the paid plan to finish this course. Start on the free tier — a free tier for individual developers with a monthly allowance of completions and chats, plus free access for verified students. Upgrade only when you hit a wall you can name: a longer file, a newer model, or a rate limit you keep meeting.

   The lesson

   Every one of these tools has a free tier that is good enough to learn on and a paid tier that removes a limit. a paid individual plan raises the limits, and the business plans add the organisation-wide features. The mistake is buying the paid plan in week one, before you know which limit you hit — you end up paying to remove ceilings you were never going to touch.

   Work out your own honest usage first. How many questions a day do you actually ask? How big are the files you upload? Do you need the newest model, or the fast one? For revision, for drafting, for coursework, the answer is usually the free tier.

   If your college or workplace provides an account, use it: a GitHub organisation plan with policy controls and audit is how most people in a job get access, and asking your placement cell whether one exists costs nothing.

   Example Student verification gives a much larger allowance at no cost, and it is the first thing to sort out if you are on a degree.

   Practice Create the account, find the plan page, and write down in one line which limit you would hit first in your own week. It is usually a message cap or a file-size cap, not the model.

3. The screen: where every control lives

   A tour of the interface you will live in — grey ghost text in the editor as you type, an inline chat where you type in the code, a side chat panel, and comment-triggered actions inside a pull request. Every panel has a reason to exist, and half of them are the difference between a chat and a system.

   The lesson

   The interface of GitHub Copilot is grey ghost text in the editor as you type, an inline chat where you type in the code, a side chat panel, and comment-triggered actions inside a pull request. That sentence is worth slowing down on, because the single biggest cause of bad output is not a bad prompt — it is a good prompt typed into the wrong place.

   The history list is your memory of what worked. Name your conversations. The temporary or private mode is for anything you would not want in an account's history. The settings panel holds the personal instructions that apply to everything, which is where your context belongs rather than repeated at the top of every message.

   Do this once, properly: turn completions off for an hour and write one function by hand. Fluency in your own editor is the thing the tool is meant to speed up, not replace.. It takes fifteen minutes and saves you those fifteen minutes every week after.

   Example The ghost text is the part most people start with, and the pull-request review is the part that changes how a team works.

   Practice Spend fifteen minutes doing nothing but clicking. Open every panel, rename one conversation, and save one setting you will want again. Fluency with the screen is what stops you re-explaining yourself every session.

Week 2 — how GitHub Copilot reads text, the four-part prompt, your own work, and what to do when the answer is wrong.

1. How GitHub Copilot reads what you type

   Context, instructions and roles. The editor sends it your open files and the surrounding code, and the chat panel can be pointed at a specific file or selection. Understanding what the model can see — and what it has already forgotten — explains almost every disappointing answer you will get.

   The lesson

   The editor sends it your open files and the surrounding code, and the chat panel can be pointed at a specific file or selection. This is the machinery. A model does not remember your last conversation the way a person does; it is handed text and asked to continue it well. Everything you want it to know has to be in that text, in the same window.

   There is a difference between a system instruction — the standing context, set once — and a message, which is this request. Put your standing context in the standing place. "I am a final-year mechanical engineering student applying for data roles" belongs in your profile, not typed again at the start of every chat.

   And there is a hard limit. When a conversation gets long enough, the earliest turns fall out of view. Symptoms: it contradicts an instruction you gave ten messages ago, or forgets the file you uploaded. The fix is a new conversation with a written summary of where you got to, not a longer argument.

   Example Point the chat at a file before asking a question about it. Asking "why is this failing" with no context gives you a list of general reasons.

   Practice Ask the same question twice: once on its own, once after a short paragraph of setup about who you are and what you need. Compare the two answers and write down the difference. That gap is the thing you are learning to control.

2. The four-part prompt: role, task, context, format

   Almost every good prompt has four parts: who the model should be, what it must do, the facts it must use, and the shape of the answer you want. Leave out the fourth and you get an essay when you wanted a table.

   The lesson

   Write the four parts as four lines, in this order. ROLE: who it should answer as. TASK: the single thing you want done, as an instruction, not a wish. CONTEXT: the facts, pasted, not referred to. FORMAT: the exact shape of the answer — "a table with three columns", "five bullets, no more than twelve words each".

   FORMAT is the part everybody skips and the part that saves the most time. An answer you have to restructure by hand was not really an answer. Ask for the shape you are going to use: if it is going into a slide, ask for slide bullets; if it is going into a spreadsheet, ask for rows.

   Here is the same request done both ways — first as people usually write it, then in four parts:

   PromptCopy

   Weak:  tell me about data analyst jobs
   
   Strong:
   ROLE:    A hiring manager for entry-level analytics roles in India.
   TASK:    List what you screen for in a fresher's first 30 seconds.
   CONTEXT: I am a 2026 B.Com graduate with Excel, basic SQL and one
            dashboard project. No internship yet.
   FORMAT:  A table: skill | what a fresher shows | what most get wrong.
            Five rows maximum. No introduction.

   The second prompt is not longer because long is good. It is longer because it contains four things the model cannot guess, and the guess is where the useless answer came from.

   Example "Explain this function line by line, then show the smallest input that would break it" produces a far more useful answer than "what does this do".

   Practice Take a task you did last week without AI and write the prompt in four labelled lines. Then run it, and rewrite only the part that failed — not the whole prompt.

3. GitHub Copilot for the work you actually have

   Assignments, revision, email, applications, meeting notes. A function you half-remember, a test file for code you just wrote, a review comment on your own pull request before a human sees it. The test of a tool is whether it removes an hour from your week, not whether the demo looked clever.

   The lesson

   The highest-value use of GitHub Copilot for a student or a fresher is not writing essays. It is compression: turning a 40-page chapter into the six things you actually have to remember, turning a messy set of notes into a revision sheet, turning a job description into a list of what to prove.

   The second highest is structure: given a blank page, ask for three possible outlines and pick one. Being stuck is usually a problem of options, not of effort.

   Here is a prompt worth keeping verbatim — it is the one that turns a document into something you can study:

   PromptCopy

   Here is my function: [paste]
   
   Write tests for it in [framework].
   Include:
   - the normal case
   - an empty input
   - the input that breaks it, and say what happens when it does
   - one test that documents a decision I made, not a bug
   
   Then list any behaviour in my function you are unsure about, rather
   than assuming it is correct.

   Notice the last line. Asking for the gaps is asking the tool to mark its own work, and it is the single most useful line you can add to a study prompt: the material it could not summarise is the material you have not understood yet.

   Example Give it a function and ask for the tests you would write, including the input that breaks it.

   Practice Pick the one task you repeat every week — the one that is boring rather than hard — and rebuild it in GitHub Copilot today. Time it. Then keep the prompt that worked, saved and named.

4. When the answer is wrong: iterate instead of restarting

   A bad answer is information. It fails by being confidently wrong about the task rather than the syntax — plausible code that solves a slightly different problem. Keep the conversation, name the fault, and correct one thing at a time — restarting from scratch throws away everything the model has already got right.

   The lesson

   There are four things that usually went wrong, and each has a different fix. It answered a different question — restate the TASK as one sentence. It made things up — supply the facts yourself and say "use only these". It wrote too much — ask for the length first. It sounded like a machine — ask it to rewrite for one specific reader and cut every third word.

   Say the fault out loud, in the message. "This is too long for a WhatsApp message and it sounds like a brochure." A model cannot fix a problem you have not named, and naming the problem is also how you find out what you actually wanted.

   Follow-ups that work: "shorter", "only the parts that are true for a fresher", "rewrite the second sentence three ways", "what would you have to check before I send this?". That last one is worth using before anything goes out with your name on it.

   Example If the generated code is subtly wrong, the fault is usually in your description. Say what the function must do in one sentence, and what it must not do.

   Practice Take the worst answer you have received this week and correct it in three follow-up messages without retyping the original prompt. Notice how much faster it converges.

Week 3 — documents and tables, Pull-request review, inline chat and the test-first loop, the API, and one boring task automated.

1. Files, tables and long documents

   Uploading a PDF, a spreadsheet or a screenshot and asking questions about it: It reads the files in your workspace, so it can follow an import, a type or a naming convention that only exists in your project. This is where these tools stop being a chat and start being work, and where the failure modes are worth knowing.

   The lesson

   It reads the files in your workspace, so it can follow an import, a type or a naming convention that only exists in your project. The two failures to expect are the ones nobody warns you about: a long document is summarised as it is read, so a detail on page 60 can be missed; and a table with merged cells or a scanned page is likely to be read wrongly.

   So the working method is: ask narrow questions, and ask the tool to quote the line it is answering from. "From the attached file only, what does clause 4.2 let me do? Quote the sentence." If it cannot quote it, it did not read it.

   For a spreadsheet, ask for the formula and an explanation instead of the computed column — ask it to explain the type of every value before changing the expression — then you can fix it yourself next month when the columns change.

   Example Ask it to add a function to a service and it will match the patterns in the neighbouring file — which is why a tidy repository produces better suggestions.

   Practice Upload one real document you already own — a syllabus, a marksheet, a project report — and ask three questions whose answers you already know. When it gets one wrong, read the passage it quoted before you blame the file.

2. Pull-request review, inline chat and the test-first loop — GitHub Copilot's own feature

   Copilot is not only an autocomplete. It reviews a pull request and leaves comments, it answers a question inside the code you have selected, and it writes the test you were about to skip — which together cover the parts of the job a junior developer is actually paid for.

   The lesson

   Because the slowest part of a junior developer's week is not typing — it is waiting for review, and re-reading your own change with fresh eyes. A reviewer that never gets tired is the highest-value use of this tool, and it is the one that survives code review policies at most companies.

   Write the code, then ask for a review before you ask a person. Read every comment and either fix it or decide why it is wrong. Then write the test it asked for. Never merge on the strength of a green check from a tool — a passing test you did not read is not evidence.

   Here is the shape of it, in the form you will actually use:

   Plain textCopy

   // A function with three problems. Ask Copilot to review it, not to fix it.
   function averageScore(scores) {
     let total = 0;
     for (let i = 0; i <= scores.length; i++) {
       total += scores[i];
     }
     return total / scores.length;
   }
   
   // Ask for: (1) a review comment on each line that is wrong,
   //           (2) the input that produces NaN,
   //           (3) a rewritten version with the reason for each change.

   The mistake is accepting a suggestion that compiles, passes the build and is wrong. Generated code is easiest to accept exactly where checking it matters most: the loop boundary, the null case, the off-by-one.

   Example A pull request you opened ten minutes ago already has three review comments on it, one of which is about an edge case you missed.

   Practice Open a real pull request of your own, run the review on it, and fix everything it finds before a human looks. Then note which comments were useful and which were noise.

3. The Copilot API and the models behind it and your first script

   Copilot is a product rather than a raw model endpoint; the same capability is reachable through the GitHub platform APIs, and the underlying models through their own providers. You do not need this to finish the course, and you do not need it for a fresher job either — but an afternoon here is what turns "I have used GitHub Copilot" into "I have built with it", which is a different sentence in an interview.

   The lesson

   Copilot is a product rather than a raw model endpoint; the same capability is reachable through the GitHub platform APIs, and the underlying models through their own providers. The idea is simple: the same model you have been chatting with also answers a web request, so you can put it inside a script, a spreadsheet or a page. A key identifies you; a request sends the text; a response comes back as data.

   The reason to try it once, even if you never build anything: it makes the chat version less mysterious. You see that the whole conversation is text in and text out, that your instructions are literally lines of a request, and that "the model" is one parameter among several.

   A first call looks like this:

   TerminalCopy

   # Ask Copilot from a terminal (the GitHub CLI extension):
   #   gh extension install github/gh-copilot
   
   gh copilot suggest "list every file modified in the last commit"
   gh copilot explain "git reset --soft HEAD~1"
   
   # The rule this teaches: a command you cannot explain is a command you
   # should ask about before you run it, especially anything that changes history.

   The mistake is running an AI-suggested command that rewrites history or deletes a branch without reading it. Ask it to explain the command first; a destructive command explained is still destructive.

   Example A script that posts an AI summary of a pull-request diff as a comment is a realistic automation, and it is the kind of small tooling a fresher can build and point at.

   Practice Get a key, run one request that works, and change one word in it to see the answer change. That is the whole of the first afternoon.

4. Automate one boring task with GitHub Copilot

   Automation is not about building a system. It is about doing one repetitive job the same way every time, in less time than last time, and being able to do it again next month.

   The lesson

   Pick the task by how often it happens, not by how impressive it would be. A weekly report you can half-generate beats a clever pipeline you build once and never open again.

   Generating the test file for every new function, or drafting the pull-request description from the diff.. Whatever you choose, write the steps back out in plain English afterwards — "Step 1, open the sheet, Step 2, paste the names —" because the written steps are what you follow when the tool changes next quarter.

   And keep a copy of the prompt next to the task. A prompt that lives only in your chat history is a prompt you will rewrite from scratch in March.

   Example A pull-request template that starts with the summary the assistant generated, which you then correct, saves the five minutes you spend staring at a blank box.

   Practice Name the task you repeat most often that involves typing, then write the prompt for it and run it three weeks in a row from the same saved place. Three runs is the point at which you know whether it is genuinely automated.

Week 4 — a finished portfolio project, the privacy rules, the limits, and the GitHub certification paths.

1. Build the portfolio project: one reviewed, tested, merged project on GitHub

   Take a small project — a script, a small app, a data tool — and take it all the way: issues, a branch, tests, a pull request reviewed by the tool, and a merge. The process is the project. It is the thing you will talk about in the interview, so it has to be small enough to finish in a fortnight and concrete enough to show a person in one minute.

   The lesson

   Take a small project — a script, a small app, a data tool — and take it all the way: issues, a branch, tests, a pull request reviewed by the tool, and a merge. The process is the project. Finish it before you start the next one. A half-built idea shows nothing; a small finished thing shows that you can finish.

   Use the tool as a collaborator, not an author: ask it for a plan, a critique and a checklist, and write the work yourself. In the interview the questions will be about the decisions — why this, why not that — and only the work you did yourself has answers.

   Write one paragraph beside the project: what problem it solves, what you used, and what you would do differently next time. That paragraph is the interview.

   Example Finished, it is a repository with real commit history, tests that run, and a merged pull request with review comments you answered.

   Practice Walk somebody through the pull request and why you made each change. The interview question is never "what did it do" — it is "why did you do it that way".

2. Ethics, privacy and what never to paste

   These tools send what you type to somebody else's computer and keep it in a history. Never paste passwords, government ID numbers, bank or card details, medical records, or another person's private data — and never paste a company's confidential document.

   The lesson

   There is no version of this tool where your text stays on your laptop. Everything you type is sent to a server, kept in a history you can usually see, and may be reviewed or used to improve the product depending on the plan.

   Never commit a key, and never paste a customer's data into a chat to debug it. If your project has a .env file, it belongs in .gitignore before you install anything, not after the first accidental push.

   The practical rule for a fresher: replace the real thing with a stand-in. "Client A", "my friend's phone number", "the amount in the offer letter". The tool rarely needs the real value to do the work, and the stand-in costs you nothing.

   And the professional rule: on a work repository, assume the assistant's suggestions are covered by your employer's policy, and read that policy before you paste anything in. If your employer has an approved plan or a policy, that policy is the answer, not your judgement about how sensitive a file really is.

   Example A coding assistant reads your repository, and a repository is where credentials, customer data and unpublished business logic live.

   Practice Go through your last five conversations and delete anything containing a real phone number, a client name, or a document you did not write. If you cannot find the delete button, that is the lesson.

3. Limits, hallucinations and how to check

   These tools predict plausible text. It is trained on code that exists, which means it will confidently reproduce a deprecated pattern it has seen a thousand times That is a mechanism, not a moral failing — and the habit it demands is the habit of asking "where did this come from?" out loud, every time, before you use an answer.

   The lesson

   A model does not look things up unless it has been given a way to look things up, and even then it can attach a real number to the wrong claim. It is trained on code that exists, which means it will confidently reproduce a deprecated pattern it has seen a thousand times

   So the rule is: numbers, dates, names, citations and legal or medical claims get checked in a primary source before they leave your hands. Everything else — drafts, structure, explanations, practice — is fair game.

   Three questions to ask before you trust an answer. Where did this come from? What would make it false? Who is the original source, and can I open it? If the third one has no answer, you have writing material, not facts.

   Run it, test it, and read the boundary condition yourself. Tests you did not read are decoration.

   Example Ask for an authentication flow and read the version it suggests. You will often see an approach that was standard three years ago and has a known flaw now.

   Practice Ask for one statistic with its source, then open the source. Sometimes it exists. Sometimes the citation is invented, and the number is close enough to a real one to be dangerous. Either way you will remember the exercise.

4. Get certified: the official GitHub paths

   A Way2Fresher certificate for this course is free and lives on this site. Beyond it, GitHub publishes its own learning and certification material — and the rail on this course page links to it.

   The lesson

   There are two things called a certificate and they are not the same. The one this site issues records that you finished a structured course and built the project at the end of it — it is free, and it is yours to print. The ones GitHub issues record that you passed their own material.

   GitHub publishes free learning paths through GitHub Skills and Microsoft Learn, including a Copilot-specific path and GitHub Foundations, and the foundational certification is recognised by employers. Student accounts also unlock the larger assistant allowance for free.

   Get both, in that order. The project is what an interviewer asks about; the certificate is what gets past a filter that looks for keywords. The links to the official paths are in the rail beside this lesson, each labelled with who issues it.

   And put the work on the certificate, not the other way round: a certificate with no project behind it is a line on a resume, and it lasts exactly until the first technical question.

   Example Being able to explain a pull request you wrote, and why, is the whole interview. The tool helps you get there; it does not answer for you.

   Practice Finish every lesson here, take your Way2Fresher certificate, then open one official path and work through it with the project you have already built. Being certified in the tool you can already use is a small additional step.