Claude Code Tips: Seven Habits Worth Building Early
Most advice about getting more out of a coding agent is about writing better prompts. Some of that helps. But the habits that made the biggest difference for me aren't about phrasing at all — they're about what I hand over, when I stop, and what I check.
None of these are clever. They're the things I'd tell someone on their first week — which is not the same as saying I did them from mine.
1. Ask for the plan before the diff
The fastest way to waste twenty minutes is to let an agent start editing files before you've agreed on what it's doing. Asking for the approach first — which files, what order, what it thinks the tricky part is — costs one exchange and surfaces the misunderstanding while it's still cheap to fix.
It also tells you something useful when the plan comes back thin. A vague plan usually means the request was vague, and that's easier to fix in the plan than in the diff.
2. Point at the file instead of describing it
When you paraphrase what's in a file, the agent works from your paraphrase. When you name the file, it works from the file. Those are different inputs, and the second one is more reliable — your memory of a config you wrote three months ago is not a great source.
This applies to anything you're tempted to summarize from memory: the schema, the existing convention, the way the other endpoint does it. Naming the path is fewer words than describing the contents, and it's the version that's actually true.
3. Hand over the command that proves it worked
"Add validation to the signup form" and "add validation to the signup form; npm test should pass" are very different requests. The second one includes a way to check the answer, so the agent can tell whether it's done rather than guessing.
If there's no such command, that's worth noticing. Work you can't verify from the outside is work you'll be reviewing by eye, and reviewing by eye is where things get through.
4. Commit first, then let it work
A clean checkpoint before you start turns "undo this" into one command. Without it, separating the change you wanted from the four changes you didn't means reading a diff line by line.
This is the habit that most reliably converts a bad session into a two-second recovery, and it costs nothing.
5. Let it read the error
The reflex is to copy an error out of the terminal and paste the interesting-looking part. That's a lossy step — you're choosing what matters before you know what matters. Letting the agent run the failing command and read the whole output means it sees the stack trace, the warning three lines above it, and the exit code, rather than the fragment you found legible.
I still catch myself summarizing errors. It's a hard reflex to lose, because for years the person reading the error was me.
6. Start a new session when the thread has drifted
Long sessions accumulate. Decisions you reversed, a file you abandoned, an approach you talked yourself out of — and some of that is still shaping what comes next. Long conversations do get compacted as they grow, which helps with length, but compaction summarizes the history rather than working out which parts you've moved past. When answers start feeling anchored to something you've already abandoned, that's usually what's going on.
Starting fresh with a short summary of where things actually stand is faster than arguing the history back out. This one is easy to resist, because a long session feels like accumulated progress.
7. Say what not to touch
Most instructions describe the target. Fewer describe the boundary — the files that shouldn't change, the dependency that's pinned for a reason, the config that looks wrong and isn't.
When I handed a portfolio of repositories to an agent to standardize, what kept that safe was a two-phase brief — audit everything first, change things only after approval. Boundary information belongs in the same category: a per-repo facts file recording the do-not-touch list, so that "inconsistent" doesn't get read as "broken."
The pattern underneath
Three of these are the same move: point at the file, hand over the command, let it read the error. Each one gives the agent the real artifact instead of your description of it — and your description is the lossy part, every time.
The other four are about scope. Agree on the approach before anything changes, keep a checkpoint to fall back to, drop the history once it stops helping, and mark what's off-limits.
Both halves come from the same place: the agent can work from the artifact, or from your account of the artifact. The first three hand over the artifact. The other four keep your account of it from quietly standing in for the thing itself.
If you want the longer version of one way to package reusable context so you're not retyping it every session, see my guide to Claude Code skills.
FAQ
What are the best Claude Code tips for beginners? Ask for a plan before any edits, name files instead of describing them, and commit before you start so you can undo cleanly. Those three cost nothing and are easy to make automatic.
How do I get better results from Claude Code? Give it access to the things it can check: the actual file, the failing command, the test that has to pass. When a result disappoints, it's worth asking whether the agent was working from the problem or from your description of it.
When should I start a new Claude Code session? When the conversation starts producing answers anchored to decisions you've already reversed. A short summary of current state in a fresh session usually beats correcting the accumulated history.