Claude Code Best Practices: Lessons from Teaching 100+ Students

I've trained over 100 people on Claude Code at this point. PMs, founders, designers, engineers. The gap between people who get incredible results and people who struggle isn't intelligence or technical skill. It's habits.

Specific, learnable patterns that turn Claude Code from a frustrating autocomplete into something that actually ships software for you. Here are the 10 that move the needle, pulled from teaching real people to build real things.

1. Always Create a CLAUDE.md First

Practice zero. Before you write a single prompt, create a CLAUDE.md file in your project root. This is Claude Code's persistent memory. It reads it at the start of every session.

A good CLAUDE.md tells Claude what your project is, what stack you're using, what conventions to follow, and any hard rules. Something like:

# Project: Expense Tracker
## Stack: Next.js 14, TypeScript, Tailwind, Supabase
## Rules:
- Always use TypeScript strict mode
- Use server components by default
- Style with Tailwind, never inline CSS
- Use shadcn/ui for all UI components

Without this, every session starts cold. Claude guesses your preferences, and guesses lead to inconsistency. With a good CLAUDE.md, Claude hits the ground running every time. I've watched this single file cut wasted iterations by half.

2. Use Plan Mode for Anything Complex

Claude Code has a plan mode. Press Shift+Tab to toggle it on, or just say "plan this out first." For any task that touches more than 2 or 3 files, use it.

Without plan mode: Claude starts building, gets 3 files deep, realizes the architecture doesn't hold up, and either produces something messy or paints itself into a corner. You end up saying "actually, start over." Wasted time, wasted tokens.

With plan mode: Claude lays out its approach first. You review it, push back, suggest changes, then let it execute. 30 seconds of planning saves 10 minutes of backtracking. I tell every student: if the task spans more than one file, plan it first.

3. Describe Outcomes, Not Implementations

Bad prompt: "Create a React component with useState that maps over an array and renders a list with delete buttons that call a filter function."

Good prompt: "I need a task list where users can add tasks, mark them complete, and delete them. Completed tasks should be visually distinct (strikethrough or grayed out). Put the add form at the top."

The first prompt does Claude's job for it, badly. Claude is better at picking implementations than you are (sorry). The second prompt describes behavior, appearance, and user experience. Claude figures out the code, and it usually picks a better approach than what you would've specified.

Hardest habit for engineers to learn. Non-engineers actually have an advantage here because they naturally describe what they want in user terms.

4. Build Incrementally

The #1 mistake I see: someone describes an entire application in one massive prompt. "Build me a project management tool with user auth, team workspaces, kanban boards, drag-and-drop, real-time updates, file attachments, and email notifications."

Claude will try. It might even produce something. But the result will be brittle, hard to debug, and full of half-baked features. Build one thing at a time instead:

1. "Set up a Next.js project with TypeScript and Tailwind."
2. "Create a kanban board with 3 columns: To Do, In Progress, Done."
3. "Add the ability to create new cards with a title and description."
4. "Add drag and drop between columns."
5. "Add user authentication with Supabase."

Each step builds on the last. Each step produces something you can test. If step 4 goes wrong, you only fix step 4, not unravel an entire application. This mirrors how professional software gets built, and it's how you get the best results from Claude Code. (We walk through this exact pattern in the hands-on tutorial.)

5. Use Git So You Can Roll Back

Claude Code writes and modifies files directly on your filesystem. If it makes a mess (and sometimes it will), you need a way to undo everything and try again. Git is that way.

My rule: commit after every successful change. Your git history should look like:

"Add basic kanban board layout"
"Add card creation form"
"Add drag and drop between columns"
"Add Supabase auth"

If Claude's attempt at drag-and-drop wrecks everything, you run git checkout . and you're back to the last working state. Without git, you're stuck trying to manually undo changes across a dozen files. I've watched people lose hours of work because they didn't commit before a big change. Don't be that person.

6. Create Skills for Repeated Workflows

Skills are markdown files in your .claude/skills/ directory that teach Claude Code specific workflows. If you keep giving Claude the same instructions over and over, put them in a skill file.

Example: you always want new pages to follow a specific pattern (server component, fetch data, pass to client component, specific layout). Write a skill for it:

# .claude/skills/new-page.md
When creating a new page:
1. Use server components for the page file
2. Fetch data in the server component
3. Create a separate client component for interactivity
4. Always include metadata export
5. Use the AppLayout wrapper
6. Add loading.tsx and error.tsx

Now you say "create a new settings page" and Claude follows your exact pattern without you re-explaining it. Write the skill once, reap the benefit forever. That compounds.

7. Review What Claude Builds

Claude Code is wildly capable, but it isn't infallible. It will sometimes install packages you don't need, bolt on complexity you didn't ask for, or implement something that works but isn't what you wanted.

After Claude finishes a task, always do 3 things:

1. Test it. Actually run the app and use the feature. Click every button. Try edge cases.
2. Read the diff. Run git diff and skim what changed. Look for surprises: new dependencies, deleted code, unexpected file changes.
3. Ask questions. "Why did you add that package?" or "Walk me through how this component works." Claude explains its reasoning, and sometimes that reveals misunderstandings.

This isn't about distrust. It's about staying in control of your codebase. The people who get the best results are engaged reviewers, not passive acceptors.

8. Learn to Recognize Error Patterns

When something breaks (and it will), Claude Code usually spits out an error message. Most non-engineers see a wall of red text and freeze. Here's the thing: you don't need to understand the error. Just copy it back to Claude.

But over time, learn to spot the common patterns:

• "Module not found": a package isn't installed or an import path is wrong
• "Type error": TypeScript found a mismatch (Claude usually fixes these instantly)
• "EADDRINUSE": something is already running on that port
• "Permission denied": file access issue, usually fixable with a permission change
• "Cannot read property of undefined": something expected data that wasn't there

You don't need to fix these yourself. But recognizing them lets you give Claude better context. "I'm getting a module not found error for the auth package" is more useful than "it's broken." This skill develops naturally if you pay attention.

9. Start Each Session with Context

Claude Code reads your CLAUDE.md at the start of each session, but it doesn't remember your previous conversations. If you spent yesterday building a feature and you're picking up where you left off, brief Claude:

"Yesterday I built the expense tracking feature. Today I need to add
monthly totals and a chart. The expenses are stored in Supabase in the
'expenses' table with columns: id, amount, category, date, description."

That 20-second context dump saves Claude from re-discovering your project structure. It also prevents Claude from making changes that conflict with yesterday's work. Think of it like briefing a contractor at the start of each day: a minute of context saves an hour of misunderstanding.

10. Use /compact When Conversations Get Long

Claude Code has a context window (the amount of text it can "see" at once). As your conversation gets longer, older messages start falling out. This leads to Claude forgetting earlier decisions, re-introducing bugs you already fixed, or contradicting itself.

The /compact command compresses your conversation history into a shorter summary, freeing up context space. Use it when:

• Your conversation has been going for more than 20 to 30 messages
• Claude starts repeating itself or forgetting earlier context
• You're shifting to a new task within the same session
• You see the context window indicator getting full

Some people just start new sessions instead. That works, but you lose all conversational context. /compact preserves the important bits while stripping out the noise.

The Meta-Practice: Stay Engaged

The biggest predictor of success with Claude Code isn't any single trick. It's engagement. The people who get great results are paying attention, asking questions, iterating, and learning from each interaction. The people who struggle type a prompt, walk away, come back to something broken, and blame the tool.

Claude Code is a collaborator. The better you collaborate (clear instructions, incremental steps, active review) the better the output. That's true whether you're an engineer with 20 years of experience or a PM who's never opened a terminal before.

Want to drill these practices hands-on? In ClaudeFluent, we work through all 10 with real projects so they become muscle memory. Also check out how to use Claude Code for the core workflow.