Claude Code in Production: What Actually Works in Large Codebases

There's a gap between AI coding demos on Twitter and what actually ships in production. Most "AI writes my entire app" posts are greenfield toys. The hard part — navigating a 200-service monorepo, respecting existing patterns, not breaking the CI pipeline — doesn't make for good clips.

Claude Code is the first tool that genuinely closes that gap. Not perfectly. Not for everything. But for a specific set of real-world coding tasks, it's a fundamentally different experience from anything else available.

This article is based on months of daily use across production projects ranging from a 15-service startup backend to a large enterprise monorepo. Here's what actually works.

What is Claude Code, really?

Claude Code is an agentic coding tool that runs directly in your project. It started as a terminal CLI, but now it's also a native extension for VS Code and JetBrains IDEs — so you can use it however you prefer. Terminal purists get the CLI. IDE fans get the same agent embedded right in their editor with full access to the same features.

Either way, it's an agent that can:

• Read every file in your project (200k token context window)
• Edit files directly — create, modify, delete across your codebase
• Run shell commands — tests, builds, linters, git operations
• Plan and execute multi-step tasks autonomously
• Remember context across sessions via MEMORY.md
• Connect to external systems via MCP servers (databases, APIs, browsers)
• Compress context intelligently — long conversations don't lose important details

Install the CLI with npm install -g @anthropic-ai/claude-code, or install the VS Code / JetBrains extension directly from the marketplace. Run claude in your project (or open the panel in your IDE), and you're talking to an agent that understands your actual code — not generic Stack Overflow snippets.

What actually works in production

1. Cross-file refactoring

This is Claude Code's killer feature. Tell it "rename UserService to AccountService across the entire project, update all imports, tests, and docs" and it does it. Not find-and-replace — it understands context. It knows that userService in a variable name needs to change too, but user_service_endpoint in your nginx config might not.

2. Adding features that follow existing patterns

This is where the large context window matters. Claude Code reads your existing controllers, services, and tests — then generates new ones that match your exact patterns. Same naming conventions. Same error handling. Same test structure.

# Real prompt that works:
"Add a /api/v2/invoices endpoint. Follow the same pattern as /api/v2/orders —
same auth middleware, same pagination, same error responses.
Include integration tests matching the orders test file."

It reads the orders implementation, understands the pattern, and produces an invoices implementation that looks like the same engineer wrote both. This is impossible with tools that only see the current file.

3. Bug investigation and fixing

Point Claude Code at a bug report and watch it work:

# This actually works:
"Users in EU timezone are seeing duplicate notifications.
Check the notification scheduler, the timezone handling,
and the dedup logic. Find the bug and fix it."

It reads the scheduler code, traces the timezone conversion, finds the off-by-one in the dedup window, fixes it, and updates the test. The extended thinking mode (Opus) is noticeably better at this kind of multi-step reasoning.

4. Writing tests for existing code

Claude Code writes tests that actually test something. Because it reads the implementation, it knows the edge cases. It doesn't just test the happy path — it tests the boundary conditions that matter.

"Write comprehensive tests for the PaymentProcessor class.
Cover all error paths, retry logic, and the idempotency key handling.
Use the same test patterns as OrderProcessor.test.ts."

5. Documentation that stays accurate

Because Claude Code reads the actual code, it generates docs that match reality. API docs with the real field names. Architecture docs that reflect the actual dependency graph. README updates that include the current CLI flags.

CLAUDE.md: The feature that changes everything

This is the most underrated feature in all of AI-assisted coding. Drop a CLAUDE.md file in your project root with your team's conventions, and Claude follows them every single time.

# Example CLAUDE.md that works in production:

## Architecture
- Monorepo with /packages/* structure
- Each package has src/, tests/, and package.json
- Shared types in /packages/shared-types

## Coding Standards
- Use Result<T, E> pattern for error handling, never throw
- All database queries go through the repository layer
- No direct imports between packages — use the public API

## Testing
- Integration tests hit a real database (docker-compose up first)
- Unit tests use dependency injection, no mocks for DB
- Every PR needs tests — no exceptions

## Git
- Conventional commits (feat:, fix:, refactor:)
- Squash merge to main
- Branch naming: feature/TICKET-123-short-description

The power here is team-wide consistency. Every engineer on the team gets Claude Code that follows the same rules. New hires get perfectly formatted code from day one. The conventions aren't suggestions — they're instructions that Claude follows precisely.

MEMORY.md: It remembers your project

This one is subtle but game-changing over time. Claude Code maintains a MEMORY.md file where it writes its own persistent notes about your project — across sessions. Close the terminal, come back tomorrow, and Claude already knows:

• Your project structure and key architectural decisions
• Which patterns you prefer and why
• What you worked on last time and where you left off
• Your personal preferences for code style, commit messages, testing approach

You never re-explain your stack. You never say "remember, we use Prisma not TypeORM" for the fifth time. It's like pair programming with someone who has genuine institutional memory. The more you use it, the better it gets — MEMORY.md accumulates knowledge about your project that makes every session more productive than the last.

Skills: Custom slash commands that save minutes every day

Skills are reusable slash commands you define for your project. Instead of typing the same complex prompt every time, you create a Skill once and invoke it with /skill-name.

# Examples of Skills teams actually use:
/commit     — analyze staged changes, write a conventional commit message
/review-pr  — review a PR diff for bugs, style issues, missing tests
/test       — write tests for the current file following project patterns
/deploy     — run the full deploy checklist with safety checks
/explain    — explain a complex function for onboarding docs

Skills are stored as markdown files in your project, so they're version-controlled and shared with the team. When a senior engineer creates a /review-pr Skill with all the things they check for, every junior engineer on the team gets that same review quality. It's institutional knowledge encoded as automation.

The compound effect is real: 5 Skills that each save 3 minutes means 15 minutes saved per session. Over a week, that's hours.

Plan Mode: Think before you code

This is personally my favorite feature. Before Claude Code touches a single file, you can ask it to plan first.

Plan Mode (/plan or enable it in settings) tells Claude to research your codebase, think through the approach, and produce a detailed markdown plan before writing any code. The plan includes:

• Which files need to change and why
• The order of operations (what depends on what)
• Edge cases it identified
• Alternative approaches it considered and rejected
• A verification checklist (how to test the changes)

# Try this:
"Plan how to add rate limiting to our API. Don't make changes yet —
just analyze the codebase and write a plan as a markdown file
with the steps, files to modify, and testing strategy."

You review the plan, give feedback ("skip the Redis approach, we want in-memory for now"), and then let it execute. This is incredibly powerful for complex changes where you want to think before you act. It's the difference between a junior dev who starts coding immediately and a senior who sketches the architecture first.

You can also ask Claude to write a progress log — a markdown file describing what it already did, what's left, and any decisions it made along the way. For longer sessions, this is invaluable: you get a human-readable audit trail of every change and the reasoning behind it.

Context compression: Long sessions that don't break

Here's a problem every AI coding tool has: long conversations eat up the context window, and eventually the model "forgets" what you discussed earlier. Claude Code solves this with automatic context compression.

As your conversation grows, Claude Code intelligently compresses earlier messages — keeping the important decisions, file changes, and context while discarding the noise. The result: you can have sessions that last hours without Claude losing track of what you're doing.

In practice, this means you can start with "let's refactor the auth module", then pivot to "actually, also update the tests", then "oh and fix that bug in the middleware" — and Claude maintains coherent understanding of all three threads. Other tools would have lost the plot two pivots ago.

For large refactoring sessions where you're touching 20+ files over an hour, this is the difference between a tool that stays useful and one that starts hallucinating file paths from 45 minutes ago.

MCP servers: Connecting Claude to your infra

MCP (Model Context Protocol) servers let Claude Code talk to external systems. This is where it stops being a code editor and becomes an engineering tool.

Real setups that work:

• Database MCP — Claude queries your staging DB directly. "Why are orders failing for merchant X?" It reads the code, queries the DB, correlates the data, and finds the issue.
• Browser MCP — Claude opens your app, navigates pages, and verifies its changes visually. Catches CSS regressions that pure code review misses.
• GitHub MCP — Claude reads PR comments, checks CI status, and can create issues or PRs directly.
• Sentry/DataDog MCP — Claude reads error logs and stack traces from production, then traces them back to the code.

Real workflows that save hours

The "/commit" workflow

Create a custom Skill (slash command) that reviews staged changes, writes a conventional commit message, and runs pre-commit hooks. Takes 5 seconds instead of the 2 minutes of writing a thoughtful commit message.

The "PR review" workflow

Point Claude at a PR diff and ask for a review. It catches things human reviewers miss — inconsistent error handling, missing edge cases in tests, and patterns that don't match the rest of the codebase. Not a replacement for human review, but a powerful first pass.

The "migration" workflow

"Migrate all API endpoints from Express to Fastify.
Keep the same route structure and middleware chain.
Update tests to use Fastify's inject() instead of supertest.
Do it one package at a time, run tests after each."

Claude Code plans the migration, executes it incrementally, and validates each step. This kind of large-scale, pattern-preserving migration is where it genuinely saves days of work.

The "on-call" workflow

3am alert. Connect Claude Code to your logs via MCP, paste the error, and let it trace through the codebase to find the root cause. It reads the stack trace, finds the relevant code, and proposes a fix — all while you're still half asleep.

Where Claude Code breaks down

Honesty matters. Here's where it doesn't work well:

• Greenfield architecture decisions — Claude Code is excellent at following patterns but mediocre at choosing which patterns to use. You still need a senior engineer deciding the architecture.
• Highly performance-critical code — It writes correct code, but not always optimal code. For hot paths (database queries, tight loops, real-time systems), you need human expertise.
• Novel algorithms — It can implement well-known algorithms perfectly, but struggles with truly novel optimization problems.
• Very large monorepos (10k+ files) — The 200k context window is huge but not infinite. For massive codebases, you need to scope your requests carefully.
• Code that requires deep domain knowledge — Financial calculations, medical systems, legal compliance — always verify with domain experts.

The pattern is clear: Claude Code is a force multiplier for skilled engineers, not a replacement for them. It makes good engineers faster. It doesn't make non-engineers into engineers.

Claude Code vs. Copilot vs. Cursor

They solve different problems:

• GitHub Copilot — Best for line-by-line autocomplete while typing. Fast, low-friction, great for boilerplate. But it only sees the current file and a few open tabs. No agentic capabilities, no persistent memory, no plan mode.
• Cursor — Great IDE integration with multi-file context. Strong for medium-sized changes within 5-10 files. The Composer feature is good for coordinated edits. But it lacks MEMORY.md persistence, Skills system, and the depth of MCP integrations.
• Claude Code — Best for large-scale, agentic tasks across an entire codebase. It reads everything, plans multi-step work, runs commands, and validates its own changes. Works as CLI or IDE extension. MEMORY.md, Skills, Plan Mode, context compression, MCP — nothing else has this complete a feature set for production work.

Many engineers use Copilot + Claude Code together: Copilot for moment-to-moment autocomplete, Claude Code (in the IDE extension or terminal) for the big tasks that would take hours manually. They complement each other perfectly.

Getting started the right way

Don't try everything at once. Here's the progression that works:

1. Week 1: Install Claude Code (CLI or IDE extension), create a basic CLAUDE.md with your project structure and coding conventions. Use it for one refactoring task. Let MEMORY.md start building up.
2. Week 2: Start using it for test writing and bug investigation. Try Plan Mode for a multi-file change — ask it to plan first, review, then execute. Notice how MEMORY.md makes the second session smoother than the first.
3. Week 3: Create your first custom Skills (start with /commit and /review-pr). Add one MCP server (GitHub is easiest). Try a long session and notice how context compression keeps things coherent.
4. Week 4: Use it for a real feature implementation end-to-end. Ask it to write a progress markdown as it works. Share CLAUDE.md and Skills with your team.

The key insight: invest time in your CLAUDE.md. The better your instructions, the better Claude Code performs. Teams that skip this step get generic output. Teams that invest in it get output that's indistinguishable from a senior team member.