Getting started with Claude Code

Claude Code is not autocomplete for a single file, and it isn't a chatbot you paste code into by hand. It's a loop: you give it a goal in plain English, it reads your actual files, decides what to do (edit a file, run a command, search for something), does it, looks at the result, and keeps going until the goal is met or it needs your input. The important shift for a beginner is trust, not syntax — you're delegating a task, not writing a prompt for a single reply.

It runs from a terminal, inside your own project's files, with your own git history and your own tools (compilers, test runners, linters) available to it — that's what lets it actually verify its own work instead of just guessing at what compiles.

Claude Code installs with a single command (npm install -g @anthropic-ai/claude-code if you have Node.js already, or the native installer on Anthropic's own docs if you don't want Node at all) and runs from any terminal. Sign in once with your Anthropic account, then cd into a real project directory and type claude.

• Start small. Your first prompt shouldn't be "build me an app" — ask it to explain a file, fix one specific bug, or add one small function. You're calibrating trust in both directions before handing over anything bigger.
• Watch the diffs. Every file edit is shown before or as it happens. Read them, at least at first — you're building a sense of what it tends to get right and where it needs more constraint.
• It asks before doing risky things. Running a shell command or editing a file outside a pre-approved pattern triggers a permission prompt by default. That's not a bug to work around; it's the seatbelt.

A file named CLAUDE.md at the root of a repo is read automatically at the start of every session in that project. It's the single highest-leverage file a beginner can write: put the things you'd tell a new hire on day one — how to run tests, which folder holds the real source of truth, which patterns are deliberate versus legacy cruft, and any hard rules ("never touch the payments module without asking").

Keep it short and concrete rather than exhaustive. A ten-line file that states real constraints beats a hundred-line file restating things Claude can already see by reading the code itself.

By default, Claude Code asks before running commands or touching files outside a safe pattern it already knows. As you get more comfortable, you can pre-approve specific, narrow things (a test command, a linter, edits inside one folder) instead of clicking "allow" every time — but the right instinct is to widen permissions one concrete case at a time, not to disable prompting altogether the first day because it's slightly annoying.

• Read-only actions (searching, reading files, running a linter) are the lowest-risk place to grant standing permission.
• Anything that touches money, deletes data, or publishes something publicly deserves a human eyeball every single time, no matter how many times it's gone fine before.
• Version control is your real safety net. Commit before a big multi-file change so a bad result is a git diff and a revert away, never a mystery.

Most sessions follow the same shape: state the goal in one or two sentences, let it look around before it edits anything, review the plan or the first diff, then let it keep going. For anything bigger than a few files, ask it to plan first and confirm the approach before it starts editing — catching a wrong assumption in a one-paragraph plan is far cheaper than catching it after twenty files changed.

• Be specific about "done." "Fix the bug" is weaker than "the login form should reject empty passwords and show an inline error" — a concrete, checkable outcome is easier for it to actually verify against, not just easier to read.
• Let it run your tests. If a test suite exists, telling it to run tests after changes turns "I think this works" into "I confirmed this works" — a genuinely different, much more reliable claim.
• Interrupt freely. If it heads the wrong direction three steps in, say so immediately rather than letting it finish and then explaining everything wrong — it's cheaper to redirect early.

• Handing over a vague, huge goal on day one. "Rewrite the backend" with no other context invites it to make a hundred small decisions you never got a say in. Scope the first few tasks yourself until you trust its judgment on this specific codebase.
• Disabling permission prompts to move faster, then not reading diffs either. The two safety nets are meant to work together; removing both at once is how a bad edit ships silently.
• Treating a confident-sounding answer as a verified one. A fluent explanation of why code works is not the same as running it. If it can run your tests or build, ask it to — don't take fluency as proof.
• Never writing a CLAUDE.md. Without it, every session re-derives your project's conventions from scratch by reading code, which is slower and more error-prone than just telling it once, in writing, where that stays true across sessions.
• Pasting secrets straight into a prompt "just this once." Treat a chat session the way you'd treat a shared document: nothing in it should be a real credential you couldn't stand to have logged somewhere.