# How top developers use Claude Code

Most developers who try Claude Code use it the same way they used autocomplete: fire off a one-liner, accept what comes back, move on. That works for trivial edits. It does not work for the things worth doing.

The developers who get the most out of it treat it differently. They spend a few minutes on setup before each session. They give the agent a plan before they give it a task. They stay in the loop on every diff. This guide pulls those habits together into something you can adopt today.

## How should I think about Claude Code?

Think of Claude Code as a fast junior, and this framing matters more than any individual trick. A fast junior is capable, motivated, and will produce a lot of output. They also need direction. Left alone with a vague prompt they will do something reasonable and often wrong, because they do not know the decisions you made last Tuesday.

Your job is to be a good tech lead, not a hands-off manager. That means:

- Telling the agent what matters before it starts.
- Checking its plan before it touches files.
- Reviewing every diff before you accept it.
- Redirecting when it goes sideways, not patching over the result.

The habits below are all expressions of that model. None of them require deep AI knowledge. They require the same thing that makes any collaboration work: clear communication, agreed conventions, and staying in the loop.

## Habit 1: Write a tight CLAUDE.md

The single highest-impact thing you can do is write a good `CLAUDE.md`. Claude reads this file at session start and treats it as ground truth about your project. Every convention you document there is a mistake the agent will not make. For the full mechanics of what Claude loads and how, see [rules and memory files](/guides/rules-and-memory-files).

Run `/init` once per repo to generate a first draft. Then edit it until it reflects your codebase.

Good `CLAUDE.md` sections to include:

```markdown
## Stack
Next.js 16, TypeScript, Tailwind. Database is Postgres via Drizzle.

## File size limit
No file over 400 lines. Split by responsibility, not by line count alone.

## Naming
Group files by feature. Keep tests next to the code they cover.

## Async
Prefer async/await with try/catch over long promise chains.

## Testing
Tests live next to the file they test. Use Vitest. No snapshot tests.
```

Be specific and short. Vague rules like "write clean code" do nothing. Rules like "no file over 400 lines" are enforced on every edit automatically.The opposite failure is a bloated CLAUDE.md: hundreds of lines of every preference you ever had. The agent reads it all every session, and the rules that matter get diluted in the noise. Keep it to the conventions you would correct in a code review, and cut anything you have not enforced in months.

A few things worth including that developers often forget:

- Where tests live and what test runner you use.
- Any libraries that are banned or have a preferred alternative (e.g. "use `date-fns`, never `moment`").
- How errors are surfaced to the user in your UI.
- Which environment variables exist and what they control, if that is relevant to the agent's work.

Revisit `CLAUDE.md` whenever you catch the agent making the same mistake twice. That mistake means you have an implicit convention that is not yet explicit.

## Habit 2: Use plan mode before every non-trivial change

Plan mode is the biggest thing most developers skip. Before Claude writes a single line of code, you can ask it to produce a plan: what files it will touch, what it will change in each one, what it is unsure about.

```bash
claude --plan "refactor the auth module to use the new session store"
```

You review the plan. You push back on any step that looks wrong. Only when the plan is correct do you let it proceed. This is dramatically cheaper than reviewing code after the fact, because a wrong plan corrects a structural problem before the agent writes 300 lines built on top of it.

For anything touching more than two or three files, plan first. Always. The time cost is a fraction of the debugging cost of a bad assumption.

Inside a session you can also ask for a plan inline before the agent acts:

Before you write any code, list every file you plan to touch and what you will change in each one. I will approve before you proceed.

A good plan response will tell you the proposed order of changes, flag any files it is uncertain about, and surface assumptions it is making. If the plan says "I will update the session store interface" and you know that interface is shared with three other services, you can catch that now. The agent does not know what it does not know. Your review is the correction mechanism.The trap is treating the plan as a rubber stamp: skimming it, approving, and only reading the code once it is written. That throws away the entire point, since a wrong assumption you wave through now becomes 300 lines you have to unpick later. Read the plan as carefully as you would read the diff, and reject the whole thing if even one step rests on an interface or file you know it has misjudged.

One concrete technique: ask the agent to produce the plan as a numbered list with a one-sentence rationale for each step. That format makes it easy to spot where the reasoning is thin.

Give me the plan as a numbered list. For each step, include one sentence explaining why it comes in that order.

## Habit 3: Set the right effort level per task

Effort controls how much reasoning the model is allowed to spend. High effort is not always better. It is slower, it costs more, and for simple tasks the extra reasoning produces nothing useful. See [effort levels](/guides/claude-code-effort-levels) for the full breakdown.

The practical split:

| Task type | Effort level |
| --- | --- |
| Renaming a variable across files | Low |
| Adding a field to a form | Low |
| Refactoring a module with many dependents | High |
| Debugging a subtle concurrency problem | High or XHigh |
| Designing an architecture across multiple systems | Max |

Set it at the start of a task, not when the agent gets stuck:

```bash
/effort low
```

```bash
/effort high
```

You can change it mid-session. Drop it back to low after a hard problem is solved and you are doing follow-up cleanup.

## Habit 4: Run /clear between tasks

Context is not free. The longer a session runs, the more likely the agent is to anchor on earlier decisions that no longer apply. A conversation that started with one refactor and drifted into a bug fix and then a new feature is carrying a lot of irrelevant context in its context window.

Run `/clear` every time you switch to an unrelated task. This is not losing your work. Your code is in the files. The conversation history is the agent's short-term memory, and it is usually better to start fresh than to carry stale assumptions. For exactly what gets cleared and what survives, see [how Claude Code memory works](/guides/how-claude-code-memory-works).

```bash
/clear
```

If you are in the middle of something long and do not want to lose the thread, use `/compact` instead. It summarises the conversation and keeps going, with less noise.

A useful pattern: treat each task as a session. Open Claude Code, complete one focused piece of work, clear, start the next. When you blur the boundary, you are paying context-window cost for history that does not help. You are also increasing the chance that the agent pulls in an assumption from an earlier task that is subtly wrong in the new one.

The agents that developers complain about being "dumb" or "drifting" are usually agents running in a context window full of old conversation that the user never cleared.

## Habit 5: Use custom commands and skills for repeated patterns

If you do the same kind of task more than twice, it should be a command or a skill. Skills are reusable instruction files Claude loads on demand. Commands let you encode a workflow into a single invocation. See [commands and skills](/guides/claude-code-commands-and-skills) for how to build them.

Examples worth building:

- A `code-review` skill that checks diffs against your team conventions.
- A `new-component` command that scaffolds a component with the correct folder structure for your project.
- A `db-migration` command that generates a migration file and checks for reversibility.
- A `check-types` command that runs the TypeScript compiler and asks Claude to fix only real errors, not to change unrelated types.

Once a skill exists, the invocation is a slash:

```bash
/code-review
```

The goal is that any pattern you repeat manually is eventually encoded so a junior (human or agent) cannot get it wrong.

Think of skills as your team's institutional knowledge in executable form. When a new developer joins and runs `/new-component`, they get the correct folder structure, the correct import pattern, and the correct test file automatically. They do not need to read a doc that may be out of date. They get the right output immediately.

This compounds. Every skill you write removes a whole class of review comments from your future PRs.

## Habit 6: Fan out for parallel, independent work

When a task has several independent parts, use subagents instead of running everything sequentially. The orchestrator hands off each part, the subagents run in parallel, and the results come back faster with less context bleed between concerns. See [how agents fan out](/guides/how-agents-fan-out).

Good candidates for fan-out:

- Running a migration across multiple unrelated modules.
- Generating tests for several components at once.
- Applying the same refactor to independent services.
- Auditing multiple areas of the codebase for a convention.

Split this work into three independent pieces: updating the API types, updating the client-side hooks, and updating the tests. Run each in parallel and report the results.

Do not fan out when tasks share state or have ordering dependencies. Sequential is correct in those cases. The rule of thumb: if two pieces of work could be assigned to two different developers without a handoff meeting, they can fan out. If they need to agree on a shared interface before either starts, do that interface work first, then fan out.

Fan-out is also useful for audits. If you want to check whether every route file in an API follows a certain pattern, you can spin up one subagent per route directory, run the check in parallel, and get a consolidated report far faster than a sequential scan.

## Habit 7: Review every diff before accepting

This is non-negotiable. Claude is fast and usually correct, but it will sometimes:

- Touch a file you did not expect it to touch.
- Change behaviour while refactoring something that looked structural.
- Add a dependency you do not want.
- Remove a guard it decided was redundant.

None of these are catastrophic if you catch them at diff review. They can be expensive if you catch them in production.

Build the habit of reading the diff the same way you would read a colleague's pull request. Pay attention to:

- Files you did not expect to see changed.
- Deletions. The agent removes things confidently. Removed code is not always dead code.
- New imports and dependencies.
- Changes to error handling, null checks, or guards.

If something looks wrong, say so and explain why. The agent takes corrections well at diff time. "You removed the null check on line 42, that check is intentional because the upstream can return null in the error case" is a complete correction.

One thing that trips developers up: the agent is optimising for the stated task. If you said "remove the unused variables," it will do that. If one of those variables was commented out temporarily during debugging, the agent does not know. That context exists only in your head. The diff is the moment to apply it.

Speed-reviewing is better than not reviewing. Even a 30-second scan of the changed files, before you run the code, catches most surprises. The full deep review is for larger changes.

## Habit 8: Give feedback in context, not after the fact

When the agent makes a wrong call, correct it immediately in the same conversation. Do not accept the output and then file a mental note to be more careful next time. Tell it now:

That is not quite right. The convention here is X, not Y. Redo just that part.

If the same mistake keeps happening, that is the signal to update `CLAUDE.md`. One correction in the conversation helps this session. One line in `CLAUDE.md` helps every session.

## The habits, in one table

| Habit | When | Why |
| --- | --- | --- |
| Write a tight `CLAUDE.md` | Once per repo, then maintain it | Every convention in the file is a mistake the agent will not make |
| Plan mode before big changes | Any task touching more than 2-3 files | A wrong plan is far cheaper to fix than wrong code |
| Set the right effort level | Start of each task | Saves time and cost on simple work, enables depth on hard work |
| `/clear` between tasks | Every time you switch context | Stale context produces anchored, wrong assumptions |
| Build skills for repeated patterns | After doing something twice manually | Encodes your team's standards as executable workflows |
| Fan out parallel work | When pieces are independent | Faster results, less context bleed |
| Review every diff | After every generation | You are the engineer, not the agent |
| Correct in context | When something is wrong | Immediate feedback loops are tighter and cheaper |

## What does a Claude Code session look like end to end?

Here is what a typical session with these habits looks like.

You open the repo. Claude reads `CLAUDE.md` automatically. You describe the task and ask for a plan before any code is written:

I need to refactor the payment module to use the new idempotency key pattern. Before you write anything, give me the full plan as a numbered list with one-sentence rationale per step.

You read the plan. Step 3 says it will update the webhook handler, which was not in scope. You push back:

Skip step 3 for now, the webhook handler is part of a separate PR. Do steps 1, 2, 4, and 5 only.

You set effort to high because this is not trivial:

```bash
/effort high
```

Claude works. You review the diff. You catch that it removed an early-return guard in the idempotency check. You explain:

Restore the early return on line 84. That guard is intentional: if the key already exists we want to return immediately without logging, because logging a duplicate would spam the audit trail.

It restores the guard. You accept the diff. You run `/clear` and start the next task.

That is the full loop. Each step is you making a decision that the agent cannot make for you, and letting the agent handle the execution. The output is yours because you shaped every step.

## What separates Claude Code power users from casual users?

The pattern that emerges from all these habits is active direction. Power users are not sitting back hoping the agent gets it right. They are investing a small amount of attention at each high-impact point: the `CLAUDE.md`, the plan, the effort setting, the diff, the correction.

Each of those is a moment where ten seconds of your attention produces better output than ten minutes of debugging would have fixed. That ratio is why the habits compound. The more consistently you apply them, the less cleanup you do, and the more you can trust the output that comes back.

The developers who get the most out of Claude Code are not the ones who trust it most. They are the ones who stay most engaged with what it produces.