Switch — match the mode to the risk

You’ve used all four modes on the approval feature: Ask to understand the inherited code, Edit for the scoped shared-lib change, Agent to build the workflow in orders-service, Plan to gate the risky library work. Each felt natural in context. This lesson makes the instinct explicit, because the instinct is the whole skill. Anyone can read four mode descriptions. What makes someone good with Copilot is glancing at a task and knowing, almost without thinking, which mode it wants.

The variable that decides is blast radius

Here’s the thing that surprises people: the mode you reach for is not chosen by how hard the task is. It’s chosen by how much damage a wrong answer does — the blast radius. A gnarly algorithm contained in one file you own is low blast radius even though it’s hard. A trivial signature tweak to a function a dozen services import is high blast radius even though it’s easy. The first wants Agent mode; the second wants Plan. Difficulty is a distraction. Reach for the question “if this goes wrong, who does it hurt, and how hard is it to undo?”

That’s why this course gave you two repos on purpose. They have the same engineer doing the same feature, but opposite risk profiles, and the modes you reached for flipped accordingly:

• orders-service — your squad’s own app, well-scoped, easy to fix forward. Low blast radius → you loosened up. Agent mode, let it build, review at the end.
• shared-lib — twelve consumers, a breaking change ripples outward, hard to walk back. High blast radius → you tightened up. Plan first or scope hard in Edit, review closely.

Same person, same week, opposite postures — set by what was at stake, not by what was difficult.

A rule of thumb

When a task lands and you’re unsure, walk down this ladder and stop at the first “yes”:

1. Do I actually understand this code yet? No → Ask. Never edit what you haven’t understood, especially on inherited code.
2. Is the approach itself risky — high blast radius, hard to undo, many consumers? Yes → Plan. Agree the approach before any code exists.
3. Do I already know exactly which files change, and want them and nothing else touched? Yes → Edit. Draw the fence, work inside it.
4. Is it well-scoped, lower-stakes, and I just want it built? Yes → Agent. Give the goal, watch the checkpoints, review the whole diff at the end.

It’s a ladder of latitude, and you climb it as your confidence rises within a single task: understand, agree the approach, then build. Because switching modes carries the conversation forward, moving up the rungs costs nothing — it’s one piece of work widening the agent’s leash as you get surer of the ground.

The judgment that carries past Copilot

Step back and notice what you actually practiced in this chapter. It wasn’t four features of a tool. It was a habit of matching autonomy to stakes — giving the agent a long leash where mistakes are cheap and a short one where they’re expensive. That’s not a Copilot trick. It’s the core discipline of working with any capable agent, and you’ll see the same judgment under different names in the Permissions chapter (how much it can run) and in every other course on this site.

There’s one piece this chapter kept deferring, though. Every time you wanted Copilot’s first draft to already match how a repo does things — the sort idiom in orders-service, the style of each shared-lib file — you had to say so by hand. That repetition is a signal. The fix is to write your team’s conventions down once, in a file Copilot reads on every request, so it stops guessing and starts conforming. And here’s the part that pays off if you’ve taken another course on this site: that file is one you may already have written. Next chapter: Rules — teaching Copilot your conventions.