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.

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

Good CLAUDE.md sections to include:

## 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.Common gotchaThe 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 modeA setting where Claude lays out the steps it intends to take and waits for your approval before touching any files. 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.

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:

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.Common gotchaThe 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.

Habit 3: Set the right effort level per task

EffortA dial for how much thinking the model spends on a task. Higher effort means more reasoning, more time, and more cost. 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 for the full breakdown.

The practical split:

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

/effort low

/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 windowThe total amount of text, your prompts plus the conversation so far, that the model can hold in mind at once. It is finite..

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.

/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 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:

/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 subagentsSeparate helper agents that each handle one slice of work in their own context, so several pieces run at once. 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.

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.

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 diffA side-by-side view of exactly what changed: which lines were added and removed, before you accept the edit. 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:

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

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:

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

You set effort to high because this is not trivial:

/effort high

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

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.