I watched the Claude Best Practises video so you don't have to
There is a twenty-five minute talk called “Claude Code best practices,” given by Cal Rueb, one of the engineers on the team that builds it. It is the rare conference talk with no padding. It is still twenty-five minutes, and I know most people reading this will not press play. So I watched it twice with a notebook open. This is the summary, and my honest take on which bits are worth your time.
Start with the verdict, because that is the real question. If you open Claude Code more than a few times a week, watch the whole thing tonight. If you do not, the next five minutes give you the four habits that actually matter without the stage lighting. Rueb is not pitching you anything. He is showing you how the person closest to the tool drives it, and at least two of those moves were not obvious to me. I use this thing every day.
That last part is the embarrassing bit. I write software for clients who pay by milestone, which means I spend more time in other people’s codebases than my own, usually code I did not write and nobody at the company can fully explain anymore. I thought I had Claude Code figured out. I was using maybe a third of it. Here is what I changed the same afternoon.
Tell it not to write code yet
The single highest-leverage habit in the whole talk is the most boring one. Before you ask Claude Code to do anything non-trivial, tell it to make a plan and not touch a file. Rueb’s framing was blunt: don’t start working. Ask for the approach first.
The reason this works is mechanical. Once the model starts editing, every later token is anchored to the first decision it made, even when that decision was wrong. A plan is cheap to throw away. Two hundred lines of code built on a bad assumption are not. I now type “plan this out, do not edit anything yet” so often it has become a reflex. Half the time the plan is good and I say go. The other half I catch the wrong assumption in a sentence, before it became a diff I had to read line by line.
It searches your repo, it does not memorise it
This was the part that actually changed my mental model. I assumed Claude Code worked by quietly indexing my whole project into some vector database and looking things up. It does not. There is no embedding step, no RAG, no index sitting in a hidden folder.
It explores the way a human does. It runs grep, glob, find, opens the files the results point at, reads them, follows the trail. Rueb called it a very pure agent. The model loops with terminal tools until it has seen enough to answer, the same way you would grep for a function name and start clicking through.
Once that clicked, two things made sense. First, why it works on a repo it has never seen with zero setup. There is nothing to index. Second, why CLAUDE.md matters so much. It is the one file the model reads every single time before it starts searching, so it is where you put the things grep will never tell it.
# CLAUDE.md
## What this is
Internal ops dashboard for a logistics client. React front end,
FastAPI back end, MSSQL holding three years of invoicing data.
## House rules
- Never run a destructive docker compose command. Ask first.
- Run `just check` before telling me something works.
- The invoicing tables are sacred. Read them, never migrate them.
@docs/architecture.mdThat @docs/architecture.md line pulls a second file in by reference, so you keep the main file short and point at the detail only when it is needed. The newer models follow these instructions well enough that I keep the file small. When Claude ignores something, my first move now is not to write three more paragraphs of rules. It is to check whether a model upgrade fixes it, because usually it does.
The coworker who already read the git log
Rueb described Claude Code as the coworker who does everything in the terminal, the one who already knows the repo. That is the use case I underrated for months. I was so focused on getting it to write code that I forgot it is better at reading.
Hand it a feature you cannot find and it will locate the implementation across six files faster than you can open the first one. Ask it why a function exists and it will read the git history and tell you which commit introduced it and what the message said. Point it at the legacy module everyone is scared to touch and ask it to explain the control flow before anyone changes a thing. On a new client codebase this has replaced the two days I used to spend reading in circles, lost.
The origin story in the talk is the tell. Rueb built a note-taking app over a single weekend with it, got so absorbed he carried his laptop around the whole time watching it come together, then found out he had topped an internal usage leaderboard and ended up joining the team. Nobody gets that obsessed with autocomplete. You get that obsessed when a tool quietly deletes the boring half of the job.
Claude Code is not your typist. It is a new hire who reads the whole repo in a minute and forgets all of it the moment you close the window.
Correct it in the first ten seconds
The last habits are about staying in control once it is running.
When it starts going the wrong way, hit Escape. Do not let it finish the wrong thing out of politeness and then explain your disappointment after the fact. Interrupting costs nothing, and it drops you back in before the bad plan hardened into a diff you have to unpick.
For anything hairy, put the words “think hard” in the prompt. The current models think between tool calls, and that phrase buys more of it. Rueb’s advice was to throw a think hard in there on bugs and exploration, and it is a real difference, not a placebo. When the context gets cluttered and the model starts losing the plot, /clear and start clean rather than fighting a conversation that has gone stale. And if a task splits into independent parts, run more than one Claude Code at once. To make them cooperate, have each write to a shared markdown file the others read. Crude, and it works.
Use it to understand before you build
Go watch the talk. It is the rare twenty-five minutes that pays for itself the same day. Then, on your next real task, do one thing differently: open Claude Code on a repo you do not fully understand and refuse to let it write a single line until it has read the code and shown you a plan you agree with. Spend a week using it to understand before you use it to build. The building gets easier once you trust that it actually read the thing first.
If you want it from the source, watch Cal Rueb’s talk here. Twenty-five minutes, no fluff, and it will change how you open your terminal tomorrow.