Using AI in VS Code

VS Code with AI feels effortless until the first time it quietly does the wrong thing at scale. The danger is that the assistant predicts plausible code, and plausible is exactly the kind that passes a quick glance and fails in production.

Picture a developer who opens the Chat view, types "add caching to the user lookup", and leaves it in agent mode with terminal approvals turned off. The agent decides the cleanest fix is a new caching library, runs npm install on a package it picked, edits four files, and reports success. The code compiles. The build is green. Two days later a teammate notices the new dependency is unmaintained, the cache never invalidates, and the lookup now returns stale profiles after a password change. None of this was visible in the moment, because the developer approved nothing and read nothing. They treated the agent loop as a vending machine instead of a junior pair who needs review.

The expensive lesson here is that the editor did not fail. It did exactly what it was told, which was nothing in particular. The control a developer has in VS Code is structural, and it sits in three places: the context you load before the assistant predicts, the mode you choose for the size of the change, and the diff and command prompts you read before anything is kept. When those three are used, the same task becomes a reviewed plan, a small diff, and a denied npm install that prompts a conversation about whether the dependency is needed at all.

This matters more in 2026 than it did a year ago, because the editor now ships an Autopilot setting that auto-answers tool prompts and keeps working until the task is done. The faster the agent can move, the more the burden shifts onto the reviewer. The mechanism that lets you keep that burden manageable is the set of modes and approvals, which the next section breaks down.

Two distinct systems run under the same editor, and confusing them is the root of most frustration. Naming the parts makes the rest of the page concrete.

• Inline completions. As you type, a fast completion model proposes the next few lines as grey ghost text. There is no loop and no tool use. You accept with Tab or keep typing. This is for typing speed inside one file, and the only review is your eyes before you press Tab.
• The Chat view. A reasoning model that reads context, can call tools, and works in a multi-step loop. This is where real tasks happen, and it has three modes.
• Ask mode. Answers questions and explains code. It never edits a file. Use it to understand a function, a stack trace, or a library before you change anything.
• Edit mode. You name the files and describe the change. The assistant proposes edits across those files and always shows a diff first, which you apply or reject. Use it for a targeted change you can already describe precisely.
• Agent mode. You give a high-level goal. The agent finds the files itself, plans steps, edits across the project, runs terminal commands, and iterates when something fails. Use it for tasks where you do not yet know every file that needs to change.

The distinction that decides success is scope. Edit mode keeps you in control by construction, because it touches only the files you named and waits for you on every diff. Agent mode trades that for reach: it can discover the right files and fix related code you did not think of, at the cost of a larger surface to review and the ability to run commands. A useful rule is to pick the smallest mode that can do the job. A rename is Edit. A "wire this new endpoint through the service, the route, and the tests" is Agent.

The second mechanism is the approval gate in agent mode. File edits surface as diffs, and terminal commands stop at a prompt where you choose allow once, allow for this session, or deny. You can widen this with the chat.tools.terminal.autoApprove setting, an object that maps command names or /regex/ keys to true or false, so safe read-only commands (git status, npm test) skip the prompt while anything unmatched still stops for confirmation. Setting the global boolean chat.tools.global.autoApprove to true opens the gate on every tool at once. The 2026 Autopilot level goes further and auto-answers prompts to run uninterrupted. Each step you take toward auto-approval is a step away from review, so widen the gate narrowly and only for commands you would have approved anyway.

The third mechanism is context. The assistant predicts from what is in its window, so a versioned AGENTS.md at the repo root, read on every request, is how your conventions reach it without you retyping them. Path-scoped *.instructions.md files apply only where their applyTo glob matches. With those parts named, the next section walks one task through all three levers end to end.

Maya, a developer on a checkout team, needs to add server-side validation to the signup form so two fields, email and a referral code, are checked before the account is created. She does not yet know every file involved, so this is an agent task, and she runs it deliberately.

1. Load context first. The repo already has an AGENTS.md at the root with the stack (TypeScript, React, Vitest), the test command (npm test), and a rule that says no new dependencies without asking. Because the file is read on every chat request, Maya does not have to repeat any of it.
2. Ask for a plan, not a patch. She switches to a Planner custom agent, an .agent.md persona restricted to read-only tools, and prompts: "Plan server-side validation for the signup form. Email must be a valid format and unique; the referral code must exist and be unused. List the files you will touch and the tests you will add. Do not write code yet." The agent returns a six-step plan naming signup.controller.ts, a new validators/referral.ts, and two test files.
3. Correct the plan. The plan proposes a new validation library. Maya rejects that line, because AGENTS.md forbids new dependencies, and tells it to use the existing zod schema already in the repo. Fixing one sentence in a plan is far cheaper than unwinding an installed package later.
4. Hand off to the agent. She switches to Agent mode and says "Implement the corrected plan." The agent edits three files and writes the tests.
5. Review the diff and the commands. The change is about 80 lines, small enough to read line by line. When the agent reaches npm test at the terminal prompt, she chooses allow for this session, since tests are safe to rerun. She does not enable global autoApprove.
6. Verify behavior. Tests pass, but Maya manually submits a duplicate email in the running app to confirm the unique check fires, because a green test suite proves only what the tests assert.

The whole task took one short plan review, one 80-line diff read, and one scoped command approval. Compare that to the opening story: same goal, but reviewed at every lever instead of none. Maya carries into the next section, where the same workflow meets the traps that make it slip.

Each of these traps feels like progress in the moment while quietly undoing the control the modes are meant to give you.

• Tab-accepting on reflex. Long ghost-text completions are easy to accept without reading, so guesses pile up across a file. The fix is to treat Tab as a decision: read the suggestion, and reject it the moment it diverges from what you intended. Completions are for typing speed, not for design.
• Global autoApprove. Setting chat.tools.global.autoApprove to true, or running Autopilot, removes the one place you see what the agent runs. The fix is a scoped chat.tools.terminal.autoApprove object that lists only safe read-only commands, so prompts still appear for the commands that can change or destroy state.
• Agent mode for a one-liner. Reaching for Agent on a rename or a small edit turns a surgical change into a sprawling diff that takes longer to review than to write. The fix is to default to Edit mode and escalate to Agent only when you cannot name the files yourself.
• No instructions file. Without an AGENTS.md, the agent re-guesses your conventions on every task and drifts from the project style. The fix is a short versioned file at the root, not a long one, since a focused file the model actually reads beats an exhaustive one it ignores.

Two genuine edge cases sit beyond the simple rules. The hallucinated dependency. Agents sometimes import or install a package that does not exist or is abandoned, and roughly one in five AI code samples references a dependency that is not real. Maya's AGENTS.md rule and her denied install are the guard, since the approval prompt is precisely where an invented npm install becomes visible. Treat any new dependency the agent proposes as a claim to verify, not a fact.

The large diff that overwhelms review. In 2026 the constraint is review capacity, not how fast code can be generated. An agent can produce a 600-line change in a minute that no one can meaningfully read. The handling is to scope tasks so the diff stays small, and to ask the assistant "what assumptions is this code making, and are they safe?" rather than "does this look reasonable?". A reviewed plan up front keeps the eventual diff in a size a human can actually hold. These habits get harder when more than one person shares the repo, which is where scale comes in.

One developer can hold their own conventions in their head. The moment a repo has several contributors and an agent generating changes, the practice has to live in versioned files and a shared review habit, or it quietly stops happening.

The durable artifact is the instruction file under version control. A single AGENTS.md at the root carries the conventions every contributor and every agent should follow, and because it is recognized by multiple AI tools, the same file works whether a teammate uses Copilot or another assistant. For a monorepo, path-scoped *.instructions.md files under .github/instructions/ with an applyTo glob let the backend folder and the frontend folder carry different rules. A lead, call her Priya, owns these files the way she owns the lint config: they are reviewed in pull requests and they change as the project does.

The second team artifact is a pull request convention that records the AI's role. When a change came from agent mode, the PR description names that and includes the prompt or the plan, so a reviewer knows what to scrutinize. This is not bureaucracy. It tells the reviewer whether they are reading code a human reasoned through line by line or code an agent generated from a one-line goal, and the second deserves harder questions.

The third is a size limit. Keeping pull requests under roughly 400 lines is the single most effective review practice, and it correlates with materially faster review cycles. AI makes large diffs cheap to produce, which makes the limit more important, not less. Priya's team treats a 600-line agent diff as a signal to split the task, not as a reason to skim.

The durable principle to keep, whatever the size of the team: the assistant predicts plausible output, and your three levers are the context you load, the plan you agree before it writes, and the diff and commands you review before you keep anything. Start with one small thing. Add an AGENTS.md to one repo this week, default to Edit mode over Agent, and only widen terminal approvals once you trust the loop.