VS Code AI Coding: Choose an Assistant and Set Up Your Workflow
Several AI coding assistants work inside VS Code, and each takes a different approach to context, suggestions, and code changes. Here is how to choose one, configure it, and review its output before committing.
Updated 4 min read
VS Code supports several AI coding assistants through its extension marketplace and through companion tools you run alongside it. They range from inline completion engines to agents that can edit multiple files and run commands. The right choice depends on the kind of work you do and how much review you want to run before code lands. Tools like fenbs keep your project decisions and progress outside any one assistant, so switching tools does not mean starting the project explanation over.
The main AI coding options for VS Code
GitHub Copilot is the most widely used extension. It offers inline completions, a chat panel, and an agent mode called the Copilot cloud agent that can propose multi-file changes. Cursor is a separate VS Code fork with its own AI layer. Codex CLI is a command-line coding agent you run alongside VS Code. Each tool has different strengths and a different way of reading project context.
| Tool | How it runs | Best for |
|---|---|---|
| GitHub Copilot | VS Code extension | Inline completions, GitHub integration, broad language coverage |
| Cursor | Separate VS Code fork with built-in AI | Codebase-wide context, multi-file edits, larger refactors |
| Codex CLI | Command-line tool used alongside VS Code | Shell and file operations, sandboxed execution |
For a focused look at how Cursor and VS Code with Copilot compare day-to-day, see Cursor vs VS Code. For a broader comparison of coding agents, best AI coding agents covers more options.
Configuring the assistant for your project
Most AI coding tools read from a context file in the repository root. GitHub Copilot reads AGENTS.md or .github/copilot-instructions.md. Cursor reads .cursorrules or uses its built-in rules panel. Codex CLI reads AGENTS.md. These files set the ground rules: the framework, the naming conventions, the files the assistant must not touch, and the requirement to review before committing.
Keep context files short and specific. A long file dilutes the instructions and the assistant weights every line equally. A useful context file names the primary technology stack, the test runner, any restricted folders, and any standing rules about code style or review. Update it when those facts change.
Giving the assistant context at the start of a session
An assistant that starts without knowing the current task will either ask questions or make assumptions. Both slow you down. Before starting work, tell the assistant in a short message what you are building, which files are involved, and any constraint from the last review.
If you connect a supported tool to fenbs over MCP, the assistant can read the project context automatically: the Decisions and rules come first, then Where we left off and the current tasks. You write that context once and every connected session starts from it, without a manual summary.
Reviewing AI-generated code before committing
Code that compiles and passes tests is not necessarily code you want to keep. Use the VS Code diff view to check exactly what the assistant changed. Confirm that the logic matches the task, that no unintended files changed, and that the style fits the project. A guide to reviewing AI-generated code covers the specific things to look for.
- Open the diff view before staging any file, not after.
- Check every changed file, not just the ones you asked the assistant to touch.
- Run the full test suite before committing, not just the test for the feature you changed.
- If you reject a suggestion, note why, so the next session starts with that correction.
Give every assistant the same project context
Connect your AI coding tool to fenbs over MCP from Integrations. At the start of a session the assistant reads your Decisions and rules, Where we left off, and the current task. Before stopping it saves where each task stands. The next session, in the same tool or a different one, starts from the same record.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Switching tools mid-project
VS Code extensions can be enabled or disabled per workspace, so switching tools is technically easy. What gets lost is the record of what was decided and where things were left. Saving that record before switching is the habit that keeps a tool change from becoming a context reset. Ask the current assistant to save its progress before you switch, then ask the new one to read the project context before it starts.
Put your context file in version control. Every developer who clones the repository gets the same starting instructions, and updates are tracked alongside the code. Review it when the project adds a new dependency or changes a coding standard. An outdated context file gives an AI assistant wrong information, which is harder to catch than no information at all. A short note at the bottom of the file recording the last date it was reviewed helps the team keep it current.
How to do this with fenbs
- Create a free account and add a project for the codebase you are working on.
- Add the current tasks, their status, and any active Decisions and rules about the code: naming conventions, libraries to avoid, the review requirement.
- Connect your AI coding tool from Integrations. GitHub Copilot, Cursor, and Codex CLI are supported over MCP.
- Ask the assistant to read the project context at the start of each session and to save task progress before stopping.
- When you switch tools or start a new session, the next assistant reads the same record and continues from Where we left off.