Claude Code

Claude Code tips: 10 habits that get better results

Most "Claude Code is bad at this" complaints come from the same few causes: a vague goal, no way to check the result, and a context window full of old junk. These ten habits fix most of them. If you have not used it yet, start with what Claude Code is.

1. Say the outcome, not the activity#

"Fix the bug" forces a guess. "Fix the login bug where users see a blank screen after entering wrong credentials" does not. Include the symptom, where you see it, and what done looks like.

2. Let it explore before it edits#

Ask for understanding first: analyze the database schema, how does auth work in this repo?. The agent builds a map, and you catch wrong assumptions before they become code.

3. Give it a way to check its own work#

This is the biggest lever. Name the command: "run pnpm test auth and fix failures", "run the type check after each file". An agent that can read a failing test fixes things in a loop. One that cannot will confidently stop.

No checkWrites the codeSays it is doneYou find the bug in reviewWith a checkWrites the codeRuns the test, reads the failureFixes it, runs again, then hands backvs

4. Break big work into steps#

text
1. create a table for user profiles
2. add an API endpoint to get and update a profile
3. build a page that shows and edits it

Small steps are reviewable. A 40-file diff is not.

5. Keep the context clean#

Context is the agent's working memory, and it is finite. Run /clear between unrelated tasks. If a session has gone sideways after three corrections, start fresh with a better first prompt instead of arguing. claude -c continues the last conversation and claude -r lets you pick one.

6. Write the repeated stuff down once#

Same correction twice? It belongs in CLAUDE.md: build commands, conventions, no-go folders. Keep it short and checkable.

7. Choose the permission mode on purpose#

Shift+Tab cycles the mode. Use the strict default for unfamiliar code, loosen it for well-tested changes. Always read the diff before committing.

8. Use hooks for must-never rules#

"Never edit generated/" in CLAUDE.md is a request. A PreToolUse hook is a rule. If breaking it is expensive, enforce it.

9. Use it from scripts#

bash
claude -p "list every TODO in src/ grouped by file"

-p runs one prompt and exits, so you can pipe results or call it in CI.

10. Review like it is a junior's pull request#

Run the tests yourself, read the diff, question anything surprising. Your name is on the commit. This is the Diligence part of the 4D framework, and it is what separates AI-assisted engineering from vibe coding.

Quick recap#

HabitWhy it works
Specific outcomeRemoves guessing
Explore firstCatches wrong assumptions early
Verification commandLets the agent self-correct
Small stepsReviewable diffs
/clearFresh, relevant context
CLAUDE.mdStops repeated mistakes
HooksEnforcement, not hope

Frequently asked questions

How do I get better results from Claude Code?

Be specific about the outcome, let it explore the code before changing it, give it a test or command it can run to verify its work, keep tasks small, and record repeated instructions in CLAUDE.md.

When should I use /clear in Claude Code?

Between unrelated tasks. A long conversation fills the context window with stale detail, and starting fresh with a clear prompt usually works better than correcting a confused session.

Can I run Claude Code in scripts or CI?

Yes. claude -p "query" runs a single prompt non-interactively and prints the result, which is what you use in scripts.

How do I stop Claude Code from doing something dangerous?

Use permission modes for day-to-day control and a PreToolUse hook for anything that must be blocked every time. Instructions in CLAUDE.md are context, not enforcement.