Claude Code in Production: How Senior Engineers Actually Use It

Most Claude Code articles read like CLI documentation: install this, run that, try these commands. That is useful for the first hour. It is not enough for the first month.

The real question is not "Can Claude Code edit files?" The real question is: Can you put it inside a serious codebase without letting it create expensive, invisible damage?

My answer is yes, but only if you stop treating it like a clever autocomplete and start treating it like a junior engineer with root-level enthusiasm, uneven judgment, and unlimited stamina.

This is the production angle: what to allow, what to block, how to write CLAUDE.md, how to structure tasks, how to catch bad work, and what breaks when the demo becomes a real team workflow.

The Mental Model: Agent, Not Chatbot

Claude in the browser is a conversation. Claude Code is an agent with tools.

It can read files, search the repo, edit code, run shell commands, inspect failures, and continue iterating. That makes it useful for real engineering work:

• Tracing a failing test across several modules.
• Migrating one pattern across a codebase.
• Writing missing tests against existing behavior.
• Producing a plan before a risky refactor.
• Doing boring cleanup work that senior engineers avoid until it becomes debt.

But there is a cost: once the model has tools, your prompt is no longer just text. It becomes operational intent.

Prompting for Safety

That difference is not style. It is operational safety.

The First Production Scar: The .env Problem

Here is the kind of failure that changes how you configure Claude Code.

An engineer asks an agent to "make local setup easier." The agent sees .env.example, .env.local, Docker compose files, and a README. It decides the cleanest solution is to normalize environment variables. Helpful idea.

Then it reads or rewrites files it should never touch. Maybe it doesn't leak secrets anywhere. Maybe it only replaces local values with placeholders. Maybe it adds a new required variable and breaks every developer's machine the next morning.

The issue is not that the model is malicious. The issue is that secrets and local config look like normal project files unless you teach the tool otherwise.

I do not rely on CLAUDE.md for this. CLAUDE.md is guidance. Permissions are enforcement.

{
  "permissions": {
    "deny": [
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Edit(**/.env)",
      "Edit(**/.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.config/gcloud/**)"
    ],
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint)",
      "Bash(npm run build)",
      "Bash(git diff *)",
      "Bash(git status *)"
    ]
  }
}

Then reinforce the behavior in CLAUDE.md:

- Never read, print, modify, summarize, or copy .env files.
- Use .env.example when environment variable names are needed.
- Never change secrets, credentials, tokens, or local machine config.
- If a task appears to require secrets, stop and ask for a safer path.

Why both? Because they solve different problems. CLAUDE.md shapes what Claude attempts. settings.json controls what Claude Code is allowed to do.

Install It, But Do Not Stop There

The basic install is the easy part.

# macOS / Linux / WSL
curl -fsSL https://claude.ai/install.sh | bash

# verify
claude --version
claude doctor

Then open a repository and run:

claude
/init

/init gives you a starting CLAUDE.md. Treat it like a draft, not a contract. Your first serious session should not be "build a feature." It should be:

The CLAUDE.md I Want in a Real Repo

Most CLAUDE.md files become junk drawers. A useful CLAUDE.md tells the agent what a senior engineer would tell a new teammate on day one.

# Project Operating Rules

## Commands
- Install: npm ci
- Typecheck: npm run typecheck
- Unit tests: npm test
- Focused test: npm test -- <path-or-pattern>
- Lint: npm run lint
- Production build: npm run build

## Architecture
- API routes live in src/app/api.
- Shared domain logic lives in src/domain.
- React components must not call database clients directly.
- Data access belongs in src/server/repositories.

## Change Boundaries
- Do not edit migrations unless the task explicitly asks for schema changes.
- Do not edit generated files.
- Do not edit .env files. Use .env.example for variable names.
- Do not change public API response shapes without calling it out.

## Verification
- For UI changes, run lint and typecheck.
- For server logic, run focused tests first, then the relevant package test.
- If a command fails because of missing local services, explain the blocker.

## Git
- Keep diffs small.
- Do not commit unless explicitly asked.
- Summaries must include files changed, tests run, and remaining risk.

Permission Modes Are Engineering Policy

Claude Code has permission modes and fine-grained rules. This is where teams either become productive or reckless.

(Note: Risks range from Low (plan) to Very High (bypass). Always prefer plan for discovery and default for daily work.)

The Second Production Scar: Infinite Test Loops

Claude Code can get stuck in a loop: Run test → See failure → Patch code → Run test again → Create a different failure.

That "stop after 3 attempts" line prevents the agent from turning a debugging task into a wandering refactor.

Hooks: Where Advice Becomes Enforcement

CLAUDE.md is not enough for rules that must always happen. Use hooks when you need deterministic behavior.

The Review Loop: Trust But Verify

Claude Code should not be allowed to disappear into a repo and come back with a giant diff.

Production Workflows That Actually Pay Off

1. Bug Investigation

Use Claude Code to trace across files, not to guess from a stack trace.

"Investigate this production error. Do not edit files yet. Find the request path, the likely failing module, and the smallest test that would reproduce it."

2. Test Coverage for Old Code

Claude is quietly excellent at backfilling tests.

"Find untested branches in src/domain/invoices. Do not change production code. Add tests that document current behavior, including edge cases."

3. Mechanical Refactors

Perfect for clear pattern migrations.

"Migrate only src/components/forms from the old Button import to the design-system Button. Do not change behavior or styling. Run typecheck."

Key Takeaways