Using a VSCode AI agent: agent mode, rights and evidence

The extension is in place; the question is what happens when you switch to “agent”. This page is for the technical lead, and for the executive who arbitrates, deciding what a team hands to an AI agent in VS Code, with which rights and against which evidence.

It settles four points: agent, chat or completion depending on the task; the frame of a session; what the agent never touches; the indicators that tell you whether time is saved. The general method is the one used to create an AI agent.

Using an AI agent in VS Code: agent, chat or completion

Three tools live side by side in the editor under the same name of “AI”. Completion writes on from your keystrokes. Chat explains, proposes, answers. Agent mode, GitHub Copilot's for example, takes a high-level objective and runs it in several steps. The difference is one of surface, not power: the first touches a line, the last a repository.

Autonomy, tools, sessions, multi-file: what “agent” means in VS Code

An agent in a development environment is not a “chat that codes”: four properties separate it from the rest.

• Autonomy: it chains actions without asking for permission again at every step.
• Tools: it does not only produce text, it reads files, runs tests, calls a terminal.
• Sessions: its work has a start, an end and a state you can inspect.
• Multi-file: it acts on a coherent set, not on the open file.

The agent runs a loop: it acts, observes the result (tests, static analysis, logs), then starts again. These properties vary by extension and by mode: check them one by one, and read the list of sessions before judging.

The table below sums up what each mode does and what it is checked against; these tiers map onto the four permission levels of an AI agent in the pillar, which also classifies the seven families of agents.

When a simple assistant is enough, and when the agent becomes useful

An assistant is enough when you already know what to change in a function, a query or a test. An agent becomes useful as soon as the task crosses the project: long tasks, refactorings spread over several modules, migration of an interface, writing and running tests. The tipping criterion is not difficulty, it is the number of places to touch before the task is finished.

The agent sits mainly between the specification and the code: it turns an intention into a plan, then into verifiable changes. It also serves downstream, for review and runbooks. The agent speeds up execution; product responsibility and quality stay human.

Running an agent session

An agent performs well when you feed it like a contributor new to the project. A badly opened session cannot be rescued along the way: it produces a large diff to review in full, or to accept out of fatigue.

The frame to write before the first change

The frame is carried over from one session to the next. The project context stops the agent inventing the house rules; the definition of done says how you will know it is finished.

• Objective: the result expected on the user side, not the way to get there.
• Constraints: technical frame, versions, style, performance and security expectations.
• Acceptance criteria: tests that have to pass, expected behaviour, edge cases covered.
• Sequence: a plan before writing, then implementation in steps, each one verifiable.

A colleague who does not know the task should be able to say, on reading the criteria, whether an output is compliant; otherwise, the agent does not know where to stop.

Setting autonomy by the risk and the complexity of the task

The setting depends on two variables, for every task. The surface of change: more files touched, less autonomy and more validations. Risk: an area covered by solid tests tolerates a wide run, an area with no tests tolerates none.

At the level of the session itself, four guardrails are set.

• Read-only first: the first pass produces an analysis and a plan, never a write.
• Dedicated branch: the agent works alongside, with atomic, reversible commits. The branch isolates the history, nothing more: not access to the files on the machine, not the commands, not what goes out in the context.
• Systematic review of the diff: no unexplained change is accepted.
• Stop conditions: if a test fails twice in a row, the agent stops and asks for clarification instead of attempting a third fix.

What an agent must not touch in your repository

The list of prohibitions has three characteristics, and the first is the most important.

• Written before the first session, not at the moment the agent asks for permission: at that instant, you want the task to move forward, and you approve. That is how a scope is lost.
• Short: it fits in the repository's instruction file and is reviewed as a team.
• In two halves: what the agent may not change, and what it may not read.

An instruction file is an instruction addressed to the model, not a technical barrier: it stops neither the reading of a secrets file on the disk, nor a command outside the repository. What does stop things belongs to the system.

• The rights of the account running the agent, reduced to what the task requires.
• Secrets taken off the machine and placed in a vault.
• Mandatory approval of terminal commands.
• An isolated execution environment.

Instructions reduce how often deviations happen, barriers reduce their reach: you need both.

Files, secrets, dependencies and commands

The file scope is declared positively: the folders the agent may write in, and nothing else. An exclusion list is forgotten at the first new file; an inclusion list is not, if a mechanism enforces it. Excluded by default are the environment files and anything holding a secret, staging and production configurations, migrations already applied and generated artefacts.

Four other rules cover what the diff does not show.

• Dependencies: the agent proposes an addition, it never installs one on its own. A dependency enters the project through a human decision.
• Running commands: allowed on verification commands (tests, formatting, static analysis), subject to explicit approval for the rest, never on a command that reaches a system outside the workstation.
• Writing outside the repository: forbidden without exception, and blocked by the execution environment rather than by an instruction. An agent that changes your global configuration produces a change the diff will never show.
• History and protected branches: no history rewriting, no action on the main branch. The work comes out as a proposal and is reviewed before it goes in.

The context that stays on the machine

The second half of the list concerns reading, the easiest to forget: it leaves no trace in the repository. An agent that runs in your editor is not for that reason a local agent: most often, it runs on your machine and calls a remote model to which it sends its context.

Unless a model is installed on your machine, every step therefore transmits to a remote service what it has read: code extracts, paths, command outputs, error messages. Opening the context wide “so the agent understands better” sends data off your machine. Give the minimum sufficient context, not the whole repository; four categories stay outside.

• Secrets and environment files.
• Personal data and customer datasets.
• Production log exports.
• Contractual documents lying around the project.

In tests, synthetic data replaces real data. If your internal policy requires it, the model runs on your own machine: that is local in the strong sense, which is decided before the project and carries an operating cost.

Assessing an extension before authorizing it

An AI extension accesses the workspace, sometimes the terminal. So the assessment happens beforehand and ends in a team decision: authorized, under conditions, or refused. An extension “tried out to see” on a real repository has already been authorized, without a decision.

Five points to check before installing an extension

The table below gives the five points and the decision they call for. The last two, reversibility and the software supply chain, are the most discriminating.

The robustness limits no extension fixes

Some limits come from the nature of the models and are found in every extension, whatever the quality of the integration.

• Error handling: an agent that fails tends to try a variant rather than question its starting assumption.
• Multi-file consistency: a change that is right in each file taken on its own can be wrong at module level.
• Context limits: beyond a certain size, the agent loses elements it had read, and nothing tells you.
• Non-deterministic behaviour: the same request, twice over, does not produce the same diff.

Models remain probabilistic, and indexing the workspace reduces how often errors occur without removing them, and makes answers more convincing on a quick read. For any multi-file change, ask for the list of impacts and the checks before looking at the code.

Cutting down the iterations

Time lost with an agent is rarely lost all at once: it is lost in back-and-forth. A good agent prompt is a small technical brief, and it asks for a verifiable result rather than a satisfying one.

• Objective: “add an endpoint X with input validation and explicit errors”, not “improve the API”.
• Constraints: versions, conventions, folder structure, logging style.
• Expected formats: list of files touched, diff, tests, migration note.
• Minimal examples: one input case and its expected output, as short as possible.
• Anti-examples: “redo the whole API” with no scope and no criterion, and, more useful still, an extract of what you do not want to see in the result.

The anti-example is the most profitable and the least used: two lines remove a known class of errors. Next comes the action plan before any writing, then splitting into tasks: four diffs of thirty lines get read, one diff of a hundred and twenty gets skimmed.

Between the batches, set checkpoints: the agent stops, shows what it has changed and checked, and waits. The sequence runs in four stages: plan, first small diff, tests then fixes, final recap (what changed, how to check it, how to roll back). That last point lets you abandon a failed session instead of repairing it.

Demanding evidence: tests, diff and artefacts

An agent produces plausible code; your job is not to judge it by reading, but to obtain evidence that does not depend on your appreciation. Three families are enough: tests that fail when the code is wrong, a diff that can be read line by line, and artefacts that explain the decisions.

Having the scenarios, the edge cases and the non-regression criteria produced

To debug, first have the assumptions made explicit: probable cause, files involved, way to reproduce. An agent that proposes a fix without having reproduced the problem is fixing something else. Impose three-stage tests (nominal case, edge cases, non-regression) and ask for the edge cases before the fix: produced afterwards, they are written to pass.

The non-regression criterion is the one that gets forgotten and the most discriminating: it checks that what worked before still works. Finally, ask for verifiable fixes: command run, result observed, link between the cause and the change.

Reviewing the diff and the artefacts left behind

Your best quality assurance remains a readable diff and atomic commits: an unreadable diff is not reviewed, it is approved. Ask for conventions respected and commit messages that explain the intention. Traceability is not added afterwards: it is what will tell you, in three months, why this line exists.

Then come the artefacts, which the agent maintains well and which nobody updates spontaneously: README, architecture decision records, changelog, runbooks. They are reviewed like code, with runnable examples. If you write the loop that does all this yourself, it is a Python AI agent you are building; here, an agent writes code for you.

Knowing whether it actually saves you time

The gain is greatest on standardized tasks (skeletons, tests, documentation, mechanical refactorings), where the result is known in advance and verification is quick. The hidden cost shows up when the output is hard to maintain: style inconsistencies, needless abstractions, quiet duplication, technical debt nobody decided to take on.

The tipping point is almost always the same: review time exceeds the writing time saved. Four indicators settle it with no tooling.

Collected over a month, these four points give a documented decision on what the team hands to an agent.

Continue reading

Depending on where things go next, four articles take over.

• What comes next happens on the remote repository: automated review and the continuous integration chain belong to the GitHub AI agent.
• You are deciding for a team: licences, account rights and policies are the ground of the Copilot AI agent.
• You want to run the agent outside your editor: models, vendors and automation tools are compared on an AI agent platform.
• The code must not leave your machine: hardware, models and operating load are compared on the local AI agent.

If the agent you need to frame works on your data and your business rules rather than on code, that is the ground of a personalized AI for your business.

FAQ on AI agents in VS Code

How do you code faster with AI in VS Code without degrading quality?

You code faster without degrading quality by keeping the agent for tasks that can be checked fast: skeletons, tests, documentation, mechanical refactorings. The loop stays short (plan, small diff, tests, review), and the agent also serves as a reviewer and a generator of edge cases.

How do you create an agent in VS Code (and which limits should be set)?

An agent is created in VS Code from the built-in modes (ask, plan, execute) or as a custom agent given a role, tools and a model. The limits are set before the run: authorized file scope, explicit prohibitions (secrets, production configuration), mandatory tests.

How do you use Copilot in VS Code, including Copilot agent mode?

GitHub Copilot agent mode is used, at the time of writing, from the conversation view, after being switched on in the settings. You move to it for multi-step tasks, starting with a request for a plan, then moving forward in steps validated one at a time.

Which AI extensions support agents (and how do you assess them)?

An agent extension is assessed on five points: data sent, permissions, logging, reversibility and software supply chain, before any installation on a real repository. Extensions whose actions can be audited come first; between two candidates, the ability to prove wins over speed.

What is the difference between an agent, a chat and autocompletion in VS Code?

Autocompletion speeds up typing on known patterns, chat helps you decide without changing anything, the agent carries out a complete task in several steps, with tools and across several files. The right choice depends on the surface of change and on your ability to check the result.

Which guardrails should be switched on before letting an agent change several files?

Before a multi-file change, the agent works on a dedicated branch, with atomic commits and mandatory tests before merge. The file scope is declared positively and writing outside the repository is blocked by the environment. On a test's second failure, the agent stops and asks for clarification.

How do you give an agent the right project context without exposing sensitive data?

The right context is the minimum sufficient context: conventions, objective, paths of the relevant files, the extracts needed. Secrets, personal data and production logs stay outside, and test cases use synthetic sets. If internal policy requires it, the model runs on your own machine.

How do you avoid plausible errors and improve verifiability (tests, logs, evidence)?

A plausible error is caught by evidence, not by reading: at every step, the agent provides the command run, the result observed and the link between the cause and the fix. Edge cases are produced before the fix, and non-regression tests are systematically added.