My Claude Code Setup for Enterprise AI Projects

Most Claude Code tutorials show you how to build a side project. Enterprise codebases are a different problem: monorepos, internal SDKs, compliance boundaries, legacy patterns you can’t touch, and a CI gate that will fail you if you get anything wrong.

Here’s the setup I’ve landed on after using Claude Code as my primary interface for enterprise AI work.

Start with a well-structured CLAUDE.md

The single highest-leverage change is writing a good CLAUDE.md. Not the generic template. A project-specific one that tells Claude about your boundaries.

For enterprise work I always include:

• What not to touch: authentication flows, billing integrations, compliance-sensitive modules. Name them explicitly.
• Internal SDK patterns: if you have an internal HTTP client wrapper or a custom logging standard, describe it. Claude will use it instead of reaching for a third-party library.
• The test pattern: whether you mock at the integration layer or use real fixtures, Claude needs to know.
• Dependency constraints: if you’re locked to specific package versions or you can’t add new dependencies without approval, say so.

Without this context, Claude will write reasonable-looking code that violates half your team’s conventions.

Context windows and large codebases

The killer problem with large codebases isn’t capability. It’s context exhaustion. A 200k-line monorepo cannot fit in a context window. Your job is to make sure the right things are in context at the right time.

What works for me:

Slim the initial context. Run /init in the specific module directory you’re working in, not the repo root. This keeps the CLAUDE.md surface area focused.

Use explicit file mentions. Rather than letting Claude explore, be prescriptive: “Read src/services/rag/retriever.ts and src/services/rag/types.ts before doing anything.” This cuts exploration time and prevents hallucinated module names.

One concern per session. Multi-concern sessions drift. If you need to refactor the retriever and add a new endpoint, do them in separate Claude Code sessions. Context pollution between concerns causes more review time than it saves.

The agentic loop that actually works

For implementation tasks, I use a three-step loop:

1. Spec first. Have Claude write a detailed implementation plan in a markdown block. Review it. Ask it to reconsider any decision you disagree with before it writes code.
2. Implement in stages. Break implementation into stages that each leave the codebase in a buildable, testable state. Never let Claude write code across 8 files in one shot without intermediate checkpoints.
3. Review diffs, not summaries. Always read the actual diff. Claude’s summaries are accurate but incomplete. The interesting part is what it changed in file 7 while you were focused on file 3.

The pattern I’d avoid

One-shot “build this entire feature” prompts. They produce plausible-looking code that fails at integration. Enterprise work is integration work. The value of Claude Code in this context is the iteration speed, not the one-shot generation.

Use it as a fast pair programmer who needs clear direction, not as an autonomous agent with wide latitude.