Your first session

If you've used GitHub Copilot or the autocomplete in your editor, set that mental model aside before you start. Claude Code is a different kind of tool, and the autocomplete picture will steer you wrong.

What Claude Code actually is#

Claude Code is an agent that runs in your terminal. You describe what you want in plain English and it works on your project through a small set of tools: it reads files, edits files, and runs shell commands. That's the whole surface. Give it a goal and it decides which files to open, makes changes, runs your tests, reads what came back, and keeps going until the goal is met or it needs you.

So where autocomplete needs a good cursor position, an agent needs a good instruction and a project it can navigate. It also needs you watching, because it acts on real files and runs real commands. Most of this course is about making that supervision cheap.

Claude Code also runs on the web, in VS Code and JetBrains, and in CI, but I use the terminal CLI throughout. The mechanics are most visible there, which helps while you're learning them.

Install and start#

The npm package is the most portable way in:

# Requires Node.js 22 or later
npm install -g @anthropic-ai/claude-code

# Confirm it landed
claude --version

If claude --version prints a version number, you're set. If it says command not found, the installation troubleshooting guide matches the error to a fix. Anthropic also ships a native installer (curl -fsSL https://claude.ai/install.sh | bash) that auto-updates in the background, and the setup docs cover Homebrew and the Linux package managers too. Every method gives you the same claude binary.

To start, move into a project and run one command:

cd path/to/your/project
claude

The first run walks you through logging in through your browser. You'll need a Claude Pro, Max, Team, Enterprise, or Console account, since the free plan doesn't include Claude Code. After that your credentials are stored and you go straight to the prompt.

The three ideas that matter on day one#

You don't need the internals yet. You need three concepts, because every habit later in this course builds on them.

The agent loop#

Claude Code works in a loop: it reads something, acts (edits a file, runs a command), observes the result, and decides what to do next. When it runs your test suite and a test fails, it sees the failure and tries again. That feedback cycle is why an agent can carry a multi-step task instead of answering a single question. The agentic loop is documented in depth once you want the full picture.

The context window as working memory#

Everything the agent currently holds in mind (your instruction, the files it has read, the command output it has seen) lives in a context window. Think of it as a desk that only fits so many open books. It's large but finite, and when it fills, older detail gets crowded out. On a first session this rarely bites. On a long day it does, and chapter 3 is entirely about keeping that memory clean. For now, just know the desk exists.

Permission prompts are the safety layer#

Claude Code doesn't silently edit files or run commands. Before it changes anything, it shows you the edit or the command and waits for your approval. You can approve one action, approve a category for the session, or cycle permission modes with Shift+Tab once you trust a given flow. Chapter 2 tunes these settings so the prompts protect you without slowing you down. On your first session, read each prompt before you approve it. That habit carries most of the safety story on day one.

A first session, start to finish#

Here's a small, real first task: understanding a project, making one change, and committing it.

Notice that you never named a file. The agent found README.md by reading the project, which is the loop doing its job. Notice also that the edit and the commit each surfaced for approval before they ran. And the request was a sentence, not a specification. Chapter 4 goes deep on precision, but a plain, honest description is enough to start.

When to trust the output, and when to verify#

An agent sounds equally confident when it's right and when it's wrong. The discipline: verify what you can't afford to be wrong about. Read the diff before you approve it. When the agent says the tests pass, glance at the run. When it claims a change is done, look at the change.

One number from my own history is useful here. Across a 29-day stretch of building this way (241 sessions, roughly 1,470 hours of agent runtime), my file reads ran about 1:1 with the agent's edits. For every change the agent made, its work got looked at roughly once. That's what active supervision looks like in practice, and it's why errors get caught at the diff instead of in production. Chapter 2 turns the instinct into a repeatable setup. Until then, one rule: approve nothing you haven't read.

You've made a change and committed it. Chapter 2 covers setting up a project so an agent can't hurt you: the CLAUDE.md, the permissions, and the guardrails that let you move faster because the mistakes are contained.