How to Use Claude Code: From First Install to Shipping Real Features (2026)

How to Use Claude Code: From First Install to Shipping Real Features (2026)

I've been using Claude Code at work for months, shipping production features into a system that handles millions of candidate interactions a week. It's earned the trust on code where a mistake actually costs something.

This guide takes you from install through to autonomous agents working in parallel worktrees, with a reviewer agent critiquing the diff before you merge.

Here's the path from zero to productive.

Install and First Session

Install takes 30 seconds. You need a Claude Pro, Max, or API account. The standalone installer is the recommended path in 2026 because it sidesteps the Node permissions issues that plagued the npm package:

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

If you'd rather stay on npm (Node.js 18+ required), the package is still published:

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

Run claude in any project directory. That's it. You're in an interactive session.

Type a natural language prompt. Something like "build me a simple landing page for a coffee shop" or "make me a personal portfolio site with a contact form". Claude scaffolds the project, writes the files, and tells you how to run it. No config files needed for your first session.

The first thing most people get wrong is watching it work. Hand it the task, go make coffee, come back and review what it shipped. Treat it like an agent. Give it a clear brief, let it run, and judge the result.

The Questions Everyone Asks

Can anyone use it? You need a Claude subscription or API access. It runs in your terminal, VS Code, JetBrains, or the desktop app. Linux, macOS, and Windows via WSL.

Is it good for beginners? If you can't read code, you can't review what it produces. Claude Code generates code. You still need to know if that code is correct. If you're comfortable writing code but overwhelmed by the AI tooling landscape, that's the sweet spot.

How do you prompt it? Like you'd brief a senior engineer. "Add rate limiting to the /api/users endpoint. Use a sliding window algorithm. Write tests." Specific. Contextual. Outcome-focused. Vague prompts produce vague results.

Should you pay for it? Yes (and try to get your employer to cover it, that's pretty common now for anyone shipping software professionally). If you're paying out of your own pocket, I'd pair it with a cheaper alternative so you're not stuck on one bill. That's what I do personally: Claude Code for the integrated workflow at work, plus a cheaper agent on the side for everything else. The pricing model itself changed materially in 2026. Autonomous work now draws from a separate monthly credit, which I broke down in detail in Claude Code Pricing 2026: Autonomous Credits and What Changed. Read that before picking a plan.

If you're still deciding between Claude Code and the alternatives, Pi vs Claude Code: Which AI Coding Agent in 2026 walks through the trade-offs.

Those basics will get you running in 5 minutes. But running isn't the same as shipping.

The difference between someone who installed Claude Code and someone who ships with it comes down to five patterns that aren't in the getting-started docs.

Every Tuesday I send a weekly breakdown of how I actually use these patterns at work. No fluff. Just what shipped and what broke.

Keep Your CLAUDE.md Lean

CLAUDE.md is a markdown file Claude reads at the start of every session. It's powerful, which is exactly why most people misuse it.

Run /init in your project and Claude generates a starter file from your codebase. Then resist the urge to keep piling on.

The instinct is to dump everything Claude might possibly need into CLAUDE.md. Build commands, test instructions, coding conventions, a tour of the repo. That's a mistake. Every line in CLAUDE.md is loaded into every session and competes with your actual task for context. Bloated CLAUDE.md files quietly degrade the quality of every answer you get back.

The leaked Apple CLAUDE.md from one of their large internal projects was only around 30 lines. That's the bar. If a rule isn't load-bearing across most of your sessions, it doesn't belong in there.

What actually earns a spot in CLAUDE.md:

• Constraints that change Claude's behaviour fundamentally ("never introduce a new database table without raising it first")
• Conventions Claude can't infer from the code itself (a non-obvious naming rule, a domain term that means something specific in this repo)
• A short pointer to where things live if your repo layout is unusual

What doesn't belong:

• "Run pnpm test before committing". That's a hook, not a CLAUDE.md line.
• One-off setup steps.
• Long explanations of how the codebase ended up this way.

The files are layered across scopes. ~/.claude/CLAUDE.md holds global rules. ./CLAUDE.md committed to git holds project rules. A gitignored ./CLAUDE.local.md holds your personal overrides. In a monorepo, child directories get their own CLAUDE.md files that load on demand when Claude reads files in those paths. Use the layering to keep each individual file short.

Context degradation is the primary failure mode in Claude Code. Treat CLAUDE.md like a constitution, not a wiki.

Use Plan Mode by Default

Plan mode separates thinking from doing. Claude generates a step-by-step plan for your review before it writes a single line of code.

Set it as your project default:

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "plan"
  }
}

When the plan is ready, you get options. Approve and start in auto mode (autonomous execution with a safety classifier). Approve and accept edits (silent file changes, but prompts for commands). Approve and review each edit manually. Or keep planning with feedback.

For anything beyond trivial changes, plan mode is non-negotiable. I've seen Claude produce a beautiful plan that revealed a fundamental misunderstanding of the data model. Catching that before execution saved a painful rollback.

The "Ultraplan" option opens the plan in a browser-based view for complex tasks. You can also press Ctrl+G to edit the plan directly in your text editor before Claude proceeds.

Plan first. Execute second. This is the pattern that separates engineers who trust the tool from engineers who fight it.

Run Subagents and Agent Teams

Here's where Claude Code stops being a fancy autocomplete and starts being a force multiplier.

A subagent is a specialist. You define it in a markdown file with YAML frontmatter that specifies its name, tools, model, and permission mode. A code reviewer that only has read access. A debugger with write and bash permissions to reproduce and patch issues. A security auditor running on Opus with read-only tools to catch subtle patterns.

The key principle is least privilege. Your code reviewer doesn't need write access. Your security auditor doesn't need bash. Each subagent gets the minimum tools required for its role.

The pattern that scales on a team is checking those subagent definitions into the repo. Anyone who clones the project gets the same code reviewer, the same security auditor, the same permission boundaries, with no setup ceremony.

For coordinated work, agent teams let multiple Claude sessions coordinate as peers. Claude acts as a team lead, spawning teammates, assigning tasks, and supervising execution. Teammates share a task list and message each other directly.

Use subagents when you need to delegate isolated tasks (a code review, a security scan). Use agent teams when the parallel workers need to coordinate with each other (a cross-service refactor, a feature crew working across multiple packages).

Isolate Parallel Work with Git Worktrees

This is probably the most important pattern in the whole article. The real unlock with agents is running several of them in parallel, on independent tasks, with no shared state to fight over. Worktrees are what make that possible.

Each concurrent Claude session or subagent runs in its own separate git worktree. No edit collisions. No merge nightmares. No agents stepping on each other's branches.

For subagents, add isolation: worktree to the frontmatter. Each subagent gets a temporary worktree that's automatically removed when it finishes without changes. If changes were made, the worktree is preserved with its path and branch name for your review.

One thing that catches people: a worktree is a fresh checkout. Your .env files aren't there. Create a .worktreeinclude file in your project root to copy necessary gitignored files into each new worktree:

.env
.env.local
config/secrets.json

This applies to all worktrees, whether created manually, by subagents, or through the desktop app.

I run a personal Skill for worktree setup so every new worktree comes up exactly how I want it: env files copied, dependencies installed, branch named the way I want, a draft PR opened. Writing that skill is a 30-minute investment that pays back every single time. The friction of "spin up a worktree, configure it, then start the agent" is what stops most people from running parallel work at all.

The other half of making this work is visibility. Once three or four agents are running in parallel, a plain terminal stops being enough. You lose track of which agent is waiting on input, which one finished, which one broke. I use a multiplexed agent terminal (something like CMUX) that gives me real notifications and a single view across every parallel session. That's the difference between worktrees being a neat trick and worktrees being how you actually work.

The combination of subagents plus worktrees plus a proper agent terminal is what enables the "walk away and come back to finished work" pattern. You describe the tasks, each agent works in isolation, and you review the results when they ping you.

Review What It Shipped

If you take one thing away from this article, take this one. Review is what makes Claude Code productive at any scale. The discipline is review, review, review.

The setup I run at work is layered, and each layer catches things the others miss.

First pass: an automated reviewer like CodeRabbit or Greptile runs against the PR as soon as it opens. I get a structured breakdown of the diff, suggested fixes, and a list of the things they flag as risky. That's my first scan before I look at any code.

Second pass: I send the diff to Claude Code as a fresh review session. New chat, no memory of how the code got written, only the diff. Claude reasons at a different layer than CodeRabbit, more architecture and intent, less syntactic pattern matching, so it catches different things.

Third pass: I open the PR in GitHub and review it myself. GitHub's PR view is built for this. Inline comments, file-by-file navigation, the ability to request specific changes. That's where my actual feedback lives, and that's where I leave it for the agent (or a teammate) to act on.

A few specifics on the Claude Code review pass. You can spawn it as a read-only subagent with a fresh context. Give it only the git diff and an adversarial brief: find risks, gaps, and problems. Because it lacks the original authoring context, the review is genuinely independent in a way the authoring agent can't replicate.

The desktop app has a built-in "Review code" button that examines your local diffs and leaves inline comments. You can also enable auto-fix (Claude attempts to repair failing CI checks) and auto-merge (Claude merges the PR once all checks pass). I leave auto-merge off. The whole point of this section is that review is the part you keep.

For CI/CD pipelines, run Claude in headless mode with claude -p "your prompt" and --output-format stream-json for machine-readable output. Keep permissions conservative. Use --allowedTools to restrict what Claude can do when running unattended.

Skills: The Second Big Leverage Pattern

After review, Skills are the next big unlock. They turn repeatable procedures into versioned, governed commands you can call by name.

Mechanically, a skill is a SKILL.md file in your .claude/skills/ directory with instructions and YAML frontmatter. The frontmatter controls behaviour. A description field helps Claude decide when to use the skill automatically. Set disable-model-invocation: true so it only runs when you explicitly type /skill-name. Use allowed-tools to restrict which tools the skill can access. Set context: fork to run it in an isolated subagent.

Start with skills other people built, not your own

If you're new to Claude Code, hold off on writing your own skills for a while. You don't yet have the muscle memory to know what's actually worth turning into a skill, and the result is usually a folder of half-useful files that get ignored.

The better starting move is to install someone else's. Head to skills.sh, browse the trending skills, pick the ones that match what you actually do every day, and use them for a week. After a week you'll have a clear sense of what's missing for your own workflow, and that's when writing your own starts paying off.

A few I keep installed:

• Matt Pocock's skills package is what I reach for most. The Superhero skills and the engineering-principles set are excellent. Senior-engineer-grade defaults baked into commands.
• grill-me is great because it forces alignment before it does anything. It asks you questions until it's sure it understands the task, which catches a lot of "Claude went off and built the wrong thing" failures before they happen.

There are dozens more on skills.sh worth trying.

My own skills

I keep my personal skills on GitHub: github.com/Alexanderdunlop. Worth a browse if you want a working set built around the workflow in the rest of this article (worktree setup, PR review, CLAUDE.md hygiene). Fork them, modify them, drop the ones that don't fit.

Once you reach the stage where you're writing your own, the point of Skills is that they replace the "I'll just tell Claude what to do each time" pattern with something that's shared, versioned, and improvable.

What This Looks Like in Practice

The blueprint I run pulls every pattern above into a single workflow.

A short CLAUDE.md sets the constitutional rules for the repo. Plan mode is the default, so every non-trivial change starts with a plan I approve before any code gets written.

Most real work happens across multiple worktrees. A personal worktree-setup Skill spins each one up with env files copied, dependencies installed, and a draft PR opened. A multiplexed agent terminal gives me notifications across every parallel session, so I can keep three or four agents working at once and still know which one finished, which one's waiting, and which one broke.

Subagents handle the specialised passes. A code reviewer with read-only tools on Sonnet for speed. A security auditor on Opus for depth. Both checked into the repo so the rest of the team gets the same setup with zero ceremony.

Review is layered. CodeRabbit runs first against the PR. A fresh Claude Code session reviews the diff next. I do my own pass in the GitHub PR view last, and that's where my feedback lives.

Skills carry the patterns I use most. Worktree setup, PR review, release prep. Most of the high-leverage ones I didn't write myself. They came from skills.sh and Matt Pocock's package.

This is what I run every day on a system serving millions of interactions a week. The tooling has matured into infrastructure.

From Productive to Production-Ready

This guide took you from installation to a production workflow. A lean CLAUDE.md. Plan mode by default. Subagents and worktrees for parallel work without collisions. A layered review pass. Skills for the patterns you reach for over and over.

Knowing the patterns and building AI products end-to-end are different things.

I'm building a course called Ship With AI that takes you from "I've heard of Claude Code" to "I built and deployed a full product in a weekend." It covers how LLMs actually work under the hood (so you know why certain prompts fail), how to think like an AI product engineer, and the full workflow I use to ship, review, and deploy with Claude Code and other AI coding agents.

If you write code and want a structured path to shipping AI-native products, this is for you.