Claude Code: A Practical Guide to Tips and Best Practices

In just a few months Claude Code has gone from an experiment to a daily tool: in Anthropic he uses it approximately’80% of the technical people, engineers and researchers. Yet, faced with a simple prompt bar, the question of those who open it for the first time is always the same: where do we start? This practical guide collects tricks and best practices to use it really well, adapted from the talk of Boris, member of the Anthropic technical staff and creator of Claude Code. No history and no theory: just operational advice, in the order in which he presented them.

Before you start: how to install it

Boris opens the talk with a request to the audience: if you haven't already done so, open your laptop and install Claude Code so you can follow the examples. The only prerequisite is Node.js: If you have already installed it, the installation works without any further steps.

What is Claude Code

Claude Code is a new type of AI assistant for programming. There have been several generations of code assistants: most were used to complete one line at a time, or a few lines at a time. Claude Code was not created for this: it is completely agentic. It is designed to build entire features, write complete functions and files, and fix entire bugs in one go.

The interesting thing is that works with all your tools, without forcing you to change your workflow. Whatever IDE you use—VS Code, Xcode, JetBrains IDEs, Vim, Emacs, Zed—Claude Code works with them, because it runs in every IDE and every terminal. It works locally, as well as on Remote SSH or inside Tmux: Whatever environment you're working in, you can run it. There are people at Anthropic who wouldn't let cold, dead hands take their IDE away, yet they still use Claude Code precisely because it works with any setup.

Being general purpose, it can be confusing at first: you open the tool and see only a prompt bar, and you're wondering what to write. It's a powerful tool, usable for many things, and precisely because it can do so much, it doesn't impose a precise workflow on you: as an engineer, you should be able to use it however you like.

The recommended initial configuration

When you open Claude Code for the first time, there are a few things you should fix right away. They're simple:

• /terminal-setup - ability Shift+Enter to start a new line, so you don't have to use backslashes to insert new lines. This makes it more convenient to use.
• /theme — set light theme, dark theme or “colorblind” themes (for colorblind people).
• /install-github-app — install the GitHub app that lets you mention @claude on any GitHub issue or pull request. To install it, simply run this command in the terminal.
• Customize allowed tools —so you're not asked for confirmation every time. For transactions you're asked about frequently, it's best to set them up once and for all and avoid repeatedly accepting them.
• Voice Dictation (macOS) — a trick Boris often uses: he doesn't type many prompts. On macOS, in System Settings → Accessibility → Dictation, enable dictation; then just double-press the dictation button and dictate the prompt by voice. Having specific prompts is very helpful: you can talk to Claude Code as you would to another engineer, without having to write a lot of code by hand.

Where to start: Ask questions of your code

The thing that Boris recommends more than anything else to start with is the Q&A about the code: Ask questions about your codebase. This is what new hires at Anthropic are taught: on their first day of technical onboarding, they learn about Claude Code, install it, configure it, and immediately start asking questions about the code.

In the past, technical onboarding was a huge burden on the team: you had to ask other engineers, explore the code by hand, and figure out how to use the tools. With Claude Code, you can simply ask, and he explores the codebase and responds. The result: at Anthropic, technical onboarding has gone from about two or three weeks to about two or three days.

An important aspect of the Q&A: there is no indexing. There is no remote database with your code, it is not loaded anywhere, it remains in local under your control. No generative models are trained on your code. This also means no setup or waiting: you download Claude Code, launch it, and use it immediately, without waiting for it to index anything.

Some concrete examples of questions to ask:

• How is this piece of code used? or How do I instantiate this thing? Claude Code doesn't just do a text search: it often goes a level deeper and looks for real-world examples of how a class is instantiated and used, giving you a deeper answer — the kind of answer you'd get from a wiki or documentation, not just a Ctrl+F.
• Git history questions. For example: why does this function have 15 arguments and why do they have such strange names? Claude Code scrolls through the Git history to understand how those topics were introduced, by whom, in what situation, and to which issues the commits were related, and then summarizes everything for you. You don't have to explain it to him in detail: just tell him to look in the Git history and he'll know what to do. We didn't instruct him in the system prompt: he can do it because the model is excellent.
• Questions about GitHub issues. With the tool WebFetch can retrieve issues and bring their context into chat.
• A ritual that Boris repeats every Monday at the weekly standup: asks “what did I release this week?” Claude Code looks at the log, knows his username, and returns a neat summary of everything he’s sent, ready to copy into a document.

The advice, then: whether you're showing Claude Code to someone for the first time or onboarding your team, don't start with sophisticated tools or modify code. Start with code Q&A: it teaches you how to write good prompts and helps you understand the boundary between what Claude Code can do on its own and what requires more supervision—what can be solved in one shot, what in two or three, what requires interactive mode in a REPL.

The next step: modify the code

Once you're comfortable with the Q&A, you can move on to the code modification. The strength of an agentic use of an LLM is that you give him tools and he figures out how to combine them on his own.

Claude Code works with a deliberately small tool setOne to edit files, one to run bash commands, and one to search through files. It sequences them to explore the code, brainstorm, and then make changes. You don't have to tell it "use this tool, then that one": you tell it what to do, and it figures out how to chain them together properly.

A very strong piece of advice: Before you write code, ask Claude to think. A common mistake is to immediately ask him to implement a huge 3,000-line feature. Sometimes he gets it right the first time, but sometimes he builds something completely different from what you wanted. The easiest way to get it right is to ask him to think first: brainstorm ideas, prepare a floor, submit it to me and ask me for confirmation before writing code. No special methods or tools are needed: just ask.

Another recurring formula is the incantation “commit, push, PR”. There's nothing magical about it, but Claude is smart enough to figure it out: he creates the commit, creates a branch, pushes it, and opens a pull request on GitHub. You don't have to explain anything to them: look at the code, the history, and the Git log to figure out the commit format and everything else yourself. Again, this isn't system prompting: they know how to do it because the model is good at it.

Connect your team's tools

As you progress, you'll want to connect your team's tools—this is where Claude Code really starts to shine. There are essentially two types of tools.

1. Bash Tools (CLI). In the talk example there is a hypothetical barley CLI. You can tell Claude Code to use that CLI to do something, and for example, run --help to understand how it works. If you find yourself using it often, you can include it in your CLAUDE.md This is how Claude remembers it between sessions. It's a common pattern both at Anthropic and among external clients.

2. MCP Tools. Claude Code can use both bash tools and MCPYou tell him about the tool, add it to him, explain how to use it, and he starts using it. This is extremely powerful: when you start working on a new codebase, you can give him all the tools your team already uses for that codebase, and Claude Code uses them on your behalf.

The most common workflows

There are some recurring patterns. We've already seen the first one: explore a little, plan a little, ask me before you write code.

The other two are very powerful and are based on the idea of giving Claude a way to check your work. When Claude has control over what he produces — writing unit tests, doing screenshot with Puppeteer, or by taking screenshots from the iOS simulator — can iterate alone. If you give him a mockup and ask him to build a web UI, he'll do it pretty well; but if you let him iterate two or three times, he'll often arrive at a near-perfect result.

The trick, then, is to give him a tool with which to get feedback and check his work: give them a way to see their result And he'll get better with every iteration. Whatever your domain—unit tests, integration tests, app screenshots, or web—the same principle applies. In short: teach Claude how to use your tools and figure out the right workflow, so you know how to set the prompt.

Give Claude more context: the CLAUDE.md file

In addition to the tools, you want to give Claude more contextThe more context he has, the better his decisions will be. As an engineer working in a codebase, you have a huge amount of context in your head—the history of the systems, the decisions made, the files that matter. There are several ways to convey this to Claude.

The simplest is CLAUDE.md, a special file name. The most immediate place to put it is the root of the project (the same folder you launch Claude from): it will be automatically read in context at the beginning of each session, effectively included in the first round. There is also a CLAUDE.md local, which is not normally put under version control:

• The CLAUDE.md project it's a good idea to version it and share it with the team, so you write it once and everyone benefits from it;
• The CLAUDE.md local it remains only for you.

What to put there: Common bash commands, frequent MCP tools, architectural decisions, important files — anything you typically need to know to work in that codebase. Keep it pretty short though.: if it gets too long it consumes context and is rarely useful. All other CLAUDE.md you can put them in nested subfoldersClaude calls them on demand, loading them automatically when working in those directories. And if you're a company and want a shared CLAUDE.md across all your codebases, you can put it in the enterprise root.

All the ways to bring context

CLAUDE.md is just one option. Boris himself admits he struggled to put together the slideshow due to the multitude of options available:

• CLAUDE.md — loaded automatically.
• Slash command — custom commands in .claude/commands, both in your home directory and versioned in the project. In Claude Code's repository, for example, automatic issue labeling is exactly one of these flows: a GitHub Action executes a slash command and labels them for humans.
• Files mentioned with @ —you can reference them to bring them into context.
• CLAUDE.md nested — automatically included when Claude works in the relevant directory.

It's worth taking the time to refine the context. You can run it through a "prompt improver" and ask yourself: who is this context for? Should it be included every time or only upon request? Should it be shared with the team or is it a personal preference? Done well, this dramatically improves performance.

The configuration hierarchy: project, global, enterprise

Going deeper, it is worth thinking about a hierarchy configuration — not just for CLAUDE.md, but for pretty much everything Claude-related:

• Project — specific to your Git repository; you can version it or keep it private.
• Global —configurations valid for all your projects.
• Enterprise policies — essentially a global configuration that you distribute to all employees, automatically.

This logic applies to many things. To slash command. To the permits: if there is a bash command that all your employees use (a test command), you can put it in the enterprise policies file and it gets self-approved; the same file is used for block commands or URLs that should never be fetched. Ai MCP server: put a file mcp.json versioned into the codebase, and anyone who runs Claude Code in that repository will be invited to install the MCP servers, sharing them with the team.

If you don't know which level to use, the advice is: start from the shared project context. You write it once and share it with everyone, creating a network effect where one person's work benefits the entire team. To manage all this, Claude Code has integrated tools: /memory shows all the memory files that are loaded and allows you to edit them; the button # Instead, it helps you remember something: you type it, write down what to remember, and choose where to save it.

Keyboard shortcuts you may not know

Building for the terminal is hard but fun—it's like rediscovering a design language built on extreme minimalism, but where certain shortcuts are hard to find. Here's a quick reminder:

• Shift+Tab — accept the changes and switch to mode auto-accept editsBash commands still require approval, but file changes are automatically accepted. This is useful when you know Claude is on the right track or you're iterating on unit tests.
• # — remind Claude of something (e.g. the correct use of a tool): it is automatically integrated into CLAUDE.md.
• ! —go to bash mode and run a command locally; the output still ends up in the context window, so Claude will see it on his next turn.
• @ —mention files and folders to bring them into context.
• Esc —Stop Claude at any time, safely: it doesn't corrupt the session. If 19 out of 20 lines of a change are perfect and one needs changing, press Esc, tell him, and ask him to redo that change.
• Esc Esc (twice) — go back in history.
• claude --resume / claude --continue — once the session is over, resume the previous session.
• Ctrl+R — displays the full output, the same one Claude sees in his context window.

The Claude Code SDK

If you used the flag -p in Claude Code, you have already used the’SDK (headless/programmatic mode). In the weeks leading up to the talk, several features have been added to make it even better, and it is the exact same SDK which uses Claude Code inside - you can build on it.

An example of command line usage: with claude -p you pass the prompt; you can pass the allowed tools, possibly including specific bash commands; you can choose the output format, JSON or JSON streaming if you want to elaborate on it as you go. It's great for building on top of: in Anthropic it's used in THERE, for the incident response and in all kinds of pipelines.

The right way to think about it is as a Unix utilities: you give it a prompt, it returns JSON, and you use it however you want — you pipe in and out. You can pass git status in pipe and use jq To select the result; you can read a huge log from a GCP bucket, pipe it, and ask Claude to find what's interesting. The combinations are endless: it's a kind of Super-intelligent Unix utility, and we're only just beginning to understand how to exploit it.

Working in parallel: advanced uses

More advanced use cases include parallelism. Boris calls himself a “normie” user: he usually runs only one Claude session at a time, with at most a few terminal tabs for different repositories.

True power users, inside and outside Anthropic, almost always do this: they have sessions SSH, tunnel Tmux towards their sessions Claude, and more checkout of the same repository to run many Claudes in parallel. Alternatively, they use the Git worktree to have isolation while they work. Anthropic is working to make this easier, but you can already run as many sessions as you want: a lot of work can be done in parallel.

Questions from the audience

What was the most difficult part to implement? One of the most delicate is what is needed to make bash commands safe. Bash is inherently dangerous and can change the system state in unexpected ways; but manually approving every single command would be frustrating. The solution: Some commands are read-only, so you do a little static analysis to understand which commands can be safely combined, and there is a tiered permission system which allows for allow-lists and block-lists at different levels.

Is Claude Code multimodal? Yes, it is fully multimodal from the beginning. Being in a terminal it is a bit difficult to find out, but you can drag and drop an image, indicate a file path, or copy and paste The image. Boris often uses it when he has a mockup of something: he drags in the mock, asks for it to be deployed, gives it a server to iterate on, and the rest is automatic.

Why a command line tool and not an IDE? Two reasons. First: it was born at Anthropic, where people use a very wide range of IDEs, so the terminal is the lowest common denominator. Second, at Anthropic, we see firsthand how quickly models improve, and we want to prepare for a future where IDEs may no longer be as useful as they are today, by avoiding overinvesting in additional UI layers.

How much do you use Claude Code for machine learning? Quite a lot. At Anthropic, both engineers and researchers use it every day: about the 80% of technical people uses it daily, including researchers, who exploit tools such as the notebook tool to edit and run notebooks.

Bottom line: start simple, then scale.

The underlying logic of the entire guide is the same: Claude Code doesn't impose a workflow, it lets you choose it. Start with code questions, add file editing, connect your team's tools, provide context with CLAUDE.md, and then, when needed, scale to SDKs and parallel sessions. The common thread between every trick is giving Claude the right tools and a way to verify himself. The real accelerator is not the model, but how you learn to work with it.

And this is where, for companies, the method makes the difference: adopting these tools is only worthwhile if people learn to use them well. If you want to understand how to incorporate them into your team's daily work, our AI and automation consulting It starts exactly from here.