How to use Claude Code for production engineering

Claude Code is Anthropic's terminal-first agentic coding tool. Used well, it ships features with a planning loop, a CLAUDE.md anchor, custom slash commands, MCP integrations, subagents, hooks, and tight permissions. This guide walks through every layer, in the order you should set them up.

The short version: install it, write a CLAUDE.md, use plan mode for anything non-trivial, hook in linters and tests, add MCP servers for the tools your team already uses, delegate exploration to subagents to keep context clean, and run cheaper models for batch work. Cursor still wins inside the editor for diff UX. Claude Code wins everywhere autonomy and multi-step execution matter.

Why Claude Code is different from Cursor or Copilot

Copilot completes the line. Cursor edits the file. Claude Code edits the project. It reads across folders, writes a plan, runs your test suite, reads the failure, and iterates. The right mental model is "junior engineer with shell access," not "smarter autocomplete."

That distinction shows up in how you spend your time. With Cursor, you drive every keystroke. With Claude Code, you drive the spec, the verification, and the review. The keystrokes are mostly Claude's.

For a deeper take on the editor side of this trade-off, see our Cursor for developers guide. For the broader argument about how the daily loop changes when AI writes most of the code, see what changes when you write code with AI.

Install and the first 10 minutes

Install once, globally:

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

Authenticate. From inside any repo:

cd ~/code/your-app
claude

Pick a model. For most production work in 2026, Sonnet 4.5 is the default. Use Opus for architecture or hard refactors, Haiku for batch jobs and exploration:

claude --model sonnet
claude --model opus
claude --model haiku

Run /init. This is the first thing you do in any new repo. It scans the codebase, detects build and test tooling, and generates a starter CLAUDE.md. You then prune it.

CLAUDE.md: the most important file in your repo

CLAUDE.md is loaded at the start of every session. Every line is a permanent prompt. If it bloats, Claude starts ignoring it, which means each line earns its place. Here is a real one for a Next.js + Supabase project:

# Build & test
- pnpm dev runs the local server on :3000
- pnpm test runs vitest. Run `pnpm test path/to/file` for one file
- pnpm typecheck must pass before any commit
- Never run `pnpm build` unless asked. It's slow.

# Code style
- TypeScript strict. No `any` without a comment justifying it
- Server components by default. `"use client"` only when needed
- Tailwind utility classes. No inline styles. No CSS modules
- Supabase RLS is on for every table. Always write the policy in the same PR

# Workflow
- Before editing, read the related test file
- After editing, run typecheck and the affected test
- Commit messages: type(scope): summary. No body unless non-obvious

# Gotchas
- `lib/db/index.ts` is server-only. Never import it from a client component
- We use `next-safe-action` for mutations. Don't write raw API routes

Six rules, two gotchas, three commands. That's it. The bad version of this file lists every npm script, restates "write clean code," and explains the folder structure Claude can already see. Cut all of that.

For monorepos, drop a smaller CLAUDE.md inside each package. Claude pulls them in on demand when it works in that subtree. For personal preferences that shouldn't ship to your team, use CLAUDE.local.md and gitignore it.

Plan mode: the loop that prevents wasted work

Plan mode is the most underused feature. Press Shift+Tab until the indicator says "plan." In this mode, Claude reads files and proposes a plan. It writes nothing.

The pattern that works:

1. In plan mode, ask: "Read src/auth and propose a plan to add Google OAuth. List every file that changes and the new session flow."
2. Press Ctrl+G to open the plan in your editor. Annotate where Claude is wrong, in line.
3. Send back: "Address all my notes. Don't implement yet."
4. Repeat until the plan is right.
5. Exit plan mode. "Implement the plan. Write tests for the callback handler. Run the suite and fix failures."

Skip plan mode for one-line fixes. Use it for anything that touches more than two files or modifies code you don't fully understand. The five minutes you spend planning saves the hour you'd spend correcting a half-finished implementation in the wrong place.

Custom slash commands

Slash commands are markdown files Claude executes as prompts. Put them in .claude/commands/ for the team, or ~/.claude/commands/ for personal use. Each file becomes a /name command.

Example: .claude/commands/fix-issue.md

---
description: Fix a GitHub issue end-to-end
allowed-tools: Bash, Edit, Write, Read, Grep
---
Fix GitHub issue #$ARGUMENTS:

1. Run `gh issue view $ARGUMENTS` to read the issue
2. Search the codebase for files that match the symptom
3. Write a failing test that reproduces the bug
4. Implement the fix
5. Run `pnpm test` and `pnpm typecheck`
6. Commit with `fix(scope): summary (closes #$ARGUMENTS)`
7. Open a PR with `gh pr create`

Run it: /fix-issue 412. Claude follows the steps. Build a small library of these for the workflows your team repeats: /spike, /migration-step, /post-mortem, /rls-policy. Each one removes a paragraph of explanation from every prompt.

MCP servers: the integrations that actually matter

MCP (Model Context Protocol) is how Claude Code talks to external systems. The three servers worth installing on day one:

Server	Why it matters	Install
GitHub	Read issues, open PRs, post comments, fetch CI logs	claude mcp add github (or use gh CLI as a fallback)
Linear	Pull tickets straight into the planning prompt	claude mcp add linear
Slack	Reply to alerts, summarize threads, post deploy notes	claude mcp add slack

After that: a database MCP for query work, Sentry MCP for error triage, Figma MCP if you build UI from designs. The principle is the same in every case: the MCP saves Claude from copy-pasting context out of another tab. A Linear ticket fetched via MCP is one tool call. A Linear ticket pasted by hand is three exchanges and the chance you forgot the acceptance criteria.

Allowlist them in .claude/settings.json:

{
  "permissions": {
    "allow": ["mcp__github", "mcp__linear", "mcp__slack__read_thread"]
  }
}

Subagents: keep your main context clean

Subagents run in their own context window with their own tool set. They explore, summarize, and report back. Your main session never sees the file dump.

Two ways to use them. First, ad hoc, in any prompt: "Use a subagent to find every place we call getUser and report what each call site expects." Claude spawns a subagent, reads twenty files, and returns three sentences.

Second, define them in .claude/agents/ for repeat tasks:

---
name: security-reviewer
description: Reviews diffs for security issues
tools: Read, Grep, Glob, Bash(git diff:*)
model: opus
---
You are a senior security engineer reviewing a diff. Look for:
- SQL injection, XSS, command injection
- Auth/authz bypasses
- Secrets in code or logs
- Unsafe deserialization

Report findings with file:line references and concrete fixes.

Trigger it with: "Use the security-reviewer subagent on the current diff." It runs on Opus while your main session stays on Sonnet. You get the smart review without paying Opus rates for the rest of the work.

The Writer/Reviewer pattern is the most valuable use. Session A implements. Session B (fresh context, no bias toward what was just written) reviews. Session A applies the feedback. This catches more bugs than either session alone.

Hooks: the safety net you don't have to remember

Hooks are deterministic scripts that fire on specific events. Unlike CLAUDE.md instructions, which are advisory, hooks always run. Configure them in .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npx prettier --write \"$FILE_PATH\"" }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": ".claude/hooks/block-dangerous.sh" }
        ]
      }
    ]
  }
}

The Prettier hook means Claude can never leave unformatted code. The PreToolUse hook can block rm -rf, git push --force, drops to prod databases, anything else you'd hate to recover from. A 20-line shell script in .claude/hooks/ can prevent the entire class of "Claude did something I'd never have approved" stories.

Other useful hooks:

• Run pnpm typecheck after every edit to a .ts file
• Append a Slack notification on Stop so you know a long agent session finished
• Block writes to migrations/ unless a flag file is present

Permissions: stop clicking "approve"

By default, Claude asks before every write or shell command. This is safe for the first hour and tedious by hour two. Three ways to scale it down:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Read", "Glob", "Grep",
      "Bash(pnpm:*)", "Bash(git:*)", "Bash(gh:*)",
      "Edit(src/**)", "Write(src/**)"
    ],
    "deny": [
      "Read(.env*)", "Read(secrets/**)",
      "Bash(rm -rf:*)", "Bash(sudo:*)",
      "Edit(package-lock.json)", "Bash(git push --force:*)"
    ],
    "ask": ["WebFetch", "Bash(curl:*)", "Bash(docker:*)"]
  }
}

For longer autonomous runs, switch to auto mode (Shift+Tab cycles, or claude --permission-mode auto). A classifier model reviews each action and blocks anything risky while letting routine work proceed. This is the mode you use for "fix all the lint errors" or "run this migration script across 80 files."

CI integration: Claude in non-interactive mode

The -p flag runs Claude headless. This is how you put it in pipelines, pre-commit hooks, or batch jobs:

# In a pre-commit hook
claude -p "Review the staged diff. If you see secrets, exit 1." \
  --allowedTools "Read,Bash(git diff:*)"

# In CI, generating release notes
claude -p "Summarize commits since the last tag in CHANGELOG.md format" \
  --output-format json > release-notes.json

# Batch refactor across 200 files
for file in $(rg -l 'oldApiCall' --type ts); do
  claude -p "In $file, replace oldApiCall with newApiCall. Update tests." \
    --model haiku \
    --allowedTools "Edit,Bash(pnpm test:*)"
done

Pair --allowedTools with --model haiku for batch work and your token bill stays sane.

Cost optimization: where the money actually goes

Claude Code is metered on tokens. The big costs come from three places:

1. Files Claude re-reads. A 2,000-line file read three times in a session is 6,000 lines of context. Use subagents for exploration so the file content never enters your main window.
2. Long sessions. Past 100k tokens, performance drops and cost climbs. Run /clear between unrelated tasks. Use /compact <focus> to keep what matters.
3. Opus for everything. Opus is great for architecture and tricky bugs. It's expensive for "rename this variable." Default to Sonnet, escalate to Opus on hard problems, drop to Haiku for batch and exploration.

Concrete moves that cut cost 30 to 50 percent:

• Set CLAUDE_CODE_SUBAGENT_MODEL=haiku so subagents explore cheap.
• Add a /btw for side questions that don't need to enter context.
• Tell Claude in CLAUDE.md to prefer running single test files, not the full suite.
• Use claude --resume to pick up an existing session instead of re-loading context from scratch.

For a broader comparison of which AI tool to reach for when, see our roundup of the best AI coding tools for senior engineers.

Claude Code vs Cursor: the honest comparison

Cursor wins on diff UX. The inline suggestion, the "accept/reject" flow on a multi-file edit, the way Cmd+K reads selected code: that loop is faster than anything terminal-based for tasks where you're driving every keystroke.

Claude Code wins on autonomy. Plan mode, subagents, hooks, headless -p, MCP across your stack, and the model's willingness to keep iterating against a test suite without a human in the loop. For work that's bigger than a single file edit, this matters more than diff UX.

The right answer is both. Cursor for the IDE flow. Claude Code in a second terminal for "go fix this" tasks, batch refactors, CI hooks, and anything that needs to run across more than one file. Most senior engineers in 2026 keep both open. We have an honest read on the editor side in our Cursor IDE pros and cons review.

For the verdict-style review of Claude Code itself (where it shines, where it frustrates), see our companion review post.

What "production-ready" actually looks like

Stitch the layers together and your repo has:

• A 30-line CLAUDE.md with build commands, style rules, and gotchas
• Five custom slash commands for the workflows your team repeats
• Three MCP servers wired up: GitHub, Linear, Slack
• Two subagents defined: a reviewer and an explorer
• Two hooks: format on edit, block dangerous shell commands
• A .claude/settings.json with allow/deny lists tuned to your stack
• Headless Claude in your pre-commit and a nightly batch job for cleanup

That setup takes a senior engineer about a day to put in place. After that, every Claude Code session in the repo starts from a productive baseline. New engineers benefit from the same setup on day one without having to learn the lore.

What every Cadence engineer already does

Every engineer on Cadence is AI-native by default. The voice interview specifically scores Cursor, Claude Code, and Copilot fluency, prompt-as-spec discipline, verification habits, and multi-step prompt-ladder thinking. There is no non-AI-native option on the platform. If you're a founder evaluating talent, you can read more about what AI-native engineering actually means and why we replaced our text interview with voice.

If you're picking your next feature and aren't sure whether to build it yourself with Claude Code, buy a SaaS, or book an engineer to ship it for you, run it through our Build/Buy/Book decision tool. Three questions, one recommendation, no pitch.

Try it. Stand up the CLAUDE.md, the two hooks, and the GitHub MCP today. Tomorrow morning, ask Claude to ship one ticket end-to-end. If you'd rather skip the setup and have a vetted engineer do it, book a senior on Cadence for $1,500 a week with a 48-hour free trial.

FAQ

Is Claude Code free?

No. Claude Code is metered on tokens via your Anthropic API key or a Claude.ai Max plan. Most production users on Sonnet spend $40 to $200 per engineer per month. Heavy Opus users spend more. Setting CLAUDE_CODE_SUBAGENT_MODEL=haiku and reaching for Sonnet by default keeps the bill predictable.

How is Claude Code different from Cursor?

Cursor is an IDE fork (VS Code plus AI features) optimized for the in-editor diff loop. Claude Code is a terminal agent optimized for multi-step autonomous work: planning, running tests, calling shell tools, reading across the repo. Most senior engineers run both: Cursor for typing code, Claude Code for shipping tasks.

Can Claude Code run unattended in CI?

Yes. Use claude -p "prompt" --allowedTools "Edit,Bash(pnpm test:*)" --permission-mode auto in a CI job or pre-commit hook. The --output-format json flag gives you parseable output. Pair with a tight allowedTools list so a misfire can't escalate.

What are the must-have MCP servers for production?

GitHub (issues, PRs, CI logs), Linear or Jira (tickets), and Slack (alerts and async comms). Add a database MCP if you do query work, Sentry for error triage, and Figma if you build UI from designs. Each MCP saves an entire copy-paste round trip per session.

Should I use Claude Code or hire an engineer?

Both. Claude Code amplifies an engineer who knows the codebase. It doesn't replace the judgment, the architecture decisions, or the production instincts. If you don't have the engineer yet, every Cadence engineer is AI-native and will arrive on day one with their own CLAUDE.md, hooks, and slash-command discipline already configured.