Claude Code 101 Best Practices
These are the onboarding habits that get a new developer productive with Claude Code fastest, drawn from the fundamentals covered across this section.
How to Use This List
- Work through the groups roughly in order for a brand-new developer; each builds on the last.
- Treat the first-week items as non-negotiable; treat the ongoing habits as things to revisit periodically.
- Use this as an onboarding checklist for a team, not just an individual reference.
A - Get the Mental Model Right First
- Understand it's an agent, not autocomplete, before writing a single request. A new developer who treats Claude Code like line-completion will under-use it and get confused by its multi-step behavior.
- Learn the read, plan, act, verify loop before relying on it for real work. Knowing that one instruction can trigger multiple file edits and shell commands sets the right expectations from the start.
- Frame requests as outcomes, not step-by-step instructions. Describing the goal lets the agent plan the steps; over-specifying steps defeats the purpose of delegating the task.
B - Install and Connect Deliberately
- Verify the install with
claude --versionbefore doing anything else. A brokenPATHafter install is a common early snag that's easy to catch immediately. - Always launch from inside the actual project directory. Claude Code reads the current working directory as the project root, so launching from the wrong place gives it the wrong context.
- Start a new project with an orientation request, not a complex one. Asking it to summarize the project first confirms it read things correctly before you hand off real work.
C - Choose Permission Mode With Intent
- Default new developers to ask-every-time until they've built trust in the tool. Seeing each proposed action before it happens is the fastest way to learn how Claude Code plans in a specific codebase.
- Move to auto-accept only for well-scoped, low-risk, or already-reviewed tasks. Auto-accept trades a per-step checkpoint for speed, which only pays off once the plan is already trustworthy.
- Never use auto-accept for destructive operations or high-stakes code paths. Deletions, migrations, and authentication or payment code deserve ask-every-time regardless of experience level.
D - Use Plan Mode Before Trusting Execution on Unfamiliar Code
- Research first in Plan Mode for anything unfamiliar or ambiguous. Plan Mode restricts the agent to read-only investigation, so no real edit can happen before you've reviewed the plan.
- Actually read the proposed plan before switching to execution mode. A plan you didn't read gives you none of the safety benefit Plan Mode is meant to provide.
- Reserve straight-to-execution for small, well-understood tasks. Skipping Plan Mode is reasonable once a task is clearly low-risk and you've done something similar before.
E - Set Up the Terminal for Speed Early
- Add a shell alias for launching Claude Code in your first week. A one-word alias like
alias cc="claude"is a small setup cost with an immediate daily payoff. - Confirm font and rendering work cleanly with the REPL's interactive UI. Fixing rendering issues early avoids a confusing experience that has nothing to do with the agent itself.
- Adopt one terminal tab per active project once you're juggling more than one. This keeps sessions cleanly separated instead of losing track of which project a session is connected to.
F - Know When to Reach for Extended Thinking
- Reserve Extended Thinking for genuinely hard, multi-step problems. Architecture decisions, subtle bugs, and complex refactors benefit from deeper deliberation; small fixes usually don't.
- Expect a latency and cost trade-off when using it. More reasoning time before a plan is formed is not free, so it's worth reserving for problems that actually need the depth.
- Match the model to the task's difficulty. Haiku 4.5 for fast, low-stakes work, Sonnet 5 as the balanced default, Opus 4.8 for harder reasoning, and Fable 5 when you want reasoning depth to adjust automatically.
G - Build Ongoing Habits, Not Just First-Week Steps
- Commit your work before any auto-accept or execution-mode session with real consequences. Version control is the practical safety net underneath every permission mode.
- Revisit permission mode and Plan Mode choices as trust builds in a specific codebase. Comfort in one project doesn't automatically transfer to an unfamiliar one; keep evaluating per project, not just per developer.
- Periodically clear or compact long sessions. A session that's grown very long can slow down or dilute context, so
/compactor/clearis worth using as a routine habit, not just a fix for a stuck session.
FAQs
What's the single most important habit for a brand-new developer?
Understanding the agent mental model first. Every other habit on this list, permission mode, Plan Mode, terminal setup, assumes the developer already knows Claude Code plans and acts rather than just completing lines of text.
Should every new developer start on ask-every-time permission mode?
Yes, as a default. It's the fastest way to build an accurate sense of how Claude Code plans in a specific codebase, and moving to auto-accept later is a natural progression once that trust exists.
Is Plan Mode necessary for every task?
No, only for unfamiliar, ambiguous, or high-stakes work. Small, well-understood tasks are reasonable to send straight to execution mode.
Why does terminal setup make this list alongside things like permission modes?
Because Claude Code lives entirely inside the terminal, a clunky terminal setup slows down every single session, even when the agent itself is working correctly.
What's the biggest mistake onboarding a whole team at once?
Letting individual developers skip ask-every-time and jump straight to auto-accept before they've built any track record with the tool in that codebase, which removes the fastest feedback loop for learning how it plans.
Does Extended Thinking belong in a beginner's onboarding checklist?
Knowing it exists and roughly when to reach for it is worth including early, even though a beginner won't need it often; most early tasks are simple enough not to require deeper deliberation.
How often should the ongoing habits in section G actually be revisited?
Committing before risky sessions should happen every time. Reassessing permission mode and Plan Mode choices is worth doing per new project, not just once when a developer first starts using the tool.
Is this checklist meant for individuals or for teams?
Both, but it's written with team onboarding in mind. A team can use it directly as a shared first-week checklist for any new developer picking up Claude Code.
What happens if a developer skips the terminal setup section?
Nothing breaks, but every session is slower than it needs to be, since launching, switching, and reviewing all take more manual steps without aliases and a clean terminal setup.
Why is committing to version control listed as a best practice here rather than assumed?
Because it's the practical safety net that makes auto-accept and execution-mode sessions safe to use quickly. Skipping it removes the fastest way to recover from a plan that turned out to be wrong.
Related
- The Claude Code Mental Model: Agent, Not Autocomplete - the foundational concept every other habit in this list builds on.
- Permission Modes Explained: Auto-Accept vs Ask-Every-Time - the full comparison behind the section C practices.
- Switching Between Plan Mode and Execution Mode - the full workflow behind the section D practices.
- Terminal, Shell and Hotkey Setup for Claude Code - the full reference behind the section E practices.
- Extended Thinking Mode: When Claude Code Reasons Longer - the full explainer behind the section F practices.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.