Plan — see the plan first

Agent mode built the feature in orders-service by choosing its own approach and running with it — and that was fine, because in your own service a wrong turn is cheap to fix. Now imagine the harder version of the same task: the part of the approval feature that touched shared-lib, the library a dozen services depend on. There, the approach is the risk. Picking the wrong shape for a shared function isn’t a bug you patch later — it’s a breaking change a dozen teams inherit. For work like that, you want to see the plan before a line of code exists. That’s Plan mode.

What Plan mode is

Plan mode produces a structured, step-by-step implementation plan up front, and stops there — no edits yet. You get the agent’s intended approach laid out as something you can read, push back on, and approve before it commits to it. Copilot has a first-class plan surface for this; it’s a clean parallel to plan-first workflows you may know from the CLI agents, and it exists because some decisions are far cheaper to change while they’re still a paragraph than after they’re a diff across fifteen files.

The value isn’t the plan document. It’s the review point it creates at the moment decisions are cheapest to change. Catching “you’re about to alter a function twelve services call — add a new one instead” while it’s a bullet point costs you a sentence. Catching it after Agent mode has woven that change through the codebase costs you an afternoon and a lot of re-review.

Using it on the risky change

Think back to the shared-lib work. Instead of scoping it tightly in Edit mode (which you did) or letting Agent mode loose on it (which you wouldn’t), Plan mode offers a third path for when a shared-library change is big enough to need a strategy:

Plan how to add a configurable approval threshold and an approval-event type to shared-lib without breaking existing consumers. I want to review the approach before any code changes.

What comes back is an approach you can interrogate before it’s real:

• Does it preserve compatibility? Is it adding new surface or changing existing surface the consumers depend on? This is the question the whole plan lives or dies by, and it’s right there in plain language before any risk is taken.
• Is the sequencing sane? Library change, then version bump, then consumer adoption — in an order that never leaves the dozen services broken in between?
• Did it miss anything? A migration note, a config default, the consumers that need updating. Easier to add a step now than to discover the gap mid-build.

You read it, you push back where it’s wrong, and only when the approach is right do you let it proceed — handing the approved plan to Agent mode to execute, with the context carrying straight over.

Plan as the front of the autonomy ladder

Plan mode reframes the other three. Ask understands, Edit changes what you scoped, Agent builds autonomously — and Plan sits in front of Agent as the gate for when autonomous building is the right call but the approach is too consequential to leave unreviewed. The rhythm that emerges on serious work is: Ask to understand → Plan to agree the approach → Agent to build it. Three modes, one continuous piece of work, latitude widening only as your confidence does — and because switching modes carries the context forward, it really is one conversation, not three.

You’ve now met all four modes on the parts of the job that fit them. Which leaves the actual skill — the one this whole chapter was building toward. It isn’t knowing what each mode does. It’s knowing, when a task lands on your desk, which one it’s asking for. Next: Switch — match the mode to the risk.