How to choose an AI extension for VS Code

This guide shows how to choose an extension with verifiable criteria, test it without putting the main project at risk, and decide when a single assistant is enough or when you need to coordinate agents.

In this article you will see:

• How to separate autocomplete, chat, agent and orchestration.
• How to check publisher, origin, updates and permissions.
• How to test the extension in a controlled project.
• How to compare results without accepting code automatically.

AI extension for VS Code: start with the task

Autocomplete suggests snippets while you type. Chat answers questions and can explain files. An agent receives a goal, navigates the project and proposes changes across multiple files.

These uses are not equivalent. If you only want to complete a function, a lightweight extension may be enough. If you need to change code, run tests and review a diff, look for agent features and approval controls.

There is also orchestration. In this case, the tool organizes more than one agent, each with a task or a work folder. bridgecode enters this layer when the need stops being choosing an extension and becomes following a team of agents in VS Code or in the Antigravity IDE.

Before installing, write down the outcome you want to test. For example: “add validation to the form, create tests and show the diff before saving”. A good extension should let you follow these steps, not just generate a code block.

Check publisher, origin and permissions

Open the extension page on the Visual Studio Code Marketplace. Confirm the publisher name, the indicated repository, the documentation and the date of the last update.

Do not treat install numbers or stars as sufficient proof. They help you discover options, but they do not answer whether the extension is suitable for your repository, whether it is maintained, or whether it requests permissions compatible with your work.

Read the privacy policy and look for a description of what is sent to external services. For proprietary code, prefer to know which account is used, which files enter the context, and how to turn the feature off when needed.

The VS Code documentation also explains how to install, remove and list extensions via the command line. This is useful to repeat the test on another machine or to record the team configuration.

Install and test outside the main project

Create a test folder or use a disposable branch. The goal is to observe the extension behavior before granting access to the repository that contains code, credentials or customer data.

You can list installed extensions and install a specific option with the VS Code CLI:

$ code --list-extensions
$ code --install-extension publisher.extension

Replace publisher.extension with the identifier shown on the extension page. Do not copy commands from blogs without checking that the publisher is the same as on the Marketplace.

Open the project in Workspace Trust. In an unknown repository, keep restricted mode until you understand which tasks the extension tries to run. Trust in the workspace and trust in the publisher are different decisions.

To avoid unexpected updates during evaluation, you can review extensions manually in the VS Code settings. An example is:

{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": true
}

Use this setting only during testing or when the team has its own update process. Afterwards, reassess the risk of staying on an old version.

Run a reproducible test with the same prompt

Choose a small task with an easy to verify result. A good test has an objective, allowed files, a test command and an acceptance criteria.

A useful request is: “read src/form.ts, propose email validation, do not change other files, explain the plan and only then show the diff”. This way you can see if the extension respects scope, explains what it will do and waits for approval.

After the response, check the Git status:

$ git status --short
$ git diff --stat
$ git diff --check

Run the project tests and note three things: how many manual fixes were needed, whether the explanation helped review and whether the extension tried to access files outside scope. Do not turn a nice answer into a performance score.

If you compare two extensions, use the same request, the same clean branch and the same test set. The guide to Codex, Copilot and Claude Code in VS Code can help separate installation from practical evaluation.

When to use an extension or an agent squad

An individual extension is usually enough for quick questions, small fixes and tasks you want to follow in a conversation. The flow gets more complex when planning, implementation, review and tests are happening in parallel.

At that point, installing more icons in the editor is not enough. You need clear roles, code isolation and a way to review the result before merge. bridgecode can organize this flow in the editor you already use, with each agent in its own task.

If the extension also uses external tools, read the guide to MCP in VS Code before enabling servers. A server can increase the agent's capability, but it also increases the project's trust surface.