Claude Code is Anthropic's command-line agent: a tool that reads your code, writes changes and runs commands, directly in your terminal. We use it daily at the agency; here is the honest getting-started guide, the one we wish we'd read before diving in.

There are tools that suggest the end of your line of code, and there is Claude Code. The difference is worth stating upfront, because it shapes everything that follows: how you install it, how you talk to it, how you supervise it. This guide is for developers and teams who want to try it seriously, without kidding themselves, either about its abilities or its limits.

What is Claude Code? An agent, not autocomplete

Claude Code is a command-line development agent: a program that runs in your terminal, to which you hand a task in natural language, and which gets to work. It explores your project, reads the relevant files, proposes changes, runs your tests, executes commands. You describe the intent, it investigates and produces a diff. Nothing like an extension that finishes your sentences as you type: this is what's called an agent, and the word is no marketing trick.

A pleasant consequence: since it lives in the terminal, it works with any editor (a VS Code extension has also existed since version 2.0 in September, but it remains optional). Under the hood, it runs on Anthropic's models: Claude Sonnet 4.5 by default since its release in late September, Haiku 4.5, faster and cheaper for simple tasks, and Opus 4.1, available on the higher-tier plans.

Installing Claude Code: three lines in your terminal

To install Claude Code, the most common path is through npm (Node.js 18 or later); a native installer with no Node dependency also exists. Three lines are enough:

On first launch, the tool asks you to authenticate: either with your Claude account if you have a subscription, or with an API key created on Anthropic's console. You're now facing a conversational command prompt, inside your project. Resist the urge to ask it for a full rewrite right away: the three habits below will make the difference between a convincing trial and a frustrated abandonment.

The three founding habits

1. Initialize a CLAUDE.md with /init

Type /init from the very first session. Claude Code then explores your repository and generates a CLAUDE.md file at the root: project architecture, build and test commands, coding conventions. This file is read again at the start of every session; it's the tool's memory, and the best lever for improving its answers. Review what it generated, correct it, add your own house rules ("never commit without explicit request" is a good start), then version it: the whole team benefits, and the file grows richer over the weeks like any living documentation.

2. Work in short, focused conversations

One session, one task. The temptation to keep the same conversation open all day is strong; it's a recipe for drift. The longer the accumulated context, the more the model scatters and mixes up topics. Phrase a precise mission ("fix the cart display bug described in this ticket", rather than "improve the cart"), let it finish, review, then start fresh with /clear. This discipline can feel constraining; it is in fact the same hygiene as atomic commits, and it produces the same effect: traceable, reversible work.

3. Review every diff, no exceptions

Treat Claude Code like a talented, fast and scatterbrained developer who just joined the team: nothing it produces enters the codebase without review. The tool shows you every change as a diff before applying it: actually read them. Git remains your main safety net, complemented since version 2.0 by internal restore points (the /rewind command lets you undo a session's changes). A safety net has never excused you from watching your step.

Permissions: friction that protects you

By default, Claude Code reads freely but asks for your approval before modifying a file or running a command. This friction is intentional: an agent that can run rm or git push is not a toy, and Anthropic chose to leave you in control of every consequential action. As sessions go by, you can loosen this framework intelligently: durably allow the harmless commands you approve ten times a day (via the /permissions command or the project's configuration file), turn on automatic acceptance of file edits when the task is well scoped, or conversely switch to plan mode, where the agent proposes a strategy without touching anything.

There's also an option that disables every safeguard. Its name starts with --dangerously, and that prefix says it all: it only makes sense in an isolated, disposable environment (a container with no access to your secrets), never on your working machine. The right trajectory is progressive: approve everything the first week, then automate only what you've watched work correctly, command by command.

How much does Claude Code cost?

Two paths, as we write this. The first: Claude subscriptions, which include access to Claude Code. The Pro plan (about 20 dollars a month) is enough to discover the tool and cover regular but measured use; the Max plans (100 or 200 dollars a month) are for those who code with it all day. Quotas work on rolling five-hour windows, topped up by weekly caps: heavy use on Pro hits the limit, which is the signal to move up a plan. The second path: pay-as-you-go API billing, with no subscription, suited to one-off trials and enterprise integration; expect a few dollars for a solid day of work, more on large repositories. Our advice for getting started: the Pro subscription, which caps the spend and removes the anxiety of watching a meter.

A word on what comes next, without rushing into it: the tool extends through custom slash commands, hooks (scripts triggered automatically before or after its actions), the MCP protocol to connect it to your services, specialized subagents, and "skills", just launched in mid-October. None of this is necessary in the first month.

The limits, honestly

  • It gets things wrong with confidence. Claude Code produces incorrect code with the same assurance as correct code: an invented API, a forgotten edge case, a test that passes for the wrong reasons. No signal tells its successes apart from its mistakes; only your review does.
  • Context isn't infinite. The working window is measured in hundreds of thousands of tokens, which is a lot and yet fills up fast on a real project. Past a certain point, quality degrades before the tool actually stops: one more reason to work in short sessions.
  • Review remains your job. The agent shifts the effort, it doesn't remove it: you write less, you review more. What ships to production under your name stays your responsibility, and no subscription plan changes that.

Where to actually start

Pick a real ticket from your backlog, neither trivial nor critical: a reproducible bug, a small, well-described feature. Install the tool, run /init, hand it the task, review the diff the way you'd review a colleague's. Do this for a week. By the end of that period, you'll know two things: what the agent does better and faster than you, and what you won't hand it yet. Both lists will shift in the months ahead, probably faster than we think; what matters is having started keeping them. That's exactly what we're doing on our end, and we'll be back here, numbers in hand, to tell you what that changes in an agency like ours.