Your first reviewed change

Time to fix the bug. The task: the “recent orders” endpoint in orders-service, the course’s illustrative order-management API your squad owns, returns its list oldest-first when the UI wants newest-first. You can describe it precisely, you can verify the fix by eye, and it touches almost nothing - the ideal first thing to hand an agent on a repo you do not yet trust. (No inherited repo of your own? The course overview lists substitutions; any small, verifiable bug in a repo you own works.) The change matters less than the loop you are about to run, because that loop - describe, review, verify, commit - is the spine of everything that follows.

Describe the bug, don’t prescribe the fix

Open the Chat view (if it is not set up yet, Setup covers it), leave the agents dropdown - the picker at the chat input - at its default for now; you will meet it properly in the next chapter. Tell Copilot what is wrong in terms of behavior, not implementation:

The recent-orders endpoint returns orders oldest-first, but they should come back newest-first. Find where that list is built and fix the ordering.

Notice what that request does and does not do. It describes the symptom (“oldest-first, should be newest-first”) and points at roughly where to look (“where that list is built”), but it does not say how - no file name, no sort call, no comparator. On code you do not know well, that is deliberate. You are letting Copilot do the part it is genuinely better at than you right now - finding the relevant code in an unfamiliar repo - while you stay the judge of whether its answer is right.

Copilot reads the project, locates the endpoint, and comes back with a proposed change: usually a one-line fix to a sort, plus an explanation of what it found and why that is the cause. The change arrives as a proposed diff in the chat - something you accept or reject, not a silent edit. How much latitude the chat had in producing it is exactly what the next chapter is about; for now, all you need is the reviewing part.

Read the diff before you accept it

This is the habit. Copilot presents its change as a reviewable diff, and the discipline of working with an agent is that you read that diff before accepting it. For a one-line sort fix this feels ceremonial. Do it anyway, because the muscle being built here is the one that protects you when the change is forty lines across six files and you are tempted to skim.

Three checks, every time, scaling from one line to a whole branch:

1. Did it change what you asked - and only that? A one-line ordering fix should be a one-line diff. If Copilot also “helpfully” reformatted the file or renamed a variable, that is scope creep to catch now, not in code review.
2. Is the fix actually correct? Read the sort direction. Does newest-first mean descending by timestamp here, or is “recent” defined some other way in this codebase? You are verifying its reasoning, not just trusting that it ran.
3. Does it match how this repo does things? If the surrounding code sorts one way and the fix introduces a different idiom, that is a smell - and a preview of why the Rules chapter exists, where you write the conventions down so the first draft already fits.

If it is right, accept it. If something is off, do not start over - say so in the same conversation (“keep the existing sort helper, just reverse the direction”) and Copilot revises. That back-and-forth is the tool working as intended.

Verify, then commit

Accepting the diff changes files on disk; it does not make the fix true. Run the endpoint, or its test, and confirm the list comes back newest-first against output you can read. Then commit it yourself.

That last part is worth stating plainly: in this surface (a surface being one place the same assistant reaches you - completions, chat, GitHub), with the latitude you have here - a proposed diff you accept - you stage and commit; making the change permanent is a human keystroke. Later chapters hand the agent more latitude, and even at the longest leash a human still merges. Later in the course you will meet a surface where Copilot opens a pull request on its own - and even there the work lands on its own branch for your review, and the merge is yours (per the cloud agent documentation, as of September 2026). The shape is the same at every scale: Copilot proposes, you decide.

Try it

Open the Chat view in your own repo and describe a small bug - a wrong default, a misnamed field, anything verifiable in thirty seconds. Before accepting, read the diff against the three checks above. If anything surprises you, do not just reject it; ask Copilot to explain that specific change and judge whether the reasoning holds.

That loop does not change for the rest of the course. What changes is how much latitude Copilot gets to run it - how much it may edit and execute before you look. That latitude is set by the roles in the agents dropdown, and choosing the right one for the task in front of you is the skill of the next chapter. Next chapter: the modes.