Setting Up Claude Code in VS Code and Using It Beyond Autocomplete

Installed is not the same as integrated

Getting Claude Code running next to VS Code takes about ten minutes. Making it change how you work takes longer. A common pattern is to connect it and then treat it like Copilot, for tab completion, quick suggestions and the odd refactor. That's fine and useful, but it isn't transformative, and it's a bit like driving a sports car in first gear. Having Claude in your editor and having it built into your workflow are different things. The setup is quick, and the payoff comes from knowing what to ask once it's running.

Four ways to use Claude with VS Code

"Claude in VS Code" can mean several things:

• Claude Code in the terminal: Anthropic's own CLI. It has access to your whole codebase, reads and writes files, runs commands and works across many files at once. It's the most powerful of the four.
• GitHub Copilot running a Claude model: a Copilot subscriber can swap the model behind it to Claude Sonnet and stay in the interface they know.
• Claude.ai in a browser tab beside the editor: low-tech and underrated. Paste code, take suggestions, paste back. It's slower, works anywhere and costs nothing extra.
• Third-party extensions that add a Claude chat sidebar: quality varies, and some haven't been updated in months.

The rest focuses on Claude Code, since it's the one that changes how much the AI can do. Browser chat and Copilot are handy but limited. Claude Code sees the whole project, understands how files relate, runs tests and iterates, which is a different class of tool.

Setup in three steps

Expect around 10 minutes if you've done it before and perhaps 20 the first time.

Install it

Claude Code is a command-line tool, installed through npm:

npm install -g @anthropic-ai/claude-code

It needs Node.js 18 or newer, so update first if yours is older. After installing, start it:

claude

It asks you to sign in with your Anthropic account. A free account is enough to begin, but you'll hit limits quickly on a real project. Once you're authenticated, you're done.

Use it from the VS Code terminal

The route described here doesn't involve a VS Code extension. Claude Code runs in the integrated terminal, so the routine is:

1. Open the project in VS Code.
2. Bring up the built-in terminal with Ctrl+ (Cmd+ on a Mac).
3. cd into the project root.
4. Type claude.

From there it has context about the project. It can read files, work out the structure, run your tests and change several files in one pass. It also sits well beside the editor: let Claude edit in the terminal pane and watch the changes appear in the editor as they happen. The split-screen idea takes a little getting used to and then feels smooth.

Write a CLAUDE.md

Most tutorials skip this step, and it pays off the most. CLAUDE.md is a file in the project root that tells Claude about your conventions, preferences and rules. Without it, Claude makes reasonable guesses from what it sees. With it, Claude acts as if it has been on the team for months. A minimal version:

# Project conventions

## Tech stack
- Node.js 20, TypeScript, Express
- PostgreSQL via Prisma
- Jest for testing

## Code style
- Use async/await, never callbacks
- Prefer explicit error handling over try/catch everywhere
- All new functions need JSDoc comments

## Testing
- Every new endpoint needs at least 3 tests: happy path,
  validation error, and auth failure
- Use factories, not fixtures

## What NOT to do
- Don't use any (TypeScript). Use unknown and narrow it.
- Don't add console.log for debugging. Use the logger.
- Don't install new dependencies without asking first.

Fifteen minutes on this file saves hours of correcting Claude's defaults. Update it any time you catch Claude making the same mistake twice.

Habits that make it worth using

With setup finished, the harder part is using it in a way that beats a plain chat window.

Hand it bigger jobs

A common early habit is using Claude Code as a glorified autocomplete, asking for one function, one syntax fix or one extra parameter at a time. That works, but it isn't what makes the tool special. It does better with larger tasks. Something like: add pagination to every list endpoint in this API, here's how the users endpoint does it now, apply the same pattern everywhere. That's an hour of manual work, and Claude can do it in about five minutes.

The context window is big enough to hold a meaningful chunk of a real codebase, so use it. Give it several files, describe the whole picture and let it work across all of it.

Ask it to investigate

When something odd shows up in production, such as a slow query, a slightly wrong response or an error that appears only now and then, describe it, point Claude at the relevant files and ask where it could be going wrong. It reads across the codebase and returns a ranked list of suspects. It isn't always right, but it finds things you would have overlooked and traces execution paths much faster than doing it by hand.

In a side-by-side trial on a real bug against Cursor and Copilot, Claude Code was the only one that paused to ask a clarifying question before starting, and that question turned out to be the entire bug.

Write the test first

It sounds backward, and for anything with clear requirements it works well. Write a test describing the behavior you want, hand it over and say: make this pass without breaking anything else. Three things follow. The implementation matches your real requirements, because you defined them in code. Ambiguities surface early, because writing the test forces you through edge cases. And you finish with a test in hand, which you wouldn't necessarily get by asking for the feature first and tests afterward. It's especially worth doing for payment flows, authentication and external APIs, where mistakes are costly enough that you want correct behavior defined before any code exists.

Use it for refactoring

Refactors are easy to describe and tedious to do carefully. Maybe a function ballooned, a module took on too much, or the same snippet got copied five times instead of being abstracted. Tell Claude what the module should be responsible for, ask it to extract the rest into a new one and have it update every import site. It can carry that out across the codebase, fix every reference and run the test suite to check nothing broke. What would take a careful morning may be done in twenty minutes.

Where it falls short

• It makes confident mistakes. Claude Code sometimes implements something incorrectly without flagging any doubt, so read the output and don't just run it, especially for anything touching data or money.
• It won't do your architecture for you. Carrying out a design is its strength, while choosing what to build, how to structure the system and which tradeoffs to take is not. Those decisions stay with you.
• Context limits are real. In a very large codebase it doesn't see everything, so point it at the relevant files instead of assuming it knows where to look.
• It can't run what your environment can't run. If tests need a particular database connection, a running server or environment variables, those must be configured. It works in your actual environment and isn't magic.

It's worth knowing exactly where it failed on a realistic feature build before trusting it with anything production-critical.

Three prompts worth keeping

These came out of plenty of trial and error.

Context first. State the current behavior and the desired behavior explicitly, so Claude doesn't misread what already exists:

I'm working in [filename]. Here's the current behavior:
[describe it]

Here's what I want it to do instead:
[describe it]

Constraints: [any important limits]

Make the change and update any affected tests.

Surface the assumptions. Use this whenever requirements are even slightly ambiguous. It costs half a minute and saves you from a subtly wrong implementation:

Before you start coding, list the assumptions you're making
about how this should work. I'll confirm or correct them.

Review with a checklist. A code review is most useful when you say what to look for. Otherwise the model tends to flag style issues and overlook what matters. Run this before merging anything significant:

Review this code for: performance issues, security concerns,
missing error handling, and anything that would cause problems
at scale. Be specific. If something is fine, say it's fine
and move on.

Claude Code or Copilot?

The two excel at separate jobs, which is why people who try both usually keep both. Copilot wins on inline autocomplete: suggestions appear as you type without switching mental context, its tab completion is still smoother and it's slightly better integrated into the VS Code interface. Claude Code is stronger on multi-file tasks, investigation, refactoring and anything you can describe in natural language and leave the AI to work out across the codebase. Its agentic ability is clearly ahead.

If you have to choose one, choose Claude Code, because the work only it does well is worth more than quicker autocomplete. Many developers who use it daily still leave Copilot running in the background and switch depending on the task.

What made the difference

After months of daily use, the biggest improvement didn't come from setup. It came from changing what you ask for. The people who get the most out of Claude Code don't use it to write functions faster. They give it bigger, messier, more realistic problems: the refactor that's been postponed, the feature spanning six files, the investigation that would eat an afternoon of log reading.

The setup costs ten minutes. Learning to think in those larger tasks is the real investment, and a worthwhile one.