Claude Code is not a tool you install and use casually. It is a terminal-based coding agent that rewards investment — in configuration, in prompting technique, in workflow discipline. Teams who use Claude Code well ship measurably more code than teams who use the same underlying model through a chat interface. This guide is a practical playbook for using Claude Code like a senior developer, based on how experienced users actually configure and operate it in 2026. It covers the mental model, the configuration that matters, prompts that work, slash commands and subagents that compound value, hooks that prevent disasters, and the team patterns that turn individual productivity into engineering throughput.
The right mental model
The single most important shift when using Claude Code effectively: treat it like a very fast, very capable, very forgetful junior developer — not like a search engine. Give it a task description. Provide relevant context. Review its proposals before approving. Let it execute. Review the diff. Iterate.
Users who treat Claude Code as an oracle (ask a question, expect a magic answer) get mediocre results. Users who treat it as a teammate (brief it clearly, let it work, review carefully) get remarkable results. This framing matters more than any configuration detail.
Claude Code has no memory across sessions by default. Every conversation starts fresh. This is why CLAUDE.md and project context matter so much: they are how you brief your forgetful-but-brilliant junior every single morning.
CLAUDE.md: the most important file in your repo
CLAUDE.md is a markdown file at your project root that Claude Code reads automatically on every session. It is the persistent briefing document for the agent. Invest in it.
A good CLAUDE.md includes: project overview (what does this code do), architecture (major modules, how they relate), conventions (naming, testing, commit style), key commands (how to run tests, how to build, how to deploy), and gotchas (common mistakes to avoid, legacy quirks to respect).
A bad CLAUDE.md is empty or contains only auto-generated content. A bad CLAUDE.md means every session starts with Claude Code exploring your codebase from scratch, which wastes tokens and produces worse results.
Think of CLAUDE.md as onboarding documentation for a new developer who will read it every time they start work. Keep it under 500 lines, refresh it periodically, and put the highest-leverage information first.
Subagents: specialised helpers on demand
Subagents are specialised Claude Code configurations you can invoke for specific tasks. Each subagent has its own system prompt, its own tool permissions, and its own purpose.
Common useful subagents: a "code-reviewer" for PR review workflows; an "explore" agent for fast codebase research without making changes; a "test-generator" for writing tests to spec; a "debugger" specialised for bug investigation with broader tool access.
The value of subagents is twofold. They let you bring specialised context (different system prompts) to different tasks without re-explaining every time. And they let you constrain permissions per task — the explore agent does not need file-write access, for example.
Invest an hour in configuring a few subagents for your team's common patterns. They compound value every time you use them.
Slash commands: the shortcut layer
Slash commands are named prompt templates you invoke like "/review" or "/fix-tests." They take a short input and expand into a detailed prompt with project-specific context.
Good slash commands for a typical team: "/review" for reviewing the current branch or a specific PR; "/test" for running tests and fixing failures; "/refactor" for a standard refactor workflow; "/commit" for generating a commit message from the current diff; "/security-review" for running security-focused analysis.
Each slash command is a markdown file in your .claude/commands directory. You write the template once, and anyone on the team can invoke it. This is how individual prompting knowledge becomes team productivity.
Hooks: the guardrails that prevent disasters
Hooks are programmable triggers that run on specific events: PreToolUse (before a tool is invoked), PostToolUse (after a tool completes), Stop (when Claude Code finishes), SubagentStop (when a subagent finishes). Hooks can block actions, log events, or trigger downstream automation.
The most useful hooks in practice: a PreToolUse hook that denies dangerous commands (rm -rf, force-push, drop-table SQL patterns); a PostToolUse hook that runs your linter after file edits; a Stop hook that runs tests before the session ends; a notification hook that alerts you when a long task completes.
Hooks are the difference between trusting Claude Code with real work and constantly supervising it. A well-configured hooks setup lets you give the agent broader latitude without fearing an unrecoverable mistake.
Prompting technique for Claude Code
Claude Code responds best to specific prompting patterns.
State the goal explicitly. "Add a new endpoint at /api/users/:id/preferences that returns the user's preferences" is better than "add a preferences endpoint." Specificity reduces drift.
Provide constraints. "Use the existing repository pattern in the auth module. Write a test for every new function. Update the OpenAPI spec." Constraints upfront are much more reliable than corrections later.
Point at relevant files. "Look at src/auth/user-service.ts for the pattern to follow." Saves tokens and reduces the chance of drift to unrelated patterns.
Ask for a plan before action. For complex tasks, "Propose a plan before making any changes" is invaluable. Review the plan, adjust, then approve execution.
Iterate in short cycles. Rather than one massive prompt with 15 requirements, give two or three requirements at a time and iterate. This produces higher-quality results and catches drift early.
Use the scratch file pattern. Keep a markdown scratch file in the repo with your evolving task description. Update it as you refine the request. Claude Code reads it and you maintain source-of-truth for what you want.
Workflow: feature development
A typical Claude Code feature-development workflow.
1. Write a one-paragraph feature description in a scratch file. Include user stories, acceptance criteria, and any specific technical constraints.
2. Run Claude Code with "Please read feature-spec.md and propose a plan." Review the plan. Iterate until satisfied.
3. Approve plan execution: "Implement the plan, write tests for each new function, and run the test suite."
4. Review the proposed diff carefully. Pay special attention to files Claude Code touched that were not in the feature spec.
5. Approve file writes. Claude Code runs tests and reports results.
6. If tests fail or you need adjustments, iterate with specific feedback: "The error handling in X is too aggressive, relax it." Do not rewrite the whole thing; target specific changes.
7. Commit with Claude Code's help: "/commit" invokes a slash command that generates a message from the diff.
This workflow routinely completes small-to-medium features in 30-60 minutes that would take hours by hand. But only if you review carefully. Blind trust is the failure mode.
Workflow: bug fixing
Bug investigation with Claude Code.
1. Reproduce the bug. Capture the failing test, error message, or stack trace.
2. Start a Claude Code session with "Here is a failing test: [paste]. Investigate the root cause before proposing a fix."
3. Let Claude Code read related files, propose hypotheses, and test them. This exploratory phase is where Claude Code shines compared to guess-and-patch approaches.
4. Once root cause is identified, request a minimal fix: "Propose the smallest change that fixes this without touching unrelated behaviour."
5. Review the diff. Run the failing test plus a broader test suite. Commit.
This disciplined bug-fix workflow — reproduce, investigate, minimal fix, verify — is how Claude Code should be used on real bugs. Shortcutting it produces bug fixes that introduce new bugs.
Workflow: code review
Using Claude Code for PR review.
1. Check out the PR branch locally.
2. Invoke your "/review" slash command, which runs Claude Code with a review-focused prompt.
3. Claude Code reads the diff, surfaces concerns: style issues, potential bugs, unclear logic, missing tests, security concerns.
4. Review Claude Code's comments. Some will be valid; some will be false positives. Use your judgement.
5. Post the valid concerns to the PR as comments, alongside your own human review.
This pattern combines human judgment with AI thoroughness. The AI catches mechanical issues you might miss; you catch architectural and intent issues the AI will not understand.
Cost management
Claude Code can rack up API costs quickly on heavy agent use. A few cost-management patterns.
Use Sonnet by default, not Opus. Sonnet handles most Claude Code work well and costs a fraction of Opus. Reach for Opus only on hard tasks.
Keep CLAUDE.md concise. Every token in CLAUDE.md is sent on every request. A bloated briefing document is an ongoing cost.
Use extended thinking selectively. Reasoning mode is powerful but expensive. Enable it for genuinely hard planning steps, not routine ones.
Monitor usage. Set up cost alerts via the Anthropic console. A runaway session loop can burn through a budget faster than you notice.
Cache what you can. The Anthropic API supports prompt caching, and Claude Code uses it where possible. Structuring prompts so cache hits are likely is worth the effort.
Team patterns
Using Claude Code at team scale.
Shared CLAUDE.md in repo. Everyone on the team gets the same briefing. Keep it in source control, update via PRs like any other file.
Shared slash commands. Configure them in .claude/commands, commit to the repo, and everyone uses the same shortcuts. Individual knowledge becomes team knowledge.
Shared hooks. Guardrails should be team-wide. A security hook that denies dangerous commands should apply to everyone, not just the engineer who configured it.
Agreed review bar. Decide as a team how carefully Claude Code diffs should be reviewed. "Skim-check if tests pass" is a different standard from "line-by-line review every change." Neither is inherently right; pick based on your risk tolerance.
Usage norms. Some teams prohibit Claude Code on certain files (security-critical code, database migrations). Others allow it everywhere but require human approval for specific file patterns. Set these norms explicitly.
Common mistakes and how to avoid them
Patterns seen across teams adopting Claude Code.
Skipping CLAUDE.md. The single biggest mistake. Without a good CLAUDE.md, Claude Code wastes time re-exploring your codebase on every session and produces worse results. Invest an hour in writing one; it pays back daily.
Accepting diffs without review. Even good Claude Code diffs occasionally contain subtle bugs, unnecessary changes, or stylistic drift. Always review.
Over-broad tool permissions. Giving Claude Code unrestricted shell access and filesystem access can lead to expensive mistakes. Use hooks to constrain what it can do.
Ignoring test failures. If Claude Code's proposed change fails tests, investigate before forcing through. A test failure often indicates a real problem.
Using Opus for everything. The cost differential is dramatic and often unjustified. Sonnet is the right default.
No observability. Without logging, you cannot diagnose failures or understand usage patterns. At minimum, log every Claude Code command and its outcome.
Onboarding new teammates to Claude Code
When a new engineer joins a team already using Claude Code, their learning curve matters. Some patterns that accelerate onboarding.
Pair them with an experienced Claude Code user for their first week. Watching someone use the tool well is more educational than reading documentation.
Have them start with narrow tasks: a single-file refactor, a new test, a bug fix in one module. Broader tasks require more skill at scoping the prompt and reviewing the diff.
Walk through CLAUDE.md, slash commands, and hooks as onboarding. Understanding the team-wide configuration accelerates individual effectiveness.
Share your team's prompt patterns — the specific phrasings and structures that work well in your codebase. Every team develops its own prompting folklore; making it explicit helps new hires.
Set a baseline expectation: in the first month, every Claude Code diff should be reviewed very carefully. After a month, the new engineer has developed enough intuition to review quickly. This phased trust approach prevents mistakes while building skill.
When Claude Code is the wrong tool
An honest accounting of when to reach for something else.
For inline completions while typing, Claude Code is not the tool; GitHub Copilot or Cursor's inline suggestions are. Claude Code is a batch agent, not an inline completer.
For tiny fixes (typo, one-line change), Claude Code's overhead (session setup, briefing, review) is not worth it. Just fix it yourself.
For highly interactive work like live debugging with a debugger, Claude Code does not fit naturally. Use your IDE's debugging tools directly.
For tasks where the codebase is too unfamiliar for you to review the diff, Claude Code is risky. You need enough knowledge to catch its mistakes; if you lack that, pair-program with a human first.
For tasks involving significant judgment — architectural decisions, API design, product direction — Claude Code can help draft but should not be trusted to decide. Keep humans in charge of judgment calls.
Advanced techniques
A few patterns for experienced users.
Agent chains. Use subagents sequentially — explore agent surveys the code, review agent critiques the proposed changes, commit agent writes the commit message. Each specialised, each doing one thing well.
Test-driven Claude Code. Write failing tests first, then run Claude Code with "Make these tests pass." This constrains the problem well and produces high-quality focused changes.
Constitutional prompts. Include project-specific rules in CLAUDE.md as explicit principles: "Never use any in TypeScript without a comment explaining why. Always prefer composition over inheritance. Test coverage must stay above 80%." Claude Code treats these as constraints.
MCP integration. For teams using the Model Context Protocol, connect Claude Code to internal tools (Linear, Jira, custom APIs) via MCP. Claude Code can then fetch tickets, update issues, or query internal services directly.
Signs Claude Code is working well on your team
How to know if your Claude Code adoption is actually paying off. A few qualitative signals.
Engineers spend less time on boilerplate and more on judgment calls. Routine work like adding CRUD endpoints, writing tests, and simple refactors happens quickly through Claude Code, freeing human attention for architecture, design, and debugging edge cases.
Code reviews catch fewer mechanical issues and more design issues. When Claude Code is applying the team's conventions consistently, review comments shift toward higher-level concerns.
Ticket velocity improves without quality degradation. Bug rates stay flat or improve; the team ships more per sprint.
Engineers voluntarily use Claude Code on personal projects. Nobody loves their employer's tooling, but tools that are genuinely good get used outside of work. That is a healthy sign.
Treat Claude Code like a brilliant junior with no memory — give it a great CLAUDE.md, short specific tasks, and review every diff. Do that and it is the most productive AI coding tool of 2026.
The short version
Claude Code rewards investment. A good CLAUDE.md, useful subagents, team-shared slash commands, and well-configured hooks turn a decent coding tool into a productivity multiplier. Treat the agent as a fast, forgetful teammate: brief it clearly, let it work, review every diff. Use Sonnet by default, Opus selectively. Iterate in short cycles. Monitor costs. Senior engineers using Claude Code well ship meaningfully more code than those using any single-tool alternative, but only after putting in the setup investment. If you are new to Claude Code, start with CLAUDE.md. Everything else — subagents, slash commands, hooks, team patterns — builds on top of a good briefing document for the agent. Spend an afternoon on your CLAUDE.md, and the payback will compound for months.