Getting started with Claude Code

What it actually is

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, does it, looks at the result, and keeps going until the goal is met or it needs you. The shift for a beginner is trust, not syntax — you’re delegating a task, not writing a prompt for one reply.

It runs from a terminal, inside your own project’s files, with your own git history and tools available — that’s what lets it verify its own work instead of guessing at what compiles.

Installing it and your first session

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

• Start small. Your first prompt shouldn’t be “build me an app” — ask it to explain a file, fix one bug, add one small function. You’re calibrating trust in both directions.
• Watch the diffs. Every file edit is shown as it happens. Read them, at least at first — you’re learning where it needs more constraint.
• It asks before risky things. Running a shell command or editing outside a pre-approved pattern triggers a permission prompt by default. That’s the seatbelt, not a bug.

CLAUDE.md — telling it about your project

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 highest-leverage file a beginner can write: the things you’d tell a new hire on day one — how to run tests, which folder is the source of truth, which patterns are deliberate versus legacy, and any hard rules (“never touch payments without asking”).

Keep it short and concrete. A ten-line file that states real constraints beats a hundred-line file restating what Claude can already read from the code.

Permissions: the trust dial

By default Claude Code asks before running commands or touching files outside a safe pattern. As you get comfortable, pre-approve specific narrow things (a test command, a linter, edits inside one folder) — but widen permissions one concrete case at a time, rather than disabling prompts on day one because they’re slightly annoying.

• Read-only actions (searching, reading, linting) are the lowest-risk place to grant standing permission.
• Anything that touches money, deletes data, or publishes publicly deserves a human eyeball every single time.
• 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.

An everyday workflow

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

• Be specific about “done.” “The login form should reject empty passwords and show an inline error” beats “fix the bug” — a checkable outcome is easier for it to verify against.
• Let it run your tests. That turns “I think this works” into “I confirmed this works” — a genuinely different claim.
• Interrupt freely. If it heads the wrong way three steps in, say so now rather than letting it finish.

Mistakes first-timers actually make

• Handing over a vague, huge goal on day one. Scope the first few tasks yourself until you trust its judgment on this codebase.
• Disabling permission prompts, then not reading diffs either. The two safety nets work together; removing both is how a bad edit ships silently.
• Treating a confident answer as a verified one. A fluent explanation of why code works is not the same as running it.
• Never writing a CLAUDE.md. Every session then re-derives your conventions from scratch.
• Pasting secrets into a prompt “just this once.” Treat a session like a shared document — nothing in it should be a real credential.