How to Set Up Claude Code Like a Senior Anthropic Engineer (Exact Config Inside)

Anthropic ran the numbers: unguided Claude Code succeeds just 33% of the time.

The engineers who beat that odds don't write better prompts. They build structure around the agent before they type a single task.

Below is that exact structure: the 200-line CLAUDE.md, the slash commands, the writer/reviewer pattern, and the context rule seniors swear by.

Here's the full setup you need 👇

Before we dive in, I share daily notes on AI & vibe coding in my Telegram channel: https://t.me/zodchixquant🧠

The mindset: structure beats prompting

The biggest shift is realizing the prompt isn't where the leverage is. Anthropic's internal teams found the gap between high-output engineers and everyone else isn't prompt quality, it's the structure built around Claude before execution starts.

That structure is a small set of files that control Claude's memory, behavior, and limits. Most people use only CLAUDE.md and miss the rest of the leverage. A senior setup uses all of it, and keeps each piece lean.

Four pieces below: the CLAUDE.md, the commands, the review pattern, and context control.

1. A lean CLAUDE.md, capped at 200 lines

CLAUDE.md loads into the system prompt and stays there the entire session, so every line costs context. The senior rule is to keep it under 200 lines and push detail into rule files that load only when relevant.

Your CLAUDE.md should hold the essentials:

## Project
One paragraph: what this is, the stack, the entry points.

## Conventions
- Use the simplest approach that works. No premature abstraction.
- Match existing patterns. Check a neighbor file before inventing.

## Commands
- Test: `npm test`
- Lint: `npm run lint`

## Rules
- Never push to main directly. Open a PR.
- Write a commit after each working step, so we can revert cleanly.
- Run the tests yourself before saying a task is done.

The "use the simplest approach" line matters more than it looks. Claude over-engineers by default, adding abstraction layers and defensive code nobody asked for. One line in CLAUDE.md curbs it.

For anything longer, like detailed style guides, use .claude/rules/*.md with path globs so they load only when Claude touches matching files.

That keeps the always-on context small.

2. Slash commands for anything you do twice

At Anthropic, Security Engineering wrote 50% of all custom slash commands in the entire monorepo.

The pattern is clear: the moment you repeat a workflow, turn it into a command.

A senior starter, .claude/commands/pr.md:

---
description: Prepare a clean PR from the current branch
allowed-tools: Read, Grep, Glob, Bash
model: sonnet
---

1. Run the full test suite. If anything fails, stop and report.
2. Run the linter. Fix what it flags.
3. Summarize the diff: what changed and why, grouped by file.
4. Write a commit message in our convention.
5. Open the PR. Never push straight to main.

Now /pr runs your whole pre-merge ritual the same way every time. Build one for each workflow you repeat: shipping, reviewing, onboarding to a module, writing tests.

The commands are where a personal setup turns into a system.

3. The writer/reviewer pattern

This is the senior move most people skip. A fresh context reviews better than the one that wrote the code, because it isn't biased toward what it just produced. So you split the work across two agents.

Set up a reviewer subagent in .claude/agents/reviewer.md:

---
name: reviewer
description: Reviews a diff against the plan. Finds gaps, never edits.
tools: Read, Grep, Glob, Bash
model: sonnet
---

You review code you did not write. Assume it has gaps.

1. Read the plan and the diff.
2. Check every requirement is implemented and tested.
3. Flag only gaps that affect correctness or the stated
   requirements. Not style, not hypothetical edge cases.

Report gaps, not preferences. If the work is sound, say so.

The "flag only correctness gaps" line is doing real work. A reviewer told to find problems always finds some, even when the code is fine, which leads to over-engineering as you chase phantom issues. Scope it to what matters.

Because the reviewer runs as a subagent, the gaps come straight back to the implementing session, no copy-pasting between windows.

4. Context discipline: the senior habit

Every senior setup obsesses over one number: context use. Performance starts degrading at 20-40% of the window, and auto-compaction fires around 83% and is lossy, it keeps only a fraction of the detail.

Engineers have lost hours of work to a mid-task compaction wiping their decisions.

The rule most practitioners converged on: don't let context pass 60%. And when you near the limit, don't rely on /compact. Do this instead:

## When context gets full

1. Dump the plan and progress to a markdown file.
2. Run /clear to fully reset.
3. Start fresh with Claude reading that file.

This beats /compact: you control exactly what survives,
and nothing important gets silently dropped.

/compact condenses in memory but saves nothing to disk.

Writing state to a file and clearing gives you a clean window plus a record you control.

That's the difference between losing three hours to a compaction and picking up exactly where you left off.

Common mistakes

A bloated CLAUDE.md. A 400-line CLAUDE.md burns context every single turn and buries the rules that matter. Cap it at 200 lines, push the rest to rule files that load on demand.

Relying on CLAUDE.md for hard rules. It's followed about 70% of the time. Fine for style, dangerous for "don't push to main." For rules that must hold, use a hook, not a line in CLAUDE.md.

Letting one agent write and review. It grades its own work with the same blind spots that wrote the bug. A fresh reviewer context catches what the author can't see.

Ignoring context until it compacts. By the time auto-compaction fires, you've already lost detail. Watch the number, and dump-and-clear before the cliff, not after.

The 15-minute setup

3 minutes: trim CLAUDE.md to the essentials, under 200 lines.

3 minutes: write your first slash command for a workflow you repeat.

4 minutes: create the reviewer subagent.

3 minutes: add the dump-and-clear routine to CLAUDE.md.

2 minutes: run a real task through /pr and the reviewer, and watch the structure carry it.

The senior engineers aren't getting more from Claude because they prompt better. They get more because they build the structure first, then let the agent run inside it.

Thanks for reading!

I share daily notes on AI, finance, and vibe coding in my Telegram channel: https://t.me/zodchixquant