Claude Code Mastery: From Casual User to Daily Driver

The Gap Between Casual Users and Daily Drivers

Claude Code is one of those tools where the difference between a casual user and someone who has truly internalized it is enormous. The casual user types prompts, accepts suggestions, and treats it like fancier autocomplete. The daily driver uses it as a programmable agent with memory, custom commands, parallel sessions, and a project setup that compounds over time.

This guide is for the second kind of person.

Plan Mode: Don't Jump Straight Into Code

The single most important principle from Boris Cherny (Claude Code team): give Claude a way to verify its own work. Without this, the developer is the only feedback loop. With it, Claude iterates until things actually work, and Boris says this alone gives a 2-3x quality improvement.

Key patterns:

Explore, then plan, then code. Press Shift+Tab twice to enter plan mode. Claude goes read-only — reading files, tracing flows, understanding the data model. Then get a plan. Then execute. Skip planning for small fixes; use it for anything touching more than one file.

Use plan mode like a design document. Claude A writes the plan. Claude B (fresh session) reviews it as a staff engineer. With no context bias, Claude B catches gaps Claude A missed.

Reference, don't describe. Instead of "look at the auth module", type @src/auth/login.py. Instead of pasting an error, pipe it: cat error.log | claude. Exact context beats approximate description every time.

Delegate, don't pair-program. Cat Wu (Claude Code team): "The model performs best if you treat it like an engineer you're delegating to, not a pair programmer you're guiding line by line." Write a crisp brief upfront, then let it run.

CLAUDE.md: Small File, Big Impact

CLAUDE.md loads at the start of every session. Get it wrong and Claude repeats the same mistakes. Get it right and the same prompt produces dramatically better output.

Two principles Boris emphasizes:

Keep it short. For every line, ask: "Would removing this cause Claude to make a mistake?" If not, cut it.

Let Claude write rules for itself. Any time Claude does something wrong, end your prompt with: "Update CLAUDE.md so you do not repeat this." Boris calls Claude "eerily good at writing rules for itself" from its own failures. Repeat for a few weeks and the file becomes a curated list of every project gotcha.

The real CLAUDE.md from the Claude Code team (shared publicly by Boris):

# Development Workflow
**Always use `bun`, not `npm`.**
# 1. Make changes
# 2. Typecheck (fast)
bun run typecheck
# 3. Run tests
bun run test -- -t "test name"
bun run test:file -- "glob"
# 4. Lint before committing
bun run lint:file -- "file1.ts"
bun run lint
# 5. Before creating PR
bun run lint:claude && bun run test

That is the entire file. Build commands Claude cannot guess. The exact order to run things. Single-test invocations. The pre-PR ritual. No style preferences. No codebase tours. No platitudes.

A fuller template following the same philosophy:

# Code style
- Use ES modules (import/export), not CommonJS (require)
# Workflow
- Always use `bun`, not `npm`
- Run `bun run typecheck` before claiming done
- Never push to main directly. Always open a PR.
# Architecture
- All API routes go through src/api/middleware/auth.ts
- New database queries go in src/db/queries/. No inline raw SQL.
# Gotchas
- `User` and `UserRecord` are distinct types.
- `formatCurrency` assumes USD. Use `formatCurrencyByLocale` for international.

The "Gotchas" section is the magic. Every entry is a mistake Claude made, captured the moment it happened.

The .claude/ Directory: More Than One File

The .claude/ directory is a layered configuration system:

• CLAUDE.md — loaded every session, committed to git for the team
• CLAUDE.local.md — private, gitignored, holds personal notes
• rules/*.md — topic-scoped guidance, optionally path-gated to specific directories
• skills//SKILL.md — reusable prompts invoked with /name
• agents/*.md — subagent definitions

A powerful pattern: after every PR review, dump all feedback into CLAUDE.local.md. Over time, this becomes a personalized rule file for exactly what reviewers flag most often.

"Compounding Engineering"

Boris uses the term "Compounding Engineering" to describe how every PR review becomes a CLAUDE.md improvement. In a PR comment:

nit: use a string literal, not a ts enum
@claude add to CLAUDE.md to never use enums, always prefer literal unions

Each review comment doesn't just fix the current code — it prevents Claude from repeating that mistake in the future. This is a self-reinforcing improvement loop that accumulates over time.

Conclusion

The difference between a casual user and a daily driver of Claude Code is not prompt engineering skill. It is about building the system: plan mode, a continuously maintained CLAUDE.md, the layered .claude/ directory, and the "compounding engineering" loop from every PR review.

Start today: every time Claude makes a mistake, add "Update CLAUDE.md so you do not repeat this." It is the simplest habit with the highest compounding return.