Claude Code for Developers (2026): A Practical Guide

Claude Code is an agent you run in your terminal. You hand it a goal, it reads your repo, runs commands, edits files, and opens PRs. This guide is the one read that takes you from install to fluent: CLAUDE.md, slash commands, hooks, MCP, subagents, plugins, and the real workflows engineers ship with. It is built for people who want to actually use the tool well, not watch a demo. There is a copy-paste starter pack, a decision table for when Claude Code beats an IDE assistant, and a section on how teams test your fluency. Everything here is current as of June 2026.

Claude Code is an agentic coding tool. The same agent runs in your terminal, inside VS Code and JetBrains, on a desktop app, and in a browser. Whatever the surface, the core loop is the same: it reads your codebase, plans, runs shell commands, edits files across the tree, runs your tests, and can push a branch and open a pull request. You give it intent. It does the legwork.

That is a different shape from the two tools most developers already know.

A chat tool like a browser LLM has no hands. It cannot see your repo unless you paste it, cannot run your tests, and cannot edit a file. You are the copy-paste layer between the model and your code. Useful for thinking out loud, useless for shipping a multi-file change.

An autocomplete tool like an inline tab-complete assistant lives at the cursor. It predicts the next few lines while you type. Fast and tight, but it works one keystroke ahead, not one task ahead. It will not refactor twelve files or run a migration for you.

Claude Code sits above both. It operates at the task level, holds the whole repo in context, and takes actions. The default model in 2026 is Opus 4.8, the most capable model in Anthropic's Opus tier, with a large-context option (Anthropic has shipped a 1M-token context window on Claude models) for big codebases. For interactive coding it leans on a fast Sonnet-class model so it stays responsive, and you can route cheaper models to background work. If you are weighing it against an editor-first tool, our Claude Code vs Cursor comparison covers that head to head, and this guide stays focused on getting fluent with Claude Code itself.

Installation is a one-liner. On macOS or Linux:

curl -fsSL https://claude.ai/install.sh | bash

On Windows, use PowerShell:

irm https://claude.ai/install.ps1 | iex

Then start it in any project:

cd your-project
claude

For the editor surfaces, install the Claude Code extension from the VS Code marketplace or the JetBrains plugin marketplace. Both drive the same agent and share your config, so nothing you learn here is wasted when you switch surfaces.

You authenticate one of two ways. A Claude subscription (Pro or Max) logs you in and bills usage against your plan, which is the simplest path for individuals. An API key from the Anthropic console bills per token, which suits teams and automation. Both work in the same client. See the Anthropic docs for current auth details.

First-session sanity check: open a real repo, type claude, and ask it something it must read the code to answer, like "what does the auth middleware do and where is it." If it reads the right files and answers accurately, your setup is good. If it cannot find files, you are probably not in the repo root.

Two billing models, two mindsets.

A subscription (Pro or Max) gives you a flat monthly cost with usage caps. Predictable, good for steady individual work. The API bills per token with no cap, which is more flexible and more dangerous if you are not watching.

See Anthropic's pricing for current per-token and subscription rates.

The single biggest lever on your bill is model choice. Running the top model for every trivial task burns money. The rule worth internalizing: route the strong model (Opus or Sonnet) to the real coding, and route a cheap fast model (Haiku-class) to subagents and grunt work like searching, summarizing, and file triage. One cost-control rule to live by: check /cost mid-session, and if a task does not need deep reasoning, downgrade the model with /model before you run it. That one habit separates engineers who use Claude Code daily from the ones who get a scary invoice and quit.

If you do one thing from this guide, do this. CLAUDE.md is a markdown file Claude Code reads automatically at the start of every session. It is the agent's memory of your project. The difference between a session that nails your conventions and one that fights you is almost always this file.

There are two scopes. A global file at ~/.claude/CLAUDE.md applies to every project, good for personal preferences. A per-project CLAUDE.md at the repo root applies to that codebase and should be committed so the whole team shares it.

What belongs in it:

The principle that makes this work: grow it from real mistakes. Do not try to write the perfect file up front. Start minimal. Every time the agent does something wrong (wrong test runner, wrong import style, touches a file it should not), add one line that would have prevented it. After a week the file is sharp and the agent rarely misses.

In my own repos the line that paid off fastest was a single sentence pinning the package manager. The agent kept reaching for npm in a pnpm workspace, generating a stray lockfile every session; one line ("Use pnpm only, never npm or yarn") ended it for good. That is the whole loop in miniature: a recurring annoyance becomes a one-line rule, and you never see it again.

A minimal starter you can paste and adapt:

# Project: <name>

## Commands
- Install: pnpm install
- Dev: pnpm dev
- Test: pnpm test
- Lint: pnpm lint --fix
- Typecheck: pnpm typecheck

## Layout
- src/ application code
- src/components/ React components
- src/lib/ shared utilities
- tests/ test files, mirror src/ structure

## Conventions
- TypeScript strict. No `any`.
- Functional React components, hooks only.
- Throw typed errors, never bare strings.

## Definition of Done
- pnpm test, pnpm lint, pnpm typecheck all pass
- No new dependencies without flagging them
- Short PR description explaining the change

That file alone will lift the quality of everything that follows.

Slash commands run inside a Claude Code session. There are dozens, but a handful carry most of the value.

You can also write your own. Drop a markdown file in .claude/commands/ and it becomes a project command. For example, .claude/commands/review.md:

Review the current git diff. Flag bugs, missing tests, and
anything that violates CLAUDE.md. Do not edit files. Output a
short numbered list, most important first.

Now /review runs that prompt on demand, the same way every time, for everyone on the team who pulls the repo. Custom commands are how you turn a workflow you keep retyping into one word.

Hooks are the most underused feature and the one that turns Claude Code from "powerful but nervous-making" into "safe to let run." A hook is a shell command the harness runs automatically on a lifecycle event. The agent does not decide whether to run it. The harness does. That is what makes hooks trustworthy as guardrails.

The events you care about most:

Here is a PreToolUse hook that blocks the commands you never want an agent to run unsupervised. Put it in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "grep -qiE 'rm -rf|git push --force|force-with-lease|DROP TABLE|TRUNCATE' <<< \"$CLAUDE_TOOL_INPUT\" && { echo 'Blocked: destructive command' >&2; exit 2; } || exit 0"
          }
        ]
      }
    ]
  }
}

Exit code 2 blocks the tool call and feeds the message back to the agent, so it knows why it was stopped and can choose a safer path. Now rm -rf, force-pushes, and destructive SQL are off the table no matter what the model decides.

Pair it with a PostToolUse formatter so every file the agent writes comes out clean:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "pnpm prettier --write \"$CLAUDE_FILE_PATH\" 2>/dev/null; exit 0"
          }
        ]
      }
    ]
  }
}

Now formatting is not something the agent has to remember. It happens every time, automatically. Safety hook plus formatter hook is the baseline I would put in any shared repo.

MCP (Model Context Protocol) is an open standard for giving the agent tools beyond the shell and filesystem. An MCP server exposes capabilities, a database it can query, GitHub it can act on, a browser it can drive, and Claude Code calls them like any other tool.

Tools from a server show up under a clear permission namespace: mcp__<server>__<tool>. So a GitHub server's create-issue tool is mcp__github__create_issue. That naming matters because you grant or deny permissions per tool, and the prefix tells you exactly where a capability comes from.

End-to-end setup of one server, GitHub:

claude mcp add github --transport stdio -- npx -y @modelcontextprotocol/server-github

Set the auth token the server expects (a GitHub PAT in this case) in your environment, restart the session, and run /mcp to confirm the tools loaded. Now the agent can open issues and PRs and read repo metadata directly instead of shelling out to gh and parsing text.

A browser server like Playwright follows the same pattern and lets the agent navigate pages and click through flows, which is handy for testing UI changes it just wrote.

One security note worth taking seriously: MCP servers run with your permissions and can read what you point them at. Only install servers you trust, read what they do before wiring them in, and prefer first-party servers over random ones. The permission prefix is your friend here, deny anything you did not expect to see.

A subagent is a second Claude Code instance the main agent spawns to handle a focused task. It runs with its own separate context window, does the job, and reports back a summary. The parent's context stays clean.

Two reasons this matters. First, context hygiene. If the main agent reads forty files to find one function, its context fills with noise. Dispatch a subagent to do the search and it returns just the answer, keeping the main thread sharp. Second, cost and speed. Subagents can run a cheaper model (route them to Haiku) and several can run in parallel, so wide independent work finishes faster and costs less. In 2026 subagents can spawn their own subagents (recursive dispatch), which lets you fan out genuinely large tasks.

When to dispatch versus do it inline: dispatch when the work is self-contained and produces a small result (search the codebase for all callers of X, audit these files for a pattern, summarize this directory). Do it inline when the work needs the conversation's full context or when the result is the edit itself.

A worked example. You are renaming a widely-used function and want to know the blast radius first. Instead of reading every file yourself, you tell the main agent: "Dispatch a subagent to find every call site of getUserSession, including dynamic and re-exported uses, and return a list of file paths and line numbers." The subagent burns its own context grinding through the repo on a cheap model, hands back a clean list, and your main session uses that list to plan the rename without ever drowning in file contents. That is the whole point: parallelism and cheap routing without polluting the thread doing the real work. If you want the conceptual grounding interviewers probe on, our agentic AI interview questions guide covers orchestration patterns like this.

Plugins are how a team ships a whole extensibility stack as one installable unit. A plugin can bundle skills, subagents, slash commands, hooks, and MCP server configs together, so instead of asking everyone to set up five things by hand, you publish one plugin to a marketplace and people install it in a command.

The decision is simple. Keep it local when the config is project-specific and lives fine in the repo's .claude/ directory, your CLAUDE.md, project commands, and repo hooks belong with the code. Package it as a plugin when a setup is reusable across many repos or teams: a shared review command, a standard safety-hook bundle, an internal MCP server everyone needs. Local first, plugin when the same stack starts getting copy-pasted into a third repo.

Here is the full loop, every piece from this guide working together to ship one feature from scratch.

Start in plan mode. You run /plan and describe the feature: "Add CSV export to the reports page. Users click a button, get a download of the filtered rows." The agent reads the reports code, the data layer, and your CLAUDE.md, then proposes a plan: add an export endpoint, a button component, wire the filter state through, add tests. It touches nothing yet.

Turn the plan into a spec you agree on. Read the plan, push back where it is wrong ("the filter state lives in the URL, not component state"), and let it revise. Now you have a shared spec before a single line is written. This is the step juniors skip and seniors never do.

Build feature by feature, not all at once. Approve the plan and let it implement the endpoint first. It writes the code, your PostToolUse hook formats it, it runs the tests from your CLAUDE.md Definition of Done. Green, move to the button. Each slice is small enough to review.

Let the hooks enforce the rails. Your PreToolUse safety hook means it cannot do anything destructive while it works. Your formatter hook means everything comes out clean. You are reviewing logic, not nitpicking whitespace, because the harness handles the mechanical stuff.

Ship the PR. Once tests, lint, and types are green, the agent writes a branch and opens a pull request with a description of the change. You review the diff like any colleague's, then merge.

For bigger pushes, run parallel sessions with git worktrees. Create separate worktrees for independent features and run a Claude Code session in each. They do not share working state, so three features progress at once without stepping on each other. This is the pattern that makes the agent feel like a team rather than a single pair of hands. If your team leans on a fast, ship-now style, our vibe coding piece covers where that helps and where it bites.

The honest answer is you will run both. But they have different sweet spots, and knowing which is which is the actual skill.

The pattern: delegate big autonomous lifts to Claude Code, keep fast in-editor control for the IDE assistant. GitHub Copilot and similar tools win the cursor; Claude Code wins the task. The mature 2026 move is not loyalty to one brand, it is matching the tool to the work and switching without ceremony. Our Claude Code vs Cursor guide goes deeper on the head-to-head if you are choosing a daily driver.

The fastest way to look junior with Claude Code is to make these mistakes. They are all avoidable.

Letting the agent run blind. No /plan, just "build the whole feature." It guesses your intent, builds the wrong thing, and you pay tokens watching it go sideways. Plan first on anything non-trivial. Always.

No CLAUDE.md. Without it the agent re-learns your project every session, gets conventions wrong, and you spend the saved time correcting it. The file pays for itself in one afternoon.

No permission guardrails. Running with no hooks and broad permissions means one bad command can do real damage. The safety hook above takes two minutes to add and removes the worst-case outcomes.

Treating it like ChatGPT. Pasting code in and out, asking for snippets, ignoring that it can read and edit your repo directly. You are doing the agent's job for it and getting chat-quality results.

Infinite loops without checkpoints. Letting it churn on a hard problem with no commits and no review until the context is a mess and you cannot tell what changed. Work in small slices, commit at green, and use /cost to notice when a task has gone off the rails. Burning tokens on a confused agent is the most common rookie tax. The same discipline applies in a live setting, our guide on using Cursor for coding interviews drills the narrate-and-verify habit that keeps you in control under pressure.

Claude Code fluency is now something teams actively test. In interviews and on the job, they are not impressed that you can prompt an agent, anyone can. They watch how you drive it.

What they look for: do you plan before you build, do you have a CLAUDE.md and guardrails, do you route models by cost, do you review the agent's diffs critically instead of merging raw output, and can you explain why you delegated this task but did that one by hand. That last point, narrating your reasoning out loud, is the single highest-signal thing you can do. "I dropped to a cheaper model here because it is just a search, I kept the strong one for the refactor, and I planned first because it touches the data layer" tells an interviewer more than any finished feature.

The way to get fluent is reps under realistic pressure. Practice the full loop on real repos, talk through every decision as you make it, and time yourself so the workflow is automatic when it counts. Our Claude Code interview questions guide covers exactly what gets asked, so you are smooth, not scrambling, when a team is watching.

Is Claude Code free?

The tool requires a paid plan or API access. You authenticate with a Claude subscription (Pro or Max), which bills usage against your plan, or with an Anthropic API key, which bills per token. There is no fully free tier for sustained use, though a subscription you already have for other reasons covers it.

Does Claude Code replace Cursor?

No. They overlap but lead with different defaults: Claude Code delegates whole tasks from the terminal, an IDE assistant gives you tight inline control. Most productive developers run both and switch by task type. Our Claude Code vs Cursor comparison breaks down which wins where.

Is CLAUDE.md required?

Not technically, the tool runs without it. But it is the highest-leverage thing you can add. It is the difference between an agent that knows your project and one that re-guesses it every session. Treat it as required in practice.

Can Claude Code run autonomously and safely?

Yes, if you set rails. Use plan mode for anything non-trivial, add a PreToolUse safety hook to block destructive commands, scope permissions tightly, and work in small reviewable slices. Sandbox mode adds another layer by isolating what the agent can touch. Autonomy without guardrails is the risky part, not autonomy itself.

What model should I use?

Route by task. The strong model (Opus 4.8, the 2026 default, or a Sonnet-class model) for real reasoning and coding, a cheap fast model (Haiku-class) for subagents, search, and grunt work. Watch /cost and downgrade with /model when a task does not need the heavy model. Model choice is your main cost lever.

Knowing the features is half of it. The other half is driving the agent smoothly and explaining your choices out loud when a team is watching, which is exactly what gets tested now.

Interview Coder is a desktop app that helps you practice and perform under real interview conditions, with 20+ stealth features and 100K+ users. Coding answers run on Claude Sonnet 4.6, Anthropic's latest Sonnet. Plans: Free at $0, Monthly Pro at $299, and Lifetime Pro at $799 one-time. Rehearse the workflow, narrate your reasoning, and walk in ready. Full disclosure: this guide is published by Interview Coder, its own product.