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.

Two questions decide how much leash a task earns - neither of them is “how hard is it.” Set both for the work in front of you and read the rung it lands on.

If the agent’s worst single action went wrong, undoing it would take…

a git checkoutthe change lives in tracked files; the floor holdsreal worka migrated database, regenerated files, a rebased brancha miraclea send, a deploy, a delete with no backup

…and its consequences would reach

your working copyone repo, one machine, nobody downstreamwhat the team sharesa library others consume, common infra, shared databeyond the machineproduction, customers, money, the public

1. Run free, no fencedisposable environments onlyNothing pauses it and nothing contains it. No combination on this dial lands here - it belongs only where the whole environment is disposable: a throwaway container, an already-isolated CI runner.
2. Run free inside a fencethis taskNo prompts; the boundary does the protecting. The agent grinds end to end inside a sandbox, container, or scratch worktree, and you review the whole batch once at the end.
3. Auto-apply edits, gate the rest
4. Ask before acting
5. Read & propose only

A mechanical rename across your own repo is the canonical case: the worst outcome is a git diff you throw away. Prompting on every one of twenty-four identical edits doesn’t add safety - it teaches you to stop reading prompts, which is where real risk starts. Let it run inside the fence and review the batch once.

The rung names are generic on purpose - every tool spells its own versions of them, and most let you set different rungs for different categories of action. The judgment underneath is the same two questions, asked per task, never answered once for all time.

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.