Ask - understand before you touch

There is a moment before every change in code you did not write: you can see the feature you need, but not how the codebase models it. What represents an order’s state? Is there already a concept of approval? Where do significant events get recorded? Editing before you can answer those questions is how the next bug gets introduced while fixing the current one. The Ask role exists for exactly that moment.

Read-only by guarantee

Ask is the read-only entry in the agents dropdown - the role picker in the Chat view. You ask questions about your code, and Copilot answers - explanations, traces, summaries - without modifying files: it can read and search, but it makes no edits and runs no commands. That guarantee is the whole point: in Ask there is no diff to review and nothing to undo, because nothing changed. (Role behavior as of September 2026; this surface reorganized during the year, so treat your build’s dropdown as ground truth.) Exploration cannot touch the code, so you can follow hunches, ask naive questions, and pull on threads you would not dare pull mid-edit.

That makes Ask the right opening move on unfamiliar code generally, and it is worth being deliberate about the questions. On an inherited order-management service, useful openings are concrete and pointed:

Where in this service is an order’s status managed, and what states can an order be in?

Is there any existing concept of approval, review, or a second person signing off on an action? Show me where.

When something important happens to an order, is it recorded anywhere - an audit log, an event, a history table?

Each question asks the agent to locate and explain, not to propose changes. You are building a map; the map is what you will edit against later.

What pointed questions uncover

The third question above matters more than it looks. Suppose the task is “orders above a threshold require a second approver.” That is not just an approval flag; a second-approver workflow has to be auditable, which means you need to know how this system records significant events before adding a new one. Ask traces it - and on this course’s inherited order service (orders-service), the answer points out of the service: the audit helper, and the validation that would enforce a threshold, live in shared-lib, a library a dozen services import.

That is exactly the discovery you want to make with a read-only assistant, before anything has been written. It reframes the job: the feature cannot be built cleanly in the service until the shared library can express “this order needs approval” and record it. One task has become two pieces of work with very different risk, and you found that out by asking, not by breaking something. On inherited code this is the norm, not the exception: the boundaries between modules are where the surprises live, and Ask is the cheapest way to find them.

Why start here, even when you are in a hurry

Ask can feel like the slow option when you want to ship. It is the opposite. Time spent understanding the terrain is recovered in edits you do not have to throw away because they fought the grain of the codebase. The rule of thumb on code you do not know yet, whether you wrote it or not: understand in Ask before you change in anything else.

Understanding is also some of the cheapest context you can buy for the agent. Everything it reads while answering your questions stays in that conversation - within the chat’s context window - so switching that same chat to the Agent role when it is time to edit starts from evidence rather than guesses. It is the same reasoning the Rules chapter makes permanent in files.

Once the shape of the problem is clear, the next move depends on how well you know the ground. If you already know exactly which files change and simply want the change kept small, that is a scoped edit in Agent mode. If the approach itself needs deciding before code exists, that is Plan.