The arc - and where to go next

That is the course. Before closing it, look back at the shape of what you did, because the shape is the actual lesson - not any one feature you learned to drive.

The arc, in one breath

You inherited two repos you did not write: an order service your squad owns, and a shared library a dozen other services lean on. The first real piece of work - an approval workflow for the service - turned out to need a change to the library first. So the job split into two halves with opposite risk, and the whole course was learning to feel that difference and respond to it.

You shipped a first tiny reviewed change before anything was at stake, so the loop - describe, read the diff, commit - ran once with nothing on the line. Then you met the three roles and the judgment they exist to serve: Ask to understand, Agent to hand off the whole task, Plan to gate the work where the approach is the risk - plus scoped edits as a technique inside Agent for when the files are already known. When first drafts kept missing how each repo does things, you stopped correcting by hand and wrote the conventions down once - the copilot-instructions.md, the AGENTS.md - so code arrived already passing review. You codified a repeated task as a prompt file (and learned it is deprecated), built a reviewer agent and fanned subagents across the consumers, packaged the repo’s audit-event logging convention as a portable skill, and reached an internal registry over MCP (the protocol for connecting external tools and data) to find who would break.

Then the trust dials. You tightened approvals on the library and loosened them on the app, spent stronger reasoning where the work was genuinely hard and routine reasoning where it was not, and handed a backlog of follow-ups to the cloud coding agent - issues assigned, pull requests returned for review, merges kept human. You confirmed almost none of it was tied to VS Code. And in the last lesson you watched all of it run together across a single day, the choices gone quiet.

The one thing to keep

If you forget every file path and setting name in this course, keep this:

Match autonomy to what a wrong answer costs, not to how hard the task is.

That is the spine the whole thing hangs on. The role you reach for, how much you let the agent run - none of that is set by how hard the task is. (How hard it thinks is the one dial where difficulty legitimately plays; the models lesson owns that call.) It is set by how much a wrong answer costs and how hard it is to undo. A gnarly algorithm alone in a file you own is hard but cheap to get wrong - long leash. A one-line signature tweak to a library a dozen services import is easy but expensive - short leash. The course gave you two repos for exactly this reason: same engineer, same feature, opposite postures, set by what was at stake and nothing else. Hold onto that and the specific buttons take care of themselves.

Why the work travels

Here is the part that pays off beyond Copilot. The most valuable thing you produced in this course was not any diff - it was the context you wrote down: the conventions in the rules files, the audit convention in a SKILL.md. And that context is not editor-shaped. It is repo-shaped.

That is the bridge. The same AGENTS.md can be read by Copilot, JetBrains, the cloud coding agent, and your other agents when each surface supports that file. If you also run Claude Code or Codex, they may read the same rules files and skills format. You did not write conventions only for Copilot; you wrote them for the repo, once, then verified which capable agents inherit them. Closing the context gap compounds across every tool you use, instead of being a tax you re-pay per editor.

Where to go from here

For the spec-level other half - Foundations. This course taught the practice: one scenario, each capability introduced exactly when the work demanded it. Foundations is the reference view - lookup-shaped and authoritative, the place to go when you need the full precedence rules for custom instructions or the comparative shape of custom agents across tools, rather than the slice the story needed. Same picture from the other side.

For your other tools - the sibling courses. Most engineers do not live in one agent, and what you just built carries. The Claude Code course and Codex course run on the same teach-by-doing spine, told in each tool’s idiom. The rules and skills you wrote here come with you: pick up either course already knowing the context work transfers. Learn the discipline once; carry it across all of them.

The whole job

Strip the tool away and every chapter taught one thing. Copilot is extraordinary at the general - broad, fast, fluent across languages - and blind to the particular: it does not know your codebase, your team’s conventions, or that the library has a dozen consumers who will feel a careless change. You are the inverse: slower, narrower, but you know all of that cold. Every move in this course was a way to hand the agent the context it was missing, and a way to decide how far to trust it once it had that context.

That is the discipline. Not a clever prompt, not a favorite role - closing the gap between what you know and what the agent knows, and matching the leash to what is at stake, on purpose, every time. You have the habit now. Go use it.