Working with Claude Code: First Steps

You have Claude.ai open in a browser tab. You copy a block of code, paste it into the chat window, describe the problem, get an answer, copy it back to your editor, test, notice it’s wrong because Claude doesn’t know the rest of the file, copy more context, paste again, and repeat. After half an hour you have a working fix. After an hour you no longer know which version is in your editor and which is in the chat.

This is the workflow that Claude Code replaces.

What Claude Code is

Claude Code is a command-line tool from Anthropic. You install it as an npm package, open a terminal in your project directory, and start a session. From that moment on, Claude has access to your files, your directory structure, your git history, and your terminal. It reads, writes, runs commands, and navigates through your code — all from within the context of your project.

The difference from ChatGPT, Claude.ai, or Gemini in the browser is fundamental. Those tools live in a separate window. You cut context from your project and paste it into a chatbox. Claude Code lives inside your project. It sees your files directly. It can run grep to search for something. It can run a test to verify that a change works. It doesn’t have to guess at your project structure — it reads it.

That sounds like a small difference. In practice, it changes everything. A model that knows your project makes different mistakes than a model that has to guess. It makes fewer mistakes about imports, paths, naming conventions, and existing code. The mistakes that remain are more substantive — and therefore more useful to debug.

Installation

Claude Code requires Node.js 18 or higher. Check that first:

node --version
# v18.x or higher

Install Claude Code globally via npm:

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

After installation, the claude command is available. Run it without arguments to verify:

claude --version

The first time you start it, Claude Code asks for authentication. You need an Anthropic account with an API key, or you log in via the OAuth flow that Claude Code offers:

claude
# → Opens an authentication flow in your browser
# → After login: session is active

That’s it. No Docker, no server, no configuration files. One command, authenticate, done.

Your first session

Open a terminal in the root of an existing project. Not in an empty directory — Claude Code needs context to be useful. A project with code, a README, a package.json or pyproject.toml is ideal.

cd ~/projects/my-app
claude

Claude Code starts an interactive session. You see a prompt where you can type text. From this moment on, Claude can read, search, and modify your project files.

Start with something simple:

> Read the README and give me a summary of this project in three sentences.

Claude reads README.md, analyzes the content, and responds. That seems trivial. The point is: you didn’t copy anything. Claude read your file directly from the file system. That’s the working model.

Now try something functional:

> Find all files where an API call to /users is made.

Claude uses grep or glob to search your project and reports the results with filenames and line numbers. Again: no copying, no pasting. The tool navigates on its own.

Understanding the project model

Claude Code builds a mental model of your project with every session. It reads your directory structure, examines configuration files, and scans the code relevant to your question. That model isn’t perfect — it’s built on what Claude chooses to read, and sometimes it misses context. But it’s structurally better than the copy-paste workflow of a browser chat.

There are three ways Claude gathers context:

1. Automatically at session start. Claude reads files in the root of your project: README.md, package.json, .env.example, CLAUDE.md (more on that later). This provides a basic understanding of the project.

2. On demand. When you ask a question, Claude reads relevant files. Ask about a function in src/api/users.ts, and Claude reads that file and probably the imports and types it uses.

3. Via tools. Claude can use grep to search for patterns, glob to find files, and bash to run commands that produce output. This gives the model information it can’t get from passive reading.

The first real task

Time for something concrete. Suppose your project has an Express API and you want to add a new endpoint.

> Add a GET /health endpoint that returns { status: "ok", timestamp: Date.now() }. Follow the existing patterns in src/routes/.

Notice what this prompt does:

• It describes what needs to happen (add an endpoint).
• It specifies the response (concrete, not vague).
• It refers to existing patterns (Claude needs to first look at how the other routes are structured).

Claude will now:

1. Read the contents of src/routes/ to understand the existing structure.
2. Create a new file or modify an existing file.
3. Register the route in the appropriate file.
4. Show the change and ask for approval.

That last point is crucial. Claude Code doesn’t modify files by default without your permission. It shows a diff — the proposed change — and asks if you want to apply it. You can accept, reject, or give feedback.

This is the working rhythm of Claude Code: proposal → review → accept/adjust → next step. The model does the work. You decide whether the work is correct.

What’s different now

After this first session, there’s a concrete difference from the browser workflow.

No context loss. Claude sees your entire project. You don’t have to choose which files to include.

No copy-paste cycle. Changes are written directly to your files. You don’t have to drag code back and forth between a chat window and your editor.

Direct verification. Claude can run a test to check whether the change works. In a browser chat you have to do that yourself, come back, and report.

Pattern-aware. Because Claude reads your existing code, it follows your conventions. Using camelCase? Then Claude writes camelCase. Have a specific directory structure? Then Claude places files in the right spot.

First pitfalls

Three things you’ll encounter in the first week:

Giving too little context. “Fix the bug” is a bad prompt. Claude doesn’t know which bug. “Fix the TypeError in src/api/auth.ts on line 47 — the function expects a string but receives undefined” is a good prompt. Specificity saves iterations.

Asking for too much at once. “Build a complete authentication system with login, registration, password reset, and OAuth” is too broad for a single interaction. Break it up. One endpoint per step. One feature per session. Claude Code works best in focused iterations.

Not verifying. Claude Code can run tests. Use that. Ask after each change: “Run the tests and show me if everything passes.” This prevents errors from stacking up across multiple steps.

CLAUDE.md: the beginning of project memory

One file deserves a preview: CLAUDE.md. This is a markdown file in the root of your project that Claude Code automatically reads when starting a session. You can put project-specific instructions in it:

# CLAUDE.md

## Project
This is an Express API with TypeScript. Database: PostgreSQL via Prisma.

## Conventions
- Use async/await, no callbacks
- Error handling via custom AppError class in src/errors/
- All routes in src/routes/, registered in src/routes/index.ts

## Tests
- Run tests: npm test
- Run specific test: npm test -- --grep "auth"

In part 2 we’ll go deeper into how to effectively steer Claude Code — the difference between communicating intent and dictating steps, and why that difference determines how good your results are.

This is part 1 of the series “Working with Claude Code”. The following parts appear on vicboomer.com.

Vic Boomer is an essay-led AI studio that turns ideas about AI, agents and software into clear analysis, working systems and practical tools.