Skip to content

Course · Copilot · The modes

Scoped edits in Agent mode

Some changes are fully defined before they start. You know the two files involved, you know roughly what each needs, and the only question is getting the edit done cleanly without anything else shifting around it. You do not need an agent to discover the work - you need it to stay inside the work. In Copilot that is not a separate mode; it is a technique inside Agent, and this page is how to run it.

This is a standalone technique drill, not a change carried into the next lesson. If you apply it to a checkout, commit it on a disposable branch or restore the starting state before continuing. The Plan lesson deliberately starts from the unbuilt threshold-and-event task so you can review its approach before any code exists.

The mechanism is the request itself. Switch the agents dropdown in the Chat view to Agent and name both the files and the boundary:

Edit only src/validation/threshold.ts and src/audit/events.ts in shared-lib, the library other services import (about a dozen consumers). Add a function to the validation helper that returns whether an order amount is at or above a configurable approval threshold. Add a new event type to the audit helper for an approval being requested. Match the existing style of each file. Do not edit any other files.

Three parts of that request are doing real work. Naming the files tells Agent where the work lives, so it does not go hunting across a dozen importers. “Match the existing style” carries your conventions into the first draft - and is a preview of the Rules chapter, where you write that down once instead of repeating it. “Do not edit any other files” states the boundary in words.

Be honest about what that last sentence is: guidance, not enforcement. A named-file request shapes what the agent does, and it is usually followed, but it is still an instruction the model reads, not a fence the tool enforces. The enforcement side of Copilot lives elsewhere - permission levels and tool approvals, covered in the Permissions chapter. That split is the control principle in miniature: an instruction expresses a constraint, a permission enforces one. What makes a scoped edit dependable is the combination: a clearly bounded request, then a review that checks the boundary held.

Because you named the files, the review is unusually easy: the diff should be confined to files you can list from memory. On a shared library - code other services import - that check matters most, and three questions cover it:

  • Did it stay in scope? Files outside your list should not appear in the diff. If one does, that is the finding to look at first, before you judge any of the content.
  • Did it change a signature existing consumers depend on? Adding a new function is safe for existing consumers; altering one that a dozen services call is how a release breaks. Read specifically for it.
  • Does it match each file’s idiom? You asked it to. Confirm it did, or the edit will read as foreign at review time.

If something is off, do not start over - say so in the same conversation (“keep the existing event-naming style in events.ts”) and it revises.

A narrowly scoped request usually produces the edits and not the rest of Agent’s loop: it has no reason to run the test suite or check whether downstream consumers still compile unless you asked, so do not assume it did. On a small change you can do both yourself, and for a library change you should: run the tests, and search the consuming repos for imports of the changed symbols before you ship. When a task grows past the point where you want the agent to build, verify, and self-correct across as many files as it takes, the scoped technique has ended and the full handoff begins. Next: Agent - hand off the whole task.