Up to this point, GitHub Copilot has made suggestions and answered questions, and you have pasted every line yourself. In this lesson that relationship changes: in agent mode, on the command line and in the cloud agent, the tool helps decide which files it touches and which commands it runs. That saves manual steps, and it shifts the work: you write less, you review more. This lesson shows how to set this up so that you stay in control.
The course assumes W3.1.1 and W3.1.2: the forms of Copilot, the data flow and writing prompts with context. It does not repeat what K0 to K2 teach. The example stays the Kladde from K2.
A note on this course's honesty. Copilot changes quickly, and its answers are not predictable. No author of this lesson has run the exercises in an editor with Copilot: every surface and every command was read against the documentation, not run. Where a step is "not run against Copilot", it says so. The solutions therefore describe what you check, not what Copilot will answer.
| Module | Lesson | What you produce |
|---|---|---|
| W3.2 | W3.2.1 Agent mode, MCP and the command line | a small task for the agent, the same task through the CLI, a decision on MCP |
| W3.2 | W3.2.2 Instruction files, review and tests | an instruction file for the Kladde, generated tests assessed |
| W3.2 | W3.2.3 Privacy, exclusions and organization | an exclusion list and prompt rules for a team |
From suggestion to task
Inline suggestions and chat have one thing in common: the human takes over. A suggestion becomes code only if you accept it; a chat answer becomes a change only if you paste it. In its use-case cards, GitHub's documentation says that users bear all the risks of the generated code.
Agent mode hands some of these steps over. According to the documentation, in the editor it is simply called Agent; you choose it in the menu for the chat's mode (Visual Studio from 17.14, according to the page that was read). It decides for itself which files it changes, and it runs commands. By default: you approve the commands before they run. And every prompt uses up credit. This course gives no numbers on that; they change faster than it does. The question for your plan's documentation is: What does which usage consume?
| Inline suggestion | Chat | Agent mode | |
|---|---|---|---|
| Who decides what changes | you, per suggestion | you, when pasting | the agent, you see the result |
| Runs commands | no | no | yes, after your approval |
| Touches several files | no | only if you do it | yes |
| Where your review applies | to every line | to every answer | to commands and to the diff |
The last row is the core of the lesson. With the agent, there are two points at which you review: before a command (approval) and after the work (diff). Both are mandatory.
What it does and what it does not
An agent in the editor can do more than a chat, but it is not a colleague with responsibility. Remember three points that follow from what you have read:
- It works with the context it finds: open files, the repository, your instruction files (W3.2.2). What is not in the context,
it guesses. With a rule such as
appointment.time.overlapsin the Kladde, it can only follow it if it sees the code or the instruction for it. - It can be wrong, like any language model: it invents methods, overlooks edge cases, reports "done" although a test is red.
- It is not deterministic: the same task can turn out differently twice. That is why proof that you produce yourself belongs to it:
dotnet testand its exit code, not the agent's claim.
What the agent can do in detail depends on your editor's version and on your organization's settings. Read your editor's documentation before you make any promises to a team.