Getting Started With Claude Code: A First-Day Guide

Claude Code is Anthropic's coding agent that lives in your terminal. Not an autocomplete in your editor, not a chat window you copy-paste out of — an agent that reads your codebase, edits files, runs commands, and reports back, all from the command line inside your actual project. If you've spent time with AI coding tools that only suggest, the shift is bigger than it sounds: you're delegating a task, not accepting a completion.

This guide is for your first day. It covers what Claude Code is, how to get it running (at a high level — the exact commands live in Anthropic's docs and change often enough that you should get them from the source), the core loop you'll spend all your time in, why you want a CLAUDE.md from the very first session, and the handful of beginner mistakes that cost people their first week. Nothing here assumes a particular language or framework.

What Claude Code actually is

The important word is agent. A traditional AI coding assistant waits for you to invite a suggestion and then proposes text. Claude Code is closer to pair-programming with someone who has hands: you describe an outcome, and it goes and does the work — opening files to understand the surrounding code, making edits across several files, running your tests or a build to check itself, and course-correcting when something fails.

Because it runs in the terminal and works against the real files on disk, it fits naturally into how you already work: it's in your repo, it sees your directory structure, and it can use the same tools you do. That also means it can change things, which is why the review step (below) matters as much as the request.

Getting it running

Claude Code is a command-line tool you install once and then launch from inside any project. There's more than one way to install it — a native installer, or a package manager if you prefer — and Anthropic maintains the current instructions, so I'm deliberately not pasting a command here: install methods and prerequisites shift, and a stale command is worse than a link. Get the exact, current steps from Anthropic's official Claude Code documentation, currently at code.claude.com/docs.

Two things are worth knowing before you start:

• You'll authenticate on first launch. Claude Code needs to connect to your Anthropic account. The first time you run it, it walks you through signing in (or configuring API access). Have your account ready; the flow is quick and one-time per machine.
• You launch it from your project. Open a terminal, change into the repository you want to work on, and start Claude Code there. It anchors to that directory — the code it can see and touch is the project you launched it in. Starting it in the right folder is the whole setup.

Once it's running, you're at a prompt. Type what you want in plain language and press enter. That's the entire interface.

The core loop: describe, act, review

Almost everything you do with Claude Code is one loop repeated:

1. You describe a task in plain English. "Add a since query parameter to the /orders endpoint that filters by date." Be specific about the outcome; you don't need to specify the steps.
2. It acts. It reads the relevant files, plans an approach, edits code, and — when there's something to run — runs it. Crucially, it asks permission before it does anything consequential: by default it prompts you before editing a file or executing a shell command, and you approve or decline each one. You're never surprised by a change you didn't see coming.
3. You review. It shows you the diff and tells you what it did. You read it, run it yourself if you want, and either accept, ask for a change, or redirect.

Then you go around again. The skill you're building on day one is reviewing well — treating the agent's output as a proposal from a fast, capable, occasionally overconfident colleague, not as finished work. Read the diff. When a change has a runtime surface, ask it to actually exercise the code and show you the output, rather than accepting "it compiles" as proof it works. That one habit catches more real problems than any other.

A tip that pays off immediately: for anything non-trivial, ask for a plan before it writes code. Claude Code has a plan mode built for exactly this — it explores and proposes an approach without touching files until you approve. Naming the risky assumption up front, while a fix is still one sentence, beats discovering it after the code is written.

Write a CLAUDE.md on day one

CLAUDE.md is a plain Markdown file at the root of your project that Claude Code reads automatically at the start of every session. Think of it as project memory — standing instructions that ride along with every request so you don't re-explain your setup each time.

On day one, the single highest-leverage thing you can do is put your exact build, test, and lint commands in it. If the command to run your tests lives only in your head, the agent will guess — and a wrong guess means it skips the check that would have caught its own mistake. Give it the commands and it can verify its work before you ever see it. Add the conventions that aren't obvious from the code: how you handle errors, your directory layout, the libraries you prefer over reinventing.

Keep it short and accurate. Every line sits in the model's working context for the whole session, so a tight file beats a comprehensive one. You don't have to write it by hand, either — Claude Code ships an /init command that inspects your project and drafts a starter CLAUDE.md you can trim. If you'd like a fleshed-out example to learn from, the open-source claude-code-starter repo includes a Next.js/TypeScript CLAUDE.md template you can read and adapt to your own stack.

Four beginner mistakes to avoid

• Treating it like autocomplete. The instinct from older tools is to feed it tiny, isolated snippets. Claude Code is at its best given a real, outcome-shaped task in a real repo. Let it read the surrounding code; that context is where its judgment comes from.
• Accepting "done" without verifying. A green typecheck proves the types line up, not that the feature works. If you take one habit from this guide, take this: when there's something to run, make it run and show you the output — both the happy path and the failure path.
• Rubber-stamping diffs. It's fast, so it's tempting to accept changes without reading them. Don't. The review step is where you stay in control of your codebase. Skim every diff; you'll catch the scope creep and the "helpful" extra change you didn't ask for.
• Letting one conversation sprawl forever. A single thread that drifts across five unrelated tasks fills the context with noise, and the agent starts "forgetting" what you agreed on. When you finish one task and move to an unrelated one, clear the context (there's a /clear command for exactly this) and start fresh.

Where to go from here

Your first day with Claude Code is really about internalizing one rhythm — describe, let it act, review honestly — and setting up a CLAUDE.md so the agent stops guessing about your project. Get those two things right and everything else builds on top of them: skills, subagents, plan mode, and multi-step workflows all make more sense once the basic loop feels natural. Start with a small, real task in a repo you know well, read every diff it produces, and insist on seeing the code run before you call anything done. That discipline is what turns a fast agent into a reliable one.

Related guides

• What Are Claude Code Skills (and How to Write One)
• Doing Code Review With Claude Code
• Debugging Methodically With Claude Code