If you've used Claude or ChatGPT in a browser, you already know the basics. Claude Code is the same idea brought into your editor: it can read your files, edit code, run tests, and commit changes, all from inside VS Code. This post walks through getting it running and the three pieces of jargon that trip up most beginners on day one.

What Claude Code is

Claude Code is Anthropic's coding assistant, and it's worth being precise about what that means. It's not a chatbot in your editor. It's an agent. A chatbot writes code. An agent writes it, runs it, and iterates.

In a single request you can ask Claude Code to:

Read files, search the codebase, and explain what it finds
Create, modify, or delete files and folders
Install, upgrade, or uninstall packages and dependencies
Run shell commands, scripts, tests, and the project itself
Loop on its own work: try a fix, run the code, read the error, try again, until the tests pass (or until it stops with a question for you)

That last bullet is the real shift. The grunt work of write-run-debug becomes the agent's job, not yours.

You stay in control throughout. Every action that touches the filesystem or the network asks for permission first, unless you've pre-approved it in your settings. More on the product page.

Install it in VS Code

Two paths. Pick one.

Extension (easiest). Open the Extensions panel in VS Code, search for "Claude Code", install the official Anthropic extension, and sign in. A side panel appears where you chat with Claude inside the editor.

CLI. If you prefer a terminal, install Node.js, then run:

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

Open VS Code's integrated terminal and type claude. Same product, text only.

On first run you sign in with an Anthropic account or paste an API key.

The context window

The "context window" is how much text Claude can see at once: your messages, the files you opened, the tool results, all of it. Today's top Claude models handle up to about 1 million tokens, roughly the length of a medium novel. That sounds enormous, but a long debugging session across large files fills it faster than you'd expect.

Everything you've said in the current conversation lives inside this window, and Claude uses all of it as context: your earlier instructions, the files it has already read, your follow-up corrections, the commands it ran. That's how it "gets" what you want as the conversation goes on, and how it tries to match your intent on the next step. The more clearly you explain things up front, the closer the result lands to what you had in mind.

Context sliding (auto-compaction)

When the conversation gets too big, Claude doesn't stop. It quietly summarizes the older parts of the conversation and keeps the summary, dropping the raw text. This is auto-compaction, sometimes called "context sliding." You notice it when Claude forgets a specific line from earlier but still remembers the general thread.

Try not to push a single conversation all the way to the limit. If a task is too big to finish in one sitting, split it into smaller chunks and start a fresh conversation for each chunk. The reason: when Claude compacts, it decides what counts as "important" enough to summarize and what to throw away. Sometimes the parts that matter most to you are not seen as important by Claude and get filtered out. After a compaction you may notice Claude no longer following an instruction you gave earlier in the same session.

This is one of the main reasons CLAUDE.md exists. Claude Code re-reads the root CLAUDE.md from disk and re-injects it after every auto-compaction (and at the start of every new conversation), so the rules you wrote at the project root come back intact even after a long session shrinks down.

CLAUDE.md (project memory)

CLAUDE.md is a plain markdown file at the root of your project. Claude reads it automatically at the start of every session. Use it for things that are true about this project: the tech stack, naming conventions, where the deploy script lives, which files to leave alone.

A useful starting CLAUDE.md is three lines of behavior rules:

- Before non-trivial work, present the plan briefly and get alignment. Don't jump straight into edits.
- When a request is ambiguous, ask. Don't guess.
- Don't add features, refactor, or "improve" code beyond what was asked.

These three sentences shape how Claude works on the project, which is often more valuable than listing the tech stack (Claude can read your package.json for that). Add to the file whenever you catch yourself correcting Claude on the same thing twice.

Keep CLAUDE.md short. Aim for around 200 lines or fewer. Everything in this file is loaded into every conversation, so each line costs tokens whether Claude needs it that session or not.

For a bigger project, don't pack everything into one root CLAUDE.md. Split the project into modules (one sub-folder per module), put a smaller CLAUDE.md inside each module folder, and in the root file just leave pointers like "for anything about the auth module, read auth/CLAUDE.md." Claude reads those sub-files only when it actually works in that folder, which keeps the token budget healthy.

One nuance worth knowing: only the root CLAUDE.md gets automatically re-injected after auto-compaction. Sub-folder CLAUDE.md files reload the next time Claude reads files in that folder, but they can drop out of context after a compaction and not return until you touch that folder again. If a rule absolutely must survive every compaction, keep it in the root file.

One thing to avoid: Claude Code supports @path/to/file imports inside CLAUDE.md, but using imports pulls every referenced file into the start of every conversation, whether you need it or not. Plain prose pointers are better, because the sub-files load on demand instead of always.

MEMORY.md (Claude's private notes)

MEMORY.md is also tied to your project, but it lives outside the repo. On most setups it's at ~/.claude/projects/<your-project>/memory/MEMORY.md, in the Claude Code user folder. Git never sees it, and teammates never see it.

Claude writes to it itself. When you say "I prefer two-space indents" or "always run lint before tests," it saves the rule as a memory file and links it from MEMORY.md. Over time those notes build into a picture of how you like to work on this project.

You don't usually edit it by hand. You talk to Claude normally and it captures the things worth remembering. If a stored fact turns out to be wrong, say so, and it updates the entry.

One important detail: this auto-save isn't guaranteed. When you tell Claude something firm in a conversation ("never ever do X"), it will usually notice the weight of the instruction and write it to a memory file, so the rule carries over into the next conversation instead of vanishing when this one ends. Sometimes it doesn't. If you really want a rule to stick, say so explicitly: "add this to MEMORY.md so you remember next time." That bumps it from "maybe save" to "definitely save."

Why have two files instead of one bigger CLAUDE.md?

CLAUDE.md is public, and you write it by hand. It belongs in version control with your code. Use it for rules that should apply to anyone working in this project: the tech stack, conventions, what not to touch.
MEMORY.md is private, and Claude maintains it for you as you talk. Use it for personal preferences and the small learnings Claude picks up about how you work.

If you put personal preferences in CLAUDE.md, teammates see them in Git. If you put shared project rules only in MEMORY.md, a teammate cloning the repo (or you in a fresh checkout) won't get them at all. Keeping the two separate keeps shared rules sharable and private notes private.

Plan mode (before any major change)

For anything bigger than a small edit, switch Claude into plan mode before letting it touch files. In plan mode, Claude lays out its proposed approach in plain text first: which files it will change, what it will change them to, what commands it will run. Nothing actually happens until you approve.

The mistake I made early on was treating the plan as a formality and clicking through. Don't. Read every line. If the plan says "modify the auth handler to also clear the session cache," ask whether that's what you want, or whether you wanted a smaller, more focused change. Push back, ask for alternatives, request that risky steps be split out and confirmed separately, and ask Claude to include a documentation step in the plan (a CHANGELOG.md entry, an inline code comment, or a short note in your docs folder) so the change is easy to revisit later. Iterate until every sentence in the plan matches what you'd want a careful coworker to do.

Approve when the plan is right. Keep iterating when any sentence makes you unsure. The few extra minutes pay for themselves the first time plan mode catches a refactor you didn't actually ask for, or a step that would have touched a file you forgot to mention.

You toggle plan mode in Claude Code with Shift+Tab. You can also ask Claude to plan the work out before executing, but personally I prefer the keyboard shortcut. The shortcut puts Claude into a guaranteed read-only state until I exit it, whereas a polite "plan first please" is just a request the model can interpret loosely.

Safety layers (the deny list)

AI assistants make mistakes. Every model does, no matter how good. For anything destructive or hard to undo, don't rely on a single line of guidance. Use layers.

A short list of actions worth gating:

Deleting files or folders
Modifying any module that's already finished and signed off
Touching tables, databases, or migrations
Installing, uninstalling, or upgrading packages
Anything that points at production

Two layers of guidance, one hard gate:

Guidance in CLAUDE.md and MEMORY.md. Both files hold rules Claude reads and usually follows. They aren't really "softer" or "harder" than each other; they differ in design (public and manual vs private and auto), not in protective strength. For safety-critical rules I put the same instruction in both, on the belt-and-suspenders principle: if one gets missed (dropped during a long compaction, or absent from a fresh clone), the other still catches it.
The deny list. Inside .claude/settings.json, Claude Code lets you list specific commands or paths that it must never run, period. Drop in the things you genuinely never want executed: recursive shell deletes, package uninstalls, database drops, any command that touches production.

The first two are guidance: they tell Claude what you want. The deny list is the gate that catches the mistake when guidance fails. Adding a deny entry costs one line. Recovering from an accidental DROP TABLE costs a bad afternoon at best.

What to do next

Open a small project in VS Code, install the extension, drop a one-paragraph CLAUDE.md at the root, and try something low-stakes: ask Claude to read a file and explain it. Once the first round trip works, the rest is practice.

One last thing

Powerful as Claude Code is, it isn't a replacement for your brain. AI assistants make real mistakes, and the worst ones are subtle: a missed import, a deleted line you didn't notice in a long diff, a "fix" that masks the real bug instead of solving it. Treat the tool as a strong assistant, not an autopilot. Always read what Claude changed before you commit, and run the tests yourself. The cost of skimming a diff is a few seconds. The cost of letting small mistakes compound across a hundred commits is a codebase you no longer trust.