Claude Code Best Practices for Maximum Efficiency

I used to think Claude Code best practices were a matter of taste. Plan mode or not. Long CLAUDE.md or short. Pick what suits you, move on.

Then Anthropic scored roughly 400k sessions from over 235k users against hard evidence of success. Tests passing, commits landing, users confirming they got what they asked for. Taste turned out to be measurable. In this article, I’ll walk through what separated the sessions that worked from the ones that didn’t.

The gap had nothing to do with the model. It was behaviour.

And the study didn’t define expertise by job title or years of experience. It read three things off the transcript:

1. Precision: how precisely the person framed their directions
2. Verification: what they asked Claude to check before trusting it
3. Correction direction: whether the person corrected Claude, or Claude corrected the person

One thing to note before we get into them: expertise here is task-specific. A senior engineer asking their first Rust question is a beginner at Rust. An accountant who’s never written Python, but who tells Claude exactly which reconciliation rules to enforce and catches the edge case it fumbles at month end, is an expert at that task. All ten of the largest occupation groups landed within seven points of software engineers.

Lesson 1: Precision in How You Ask

The study found that in novice sessions, each prompt set off about five Claude actions and roughly 600 words of output. In expert sessions, each prompt set off about twelve actions and 3,200 words. More than twice the work and five times the output, from the same tool.

The difference is not prompt length. It is whether the prompt contains the things Claude cannot infer: which file, which scenario, what counts as done, and what pattern to follow.

The four upgrades that matter most

Notice what the right-hand column has in common. Each one names a location, a scenario, and a definition of done. None of them is longer than two sentences of real information.

Stop describing files, start handing them over

This is the habit I picked up latest and regret most. Rather than telling Claude where something lives, give it the thing directly:

# Reference a file inline, Claude reads it before answering
> explain the token refresh logic in @src/auth/session.ts

# Pipe data straight in, works on files outside the project
cat error.log | claude -p "group these errors by root cause"

# Paste or drag an image directly into the prompt
> [screenshot] implement this design

You can also give Claude URLs for API docs and let it fetch what it needs itself. Use /permissions to allowlist domains you hit often so you are not approving the same fetch repeatedly.

Give Claude the right tools, not just the right words

A precision habit that is easy to miss: the tools available to Claude shape how precisely it can act. CLI tools are the most context-efficient way to reach an external service, because the output comes back compact and Claude already knows the syntax.

If you use GitHub, install the gh CLI. Claude will use it to open issues, create pull requests, and read comments. Without it, Claude falls back to the GitHub API, where unauthenticated requests hit rate limits. The same applies to aws, gcloud, and sentry-cli.

It also learns tools it has never seen. This prompt shape works surprisingly well:

Use 'foo-cli-tool --help' to learn about foo tool, then use it to
solve A, B, C.

For services with no good CLI, MCP servers are the answer. Our guide to connecting MCP servers with Claude covers the setup for both Claude Desktop and Claude Code.

For anything large, let Claude interview you first

This one felt strange the first time and is now how I start every feature bigger than a day of work. Instead of writing a long spec yourself, make Claude extract it from you:

I want to build [brief description]. Interview me in detail using
the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns, and
tradeoffs. Don't ask obvious questions, dig into the hard parts I
might not have considered.

Keep interviewing until we've covered everything, then write a
complete spec to SPEC.md.

It surfaces the decisions you’d otherwise hit halfway through implementation. Once the spec is done, start a fresh session to build it, so the implementation has clean context and a written document to work against.

The best specs name the files and interfaces involved, state what’s out of scope, and end with an end-to-end check that proves the feature works. Time spent sharpening the spec pays back more than time spent watching the build.

Try this now: Take the next feature on your list. Paste the interview prompt above with a one-line description. Answer honestly, including the questions you don’t have answers to yet. That gap is the actual work.

Lesson 2: Give Claude Something It Can Check

This is the habit that pays back most, and the one I see skipped most.

Claude stops when the work looks done. If there is no check it can run, then “looks done” is the only signal available, and you become the verification loop. Every mistake waits for you to notice it.

Give Claude something that returns pass or fail and the loop closes on its own. Claude does the work, runs the check, reads the result, and iterates until it passes. A test suite, a build exit code, a linter, a script that diffs output against a fixture, a browser screenshot compared to a design. Anything that produces a signal it can read.

# Weak: no way to know when it is done
> implement a function that validates email addresses

# Strong: the check is in the prompt
> write a validateEmail function. test cases: [email protected] is true,
  'invalid' is false, '[email protected]' is false. run the tests after
  implementing.

Four levels of how hard the check gates the work

Once a check exists, you choose how strictly it stops Claude from declaring victory. Each level trades a bit of setup for a bit less of your attention:

Worth knowing about Stop hooks: Claude Code overrides the hook and ends the turn after 8 consecutive blocks. It will not loop forever if your check can never pass.

The prompt version works on any task right now. The /goal and Stop hook versions are what let an unattended run finish correctly while you are somewhere else. That is the real payoff.

Ask for evidence, not assurance

Related habit that costs nothing: tell Claude to show the test output, the command it ran and what came back, or a screenshot of the result. Reading evidence is faster than re-running the verification yourself, and it is the only way to review a session you were not watching.

The adversarial review step

The longer Claude works without you, the more an independent check matters before you call it done. A reviewer running in a fresh subagent context sees only the diff and the criteria you give it, not the reasoning that produced the change. So it judges the result on its own terms.

Use a subagent to review the rate limiter diff against PLAN.md.
Check that every requirement is implemented, the listed edge cases
have tests, and nothing outside the task's scope changed.
Report gaps, not style preferences.

Because the reviewer is a subagent, findings come back into the same session, so Claude can fix them and re-review without you copying text between windows. There is also a bundled /code-review skill that reviews the current diff for bugs in a fresh subagent if you just want a correctness pass.

Use subagents to investigate how our authentication system handles
token refresh, and whether we have existing OAuth utilities I
should reuse.

claude --permission-mode plan

> read /src/auth and understand how we handle sessions and login.
  also look at how we manage environment variables for secrets.

> I want to add Google OAuth. What files need to change?
  What's the session flow? Create a plan.

> implement the OAuth flow from your plan. write tests for the
  callback handler, run the test suite and fix any failures.

> commit with a descriptive message and open a PR

# 1. Have Claude generate the task list first
# 2. Then loop, one invocation per file

for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)"
done