Claude Code Best Practices I Actually Follow (2026)

A year of shipping code with Claude Code has turned into a small bag of habits. None of these are "use git" or "write tests" — obvious advice that doesn't need me. These are the things I actually do before, during, and after a Claude Code session.

Before the Session

1. Start with a clean diff

Commit or stash whatever you have before prompting. A clean git status means every line Claude adds or removes is visible in the review. If you start with 50 modified files, you'll lose Claude's changes in the noise.

2. Write a one-paragraph goal

Before touching Claude, write down what you want in plain English in a text editor. One paragraph. What are we building, why, what are the constraints, what should it NOT do. Then paste that as the first message. This takes 2 minutes and saves 20.

3. Point at specific files

Don't let Claude guess which files to read. Tell it: "Read src/app/api/users/route.ts and src/lib/auth.ts first." Reading the right files is half the job. Claude is good at reading when you tell it what to read; it's bad at picking when you don't.

During the Session

4. Let Claude write a plan first

For anything nontrivial, ask Claude to write the plan before writing the code. "Before making changes, describe the files you'll touch and the approach. I'll confirm, then you code." This catches wrong-direction bugs before they become wrong-implementation bugs.

5. Short turns

Each turn should be about one logical change. Not "build the entire feature" — "add the input validation, then stop." You can review a small change. You cannot review a 300-line diff that spans 8 files.

6. Read the diff every time

Not skim. Read. Every turn. Yes it's slow. Yes it feels like it defeats the purpose. The alternative is shipping silent deletions and you will ship them, I promise.

7. Say 'no' explicitly

If Claude does something you didn't ask for (refactoring unrelated code, adding a feature flag, converting promises to async/await), call it out in the next message. Not just "revert that" — explain why, so it doesn't do it again in the same session.

Between Sessions

8. Run the build after every session

Not the dev server. The actual production build. npm run build. This catches the hallucinated imports, the TypeScript errors Claude "forgot" to mention, and the Tailwind purge failures. If the build doesn't pass, you're not done.

9. Lint and format

Run prettier and eslint. Claude's style drifts subtly between turns, and you'll end up with a file that has 3 different quote styles. Running the formatter fixes this before it becomes a "refactor all files for style" PR.

10. Commit Claude changes separately from manual changes

If you reviewed Claude's diff and also made your own edits, commit them as two commits. This makes bisect much easier later and lets you revert just the AI part if something goes wrong.

Before Shipping

11. Run the checklist

This is the point of this whole site. 25 items, 15 minutes, catches the bugs that would cost you hours in production. Non-negotiable for anything touching real users.

12. Test the happy path manually

Before considering a feature "done", click through it yourself as a user. Sign up, click the button, see the result. AI tests don't catch "the button is invisible" or "the result text is white on white". You will.

What I Don't Do

I don't use auto-accept modes. I don't let Claude run long chains of commands without review. I don't trust any "this works on my end" from the AI (it doesn't have an "end"). I don't let it touch .env files or secrets. I don't use it to generate test data that ends up in prod ("John Doe, john@example.com" everywhere is a red flag).

Most of these habits came from getting burned once. The checklist on this site captures those burns as items. The habits are how I avoid the burns in the first place.