Mastering Coding Agents with GitHub Copilot

Duration: 1 Day Skills Gained

By the end of this course, participants will be able to:

• Write a task the assistant can plan, edit, and stop

• Reject a plan before any file changes

• Drive one multi-file change that has tests and a diff a reviewer can read

• Spot the defects that make these changes expensive: extra files, invented helpers, a quiet behavior change

• Write the team rule for when this mode is allowed

Who Can Benefit

This course is designed for:

• Developers who already use Copilot completions or chat and want changes that survive review

• Tech leads setting the review standard for assistant-authored work

Prerequisites

Participants should enter this course with:

• Daily use of Git and a pull-request workflow

• Working use of Copilot chat or completions, or an equivalent coding assistant

• Ability to run tests in a repository provided in class. Production code stays at home

Organizational Objectives

This course assists organizations to:

• Raise the share of assistant-authored changes that pass review the first time

• Stop unscoped edits before they reach a reviewer

• Give tech leads one rule, so the practice does not fork by team

Software

A modern browser and an internet connection. Preferred: GitHub Copilot in the lab environment we provide. If that license is not in the room, a coding sandbox, with each step mapped to Copilot. The sample repository is supplied. No production access required.

Module 1 — A Task the Assistant Can Finish

By the end of this module, you will be able to choose completion, chat, or file-editing mode, and say what each may change.

• Completions suggest the next line. Chat answers. Agent mode proposes file edits you accept or reject

• What it can see: open files, the repository, and an instructions file if you wrote one

• What you give it: the goal, the limits, and what done means

• A vague ticket produces a vague plan

Hands-on Lab: Rewrite three vague tickets into task cards on the sample repository. Compare the plans. No edits are accepted yet.

Module 2 — Plan, Then Allow the Edit

By the end of this module, you will be able to reject a bad plan and bound the files in play.

• Ask for the plan first

• An instructions file: the conventions the assistant must follow

• Files it may touch, files it may not, and interfaces that must not change

• A plan you cannot explain is a plan you reject

Hands-on Lab: On the sample repository, accept or reject the plan before any edit lands. Then run one bounded change.

Module 3 — Prove It in the Diff

By the end of this module, you will be able to make the change prove itself, and to read the diff a reviewer will see.

• Tests are the contract. The assistant runs them

• In the diff: invented helpers, a quiet behavior change, a new dependency

• On failure: feed the error back, cap the retries, then a person takes it

• The pull-request note is written for the reviewer, not for the chat

Hands-on Lab: Break the sample on purpose. Drive a fix. Write the pull-request description a reviewer can audit without opening the chat.

Module 4 — The Team Rule

By the end of this module, you will be able to say when this mode is in bounds for your team.

• In bounds: a chore, a test, a localized change with a clear done

• Out of bounds: authentication, a migration, a change you cannot state

• Review stays with a person

• What to watch: review rounds and reverts, not lines generated

Hands-on Lab: Write a one-page team rule for when the assistant may edit files.