10 Ways to Get the Most Out of Claude Code

I've run 321 Claude Code sessions across 10 repositories over the past six weeks. Not toy projects — production Next.js apps, Terraform infrastructure, Kubernetes manifests, and cross-service authentication debugging. Along the way I've learned that the gap between "using Claude Code" and "getting real value from Claude Code" comes down to how you structure your workflow around it.

Here's what I wish I'd known on day one.

The Problem With Default Usage

Most developers open Claude Code, type a prompt, get some code, paste it in, and move on. That works for simple tasks. But for anything non-trivial — framework upgrades spanning multiple apps, debugging auth flows across services, migrating a design system — the default workflow falls apart. You lose context between sessions, waste time re-explaining your project, and end up reviewing code without a clear quality bar.

The practices below close that gap. Each one addresses a specific failure mode I hit during real work.

1. Give Every Project a CLAUDE.md

This is the single highest-impact change you can make.

CLAUDE.md is a markdown file at the root of your project that Claude Code reads automatically at the start of every session. It acts as institutional memory — your architecture, conventions, environment setup, gotchas, and past mistakes, all loaded before you type your first prompt.

Without it, the first few minutes of every session go to re-explaining your project. With it, Claude is productive immediately.

What to put in it:

Architecture overview (how your apps connect, what runs where)
Environment setup (local dev commands, required env vars)
Conventions (naming, file structure, testing approach)
Known pitfalls (things Claude has gotten wrong before)
Test credentials for dev environments

The maintenance rule: Every time you correct Claude, update CLAUDE.md so the same mistake doesn't happen again. Over time, this file becomes a living document that encodes everything Claude needs to know about your project.

For one of my projects, the CLAUDE.md documents that several Next.js apps share a URL namespace behind a reverse proxy, that cross-app navigation requires window.location.href (not router.push), and that the cookie domain has to match across all apps or you get infinite redirect loops. Claude remembers all of this without being told twice.

Key takeaway: Treat CLAUDE.md like a README for your AI pair programmer. Keep it concise, keep it current, and update it after every correction.

2. Plan Before You Build

Complex tasks shouldn't start with code. They should start with a plan.

Claude Code has a plan mode (cycle into it with Shift+Tab) that follows a structured workflow:

Explore → Design → Review → Approve → Execute

Over six weeks I created 27 formal plans — login redirect loop debugging, Next.js 14-to-16 upgrade strategies, structured logging rollouts, Tailwind CSS migrations. The value is alignment before implementation. A plan surfaces edge cases, dependency chains, and architectural decisions before you've written code that needs to be thrown away.

When to use plan mode:

Framework upgrades (where breaking changes compound)
Debugging sessions (form a hypothesis before changing code)
Multi-file refactors (understand the blast radius first)
Anything you'd sketch on a whiteboard before coding

When to go back to plan mode:

If research or implementation goes sideways mid-task, switch back to plan mode and re-plan. Don't keep pushing down a bad path. Recognising when to stop and re-plan is one of the most important habits to build.

When I upgraded three apps from Next.js 14 to 16, the plan broke it into an incremental 14 → 15 → 16 strategy to isolate breaking changes at each step. Without that plan, a single-jump upgrade would have produced an impossible-to-debug wall of errors.

Key takeaway: Plan mode is cheapest at the start of a task and most valuable when the task is complex. Use it liberally.

3. Delegate to Subagents

Your main Claude Code session has a finite context window. Every file it reads, every exploration it does, fills that window. Subagents let you offload focused work to separate agents that report back with a summary, keeping your main context clean.

Parallel exploration is where this shines. Instead of exploring a codebase sequentially, launch three agents at once:

One maps the entry points and routing
One analyses the component architecture
One reviews the test infrastructure

Each agent returns a focused summary. The main agent synthesises the findings without its context getting cluttered with raw file contents.

When to use subagents:

Codebase exploration (especially across multiple repos)
Independent implementation tasks that don't depend on each other
Research tasks that require reading many files
Any time your main context is getting heavy

I found this particularly valuable when working across apps that share authentication and a URL namespace. Understanding the full picture requires looking at several systems simultaneously — subagents make that tractable.

Key takeaway: Think of subagents as team members you can spin up on demand. Give each one a focused task, let them work in parallel, and synthesise the results in your main session.

4. Track Multi-Step Work with Task Dependencies

For complex, multi-step work, Claude Code's task management keeps execution on track. Tasks have statuses (pending → in progress → completed) and dependency chains that enforce correct ordering.

When I upgraded one of my apps from Next.js 14 to 16, the work was tracked as seven sequential tasks:

1. Node version upgrade

2. Next.js 15 dependency updates

3. Async API migration

4. Build verification

5. Next.js 16 upgrade

6. ESLint flat config migration

7. Final verification

Each task was blocked by the one before it, so nothing ran out of order. When a step failed, the status made it clear exactly where in the chain the problem was.

This pattern becomes a repeatable template when you're doing the same upgrade across multiple apps. Define the task chain once, then reuse it.

Key takeaway: For any task with more than three steps, create an explicit task hierarchy with dependencies. It prevents you from skipping steps and makes progress visible.

5. Build Skills for Repeatable Work

If you do something more than once, turn it into a skill.

Skills are reusable instruction sets that encode best practices for specific types of work. Rather than explaining the same process every session, a skill packages the approach into something Claude follows consistently.

Skills I built and used:

| Skill | What it does |

|-------|-------------|

| next-upgrade | Guides Next.js major version upgrades using official migration codemods |

| frontend-design | Ensures UI implementation meets a high design bar |

| tailwind-design-system | Handles Tailwind CSS v4 migration with correct design tokens |

The next-upgrade skill guided three separate app upgrades through the same process. Without it, each upgrade would have required re-explaining the strategy — which codemods to run, what order to follow, what to verify at each step.

Custom commands work the same way. I built a /deslop command that removes common AI-generated code artifacts from diffs — unnecessary comments, overly defensive null checks, as any casts, and style inconsistencies. It runs against the diff from main so it only targets AI-introduced changes, not existing code.

Key takeaway: Skills and custom commands are your way of teaching Claude your standards. Build them for any workflow you repeat.

6. Connect Your Tools with Plugins and MCP Servers

The biggest productivity multiplier isn't writing code faster — it's eliminating context switching. Claude Code plugins and MCP (Model Context Protocol) servers bring your external tools directly into the conversation.

Plugins I use daily:

| Tool | What it enables |

|------|----------------|

| Figma | Pull design specs and screenshots into the conversation. Review implementation against the original design without leaving the terminal. |

| Notion | Search tickets, create documentation pages, query task databases. When someone references a ticket ID, Claude looks it up immediately. |

| Datadog | Query logs, metrics, and service dependencies. Debug production issues without opening a browser. |

| Context7 | Fetch up-to-date library documentation. Critical during the Next.js 16 migration when online resources were outdated. |

| Playwright | Browser automation for end-to-end testing. |

The combined effect is that Claude has the same context you do — the design, the ticket, the logs, the docs — without you copying and pasting between tools.

MCP servers extend this further by connecting Claude to external APIs. I connected Datadog's MCP server to query logs and service dependencies directly, and used Figma's MCP server for Code Connect component mapping.

Key takeaway: Every time you alt-tab to another tool, ask whether a plugin or MCP server could bring that tool to Claude instead. The fewer context switches, the faster the workflow.

7. Make Claude the Reviewer, Not Just the Writer

The most underrated practice is using Claude as a quality gate on its own output.

Two phrases I use constantly:

"QA me on these changes and don't make a PR until you're sure." This forces Claude to review the diff critically — checking for edge cases, verifying behaviour, and flagging anything it's uncertain about — before declaring the work done.

"Prove to me this works." This makes Claude diff the behaviour between main and the feature branch, demonstrating the change actually does what it claims rather than just asserting it does.

Beyond manual prompts, I use specialised review agents that catch specific categories of issues:

Silent failure detection — Are errors being swallowed in catch blocks?
Type design review — Are new types well-constructed with proper invariants?
Test coverage analysis — Are there critical gaps in test coverage?

These catch issues that a casual review misses. Combined with the /deslop command for cleaning AI artifacts, the result is a multi-layered quality gate that runs before any PR is created.

Key takeaway: AI-generated code needs AI-powered review. Build verification into your workflow, not as an afterthought but as a required step before any PR.

8. Use Git Worktrees for Parallel Work

When you need to work on a feature branch without disrupting your current checkout, git worktrees keep things clean. Claude Code can create isolated worktrees in a dedicated directory so you can run upgrade work on a separate branch while main development continues uninterrupted.

I keep all worktrees at ~/.claude-worktrees/, outside the project root, to avoid confusion between the main checkout and feature work.

This was essential during the Next.js upgrades. They touched nearly every file in each project, and I needed to keep building features on main simultaneously. Without worktrees, I'd have been constantly stashing, switching branches, and losing my place.

Key takeaway: For any large-scope work that will take multiple sessions, create a worktree. It's cheaper than juggling branches in a single checkout.

9. Go Beyond Application Code

One of the biggest misconceptions about AI coding tools is that they're only useful for writing React components. In practice, I've used Claude across the full stack:

Terraform — AWS resource provisioning and IAM configuration across environments.
Kubernetes/ArgoCD — Multi-environment manifest generation for dev and prod.
GitHub Actions — CI/CD pipeline fixes, peer dependency resolution, and lint error remediation across upgrade PRs.
Caddy — Reverse proxy configuration for local multi-app HTTPS development.

Infrastructure-as-code is repetitive, configuration-heavy, and error-prone in exactly the ways where an AI tool provides the most value. Terraform modules, Kubernetes manifests, and CI pipelines all benefit from Claude having seen thousands of similar configurations.

Key takeaway: Don't limit Claude to your application layer. Infrastructure, CI/CD, and platform configuration are some of its strongest areas.

10. Use Claude for Real Debugging

The debugging work was some of the most valuable across all 321 sessions. These weren't simple null-pointer fixes — they were cross-system issues that required understanding how multiple services interact:

Login redirect loops — Traced to cookie domain mismatches between apps sharing a URL namespace. The cookie domain had to match across all apps for shared auth to work.
7-10 second page loads — Diagnosed sequential server action round-trips on the login page that could have been parallelised.
ChunkLoadError during auth redirects — Identified a React Server Components refetch race condition triggered by cross-app navigation.
OIDC logout not clearing cookies — The cookie domain set during login didn't match the domain used during logout, so the cookie persisted silently.

Each of these required reading code across multiple repositories, understanding the interaction between systems, and forming a hypothesis. Plan mode was critical here — debugging got its own explore → hypothesise → verify cycle, preventing the "change random things and hope" approach.

Key takeaway: Claude is strongest at debugging when you give it the full picture — multiple repos, system interactions, and the symptom you're observing. Use plan mode to structure the investigation.

Putting It All Together

These practices aren't independent — they compound. CLAUDE.md makes plan mode faster because Claude already understands your architecture. Subagents make multi-repo debugging tractable. Skills make repeated workflows consistent. Plugins eliminate the context switches that break your flow. Quality gates catch what slips through.

After six weeks and 321 sessions:

27 structured plans kept complex work on track
1.4 billion+ cache read tokens (prompt caching cut costs dramatically on repeated context)
Work spanned application development, framework migrations, infrastructure, debugging, documentation, and code review

The through-line is this: Claude Code isn't just a code generator. It's a development workflow tool. The more structure you give it — memory, plans, tasks, quality gates — the more value it returns.

Start Here

If you take nothing else away, start with these three:

1. Create a CLAUDE.md for your most active project. Document the architecture, conventions, and two or three things Claude would otherwise get wrong.

2. Use plan mode for your next non-trivial task. Let Claude explore before it builds.

3. Say "QA me on these changes" before your next PR. Make Claude earn the merge.

Everything else builds on top of those foundations.