Practical Claude Code Tips and Tricks

Boris Cherny: Hello everyone. I'm Boris, I'm a member of technical staff here at Anthropic and I created Claude Code. I'm here to talk to you about some practical tips and tricks for using Claude Code. It's going to be very practical. I'm not going to go too much into the history or the theory. Before we start -- can we get a quick show of hands, who has used Claude Code before? All right, that's what we like to see. For everyone that didn't raise your hand, if you can open your laptop and install Claude Code now, you'll need Node.js.

Boris Cherny: So what is Claude Code? Claude Code is a new kind of AI assistant. Most AI coding assistants have been about completing a line at a time, a few lines at a time. Claude Code is not for that. It's fully agentic -- it's meant for building features, writing entire functions, entire files, fixing entire bugs at the same time. And it works with all your tools. You don't have to change your workflow. Whatever IDE you use -- VS Code, Xcode, JetBrains, Vim, Emacs -- Claude Code works with every IDE and every terminal. It will work locally, over remote SSH, over tmux, whatever environment you're in.

Boris Cherny: It's general purpose, and because it can do so much, we don't try to guide you towards a particular workflow -- you should be able to use it however you want as an engineer. When you open Claude Code for the first time, there are a few things we recommend. Run terminal setup -- this gives you Shift+Enter for new lines. Do slash theme to set light or dark mode. You can do slash install GitHub app, which we announced today, where you can mention Claude on any GitHub issue or PR. You can customize the set of allowed tools so you're not prompted every time. And something I actually do: for many of my prompts, I use macOS dictation -- hit the dictation key twice and just speak your prompt. It helps a lot.

Boris Cherny: So when you're starting out, it's so freeform and it can do everything -- where do you begin? The thing I recommend above everything else is starting with codebase Q&A. Just asking questions to your codebase. This is something we teach new hires at Anthropic. On the first day of technical onboarding, you run Claude Code and you immediately start asking questions about the codebase. In the past, technical onboarding used to tax the team a lot -- you had to ask other engineers questions, look around the code, figure out tools. It took two or three weeks. With Claude Code, it's now about two or three days. Claude Code explores the codebase and answers these questions without any indexing, no remote database, no uploading of your code. Your code stays local. We do not train generative models on the code.

Boris Cherny: There's no setup -- you download it, start it, and use it right away. Some example questions: how is this particular piece of code used? How do I instantiate this thing? Claude Code won't just do a text search -- it goes a level deeper, finds examples of usage, and gives you a much richer answer. Something I also do a lot is ask it about git history. For example: why does this function have 15 arguments and why are they named this weird way? Claude Code looks through git history, figures out how those arguments got introduced, who introduced them, what issues those commits linked to, and summarizes it all. You don't have to tell it to look at git history -- it just knows. The model is good. I also ask about GitHub issues -- it can web-fetch issues and build up context.

Boris Cherny: Something I do every single Monday in our weekly standup: I ask "what did I ship this week?" Claude Code looks through the git log, knows my username, and gives me a nice readout of everything I shipped. I just copy and paste that into the docs. Tip number one: for people who haven't used Claude Code before, start with codebase Q&A. Don't start by using fancy tools. Don't start by editing code. Just ask questions. It'll teach you how to prompt and calibrate what Claude Code can handle -- what can be one-shotted, what needs interactive back-and-forth.

Boris Cherny: Once you're comfortable with Q&A, you can move into editing code. The cool thing about using an LLM in an agentic way is you give it tools and it figures out how to use them. Claude Code has a pretty small set: a tool to edit files, a tool to run bash commands, a tool to search files. It strings these together to explore, brainstorm, and then make edits -- and you don't have to tell it which tool to use when. Something I like to do sometimes is ask Claude to brainstorm or make a plan before jumping in to write code. I see people give Claude Code an enormous 3,000-line feature request and sometimes it gets it right, but sometimes the result is not what you wanted at all. The easiest fix: ask it to think first. Brainstorm ideas, make a plan, run it by me, ask for approval before writing code. You don't need plan mode or special tools -- just ask Claude and it'll do this.

Boris Cherny: Another incantation I use a lot: "think about this, commit and push." Claude will make a commit, push it to a branch, make a branch, and make a PR on GitHub for me. You don't have to explain anything -- it looks through the code, the git log, figures out the commit format, and does it correctly. We're not system-prompting it to do this, it just knows. As you get more advanced, you want to start plugging in your team's tools. There are two kinds: bash tools -- you can tell Claude about a CLI and point it to --help -- and MCP tools. Just tell Claude about the tools and it'll start using them. When you start on a new codebase, give Claude all the tools your team already uses for that codebase, and Claude Code can use them on your behalf.

Boris Cherny: There are a few common workflows. One is exploration, planning, then asking for confirmation before writing code. The others are more advanced: when Claude has a way to check its work -- by writing unit tests, or screenshotting with Puppeteer, or screenshotting the iOS simulator -- it can iterate. If you give it a mockup and say "build this web UI," it'll get pretty close, and if it iterates two or three times, it often gets it almost perfect. The trick is to give it a feedback tool. Whatever your domain is -- unit tests, integration tests, screenshots -- just give it a way to see its result and it'll iterate and get better.

Boris Cherny: As you go deeper, you want to start giving Claude more context. The more context, the smarter the decisions. The simplest way is CLAUDE.md -- a special filename you put in the project root. It gets automatically read into context at the start of every session. You should check it into source control and share it with your team. There's also a local CLAUDE.md you don't check in -- just for you. The kinds of things to put in: common bash commands, common MCP tools, architectural decisions, important files, anything you'd typically need to know to work in this codebase. Keep it short -- too long just wastes context. In our codebase we have common bash commands, the style guide, a few core files -- things like that. You can put CLAUDE.md files in nested child directories too, and those get pulled in on demand when Claude works in those directories.

Boris Cherny: There are many ways to pull in context. CLAUDE.md is pulled in automatically. You can also use slash commands -- these live in .claude/commands in your home directory or checked into your project. We use slash commands in the Claude Code repo itself -- for example, there's one that labels GitHub issues automatically. A GitHub Action runs it, Claude Code runs the command, and it labels the issues so humans don't have to. You can also mention files to pull them into context, and nested CLAUDE.mds get pulled in for their directories.

Boris Cherny: Context tuning is definitely worth taking the time to do. Consider who the context is for, when it should appear, whether it's shared with the team or personal. Doing this well will dramatically improve performance. As you get more advanced, think about this hierarchy: project configs (checked in or personal), global configs across all projects, and enterprise policies -- a global config you roll out to all employees automatically. This applies to slash commands, permissions, and MCP servers. For example, if all employees use a specific test command, you can add it to enterprise policy config and it gets auto-approved for everyone. You can also use it to block commands -- if a URL should never be fetched, add it to config and employees cannot override it.

Boris Cherny: If you're not sure where to start, start with shared project context. Write it once, share it with the team, get the network effect. Someone does a little bit of work and everyone benefits. Tools like slash memory let you see all the memory files being pulled in at any time. When you type the pound sign to remember something, you can pick which memory file it goes into. That's the next step: take the time to configure CLAUDE.md, MCP servers, and all the tools your team uses -- configure once, share with everyone.

Boris Cherny: An example from our apps repo at Anthropic: we have a Puppeteer MCP server with an MCP JSON file checked in. Any engineer working in the repo can use Puppeteer to pilot UI, run tests, and screenshot automatically -- no individual install required. Now, a quick reference on key bindings, because it's very hard to discover these in a terminal. Shift+Tab accepts edits and switches to auto-accept mode -- bash commands still need approval, but file edits are auto-accepted. You can always ask for confirmation later. Use the pound sign to remember something -- Claude will incorporate it into CLAUDE.md automatically. Hit the exclamation mark to run a batch command locally -- it goes into the context window and Claude sees it on the next turn. You can mention files and folders at any time. Hit Escape to stop Claude at any point -- it won't drop the session or mess anything up. Hit Escape twice to jump back in history.

Boris Cherny: After you're done with a session, you can start Claude Code with --resume to resume that session, or --continue. Hit Control+R anytime to see the full output -- the entire context window, the same thing Claude sees. The next thing I want to talk about is the Claude Code SDK. Using the --print flag is the SDK. We've been shipping a bunch of features over the last few weeks to make it even better. You can build on top of this -- it's exactly what Claude Code itself uses internally. Pass it a prompt, pass some allowed tools including specific bash commands, tell it the output format you want -- JSON or streaming JSON. We use this in CI all the time, in incident response, in all sorts of pipelines. Think of it as a super-intelligent Unix utility. Give it a prompt, get JSON, pipe it anywhere. Pipe git status in, use JQ to select the result. Read from a GCP bucket, pipe a giant log in and have Claude figure out what's interesting. Fetch from the Sentry CLI. The combinations are endless.

Boris Cherny: The final topic is the most advanced use cases. I usually have one Claude session running at a time. When I look at power users inside and outside Anthropic, almost always they are running multiple SSH sessions with tmux tunnels into their Claude sessions. They have multiple checkouts of the same repo to run multiple Claude instances in parallel, or they use git worktrees for isolation. We're working on making this easier. You can run as many sessions as you want, and there's a lot you can get done in parallel. That's it -- I wanted to leave time for Q&A.

Audience: What was the hardest part of building Claude Code?

Boris Cherny: I think there are a lot of tricky parts. One that is especially tricky is making bash commands safe. Bash is inherently pretty dangerous and can change system state in unexpected ways. But if you have to manually approve every single bash command, you're annoying as an engineer and can't be productive. Navigating how to do this safely across the different kinds of codebases people have -- not everyone runs their code in a Docker container -- was pretty tricky. We landed on: some commands are read-only, we do static analysis to figure out which commands can be combined safely, and we have a complex tiered permission system so you can allow or block commands at different levels.

Audience: You mentioned giving an image to Claude Code -- is there multimodal functionality?

Boris Cherny: Yes, Claude Code is fully multimodal -- it has been from the start. It's in a terminal so it's a little hard to discover, but you can drag and drop an image in, give it a file path, or copy and paste the image in. I use this pretty often -- if I have a mockup, I'll drag and drop it in, tell Claude to implement it, give it a dev server to iterate against, and it's fully automated.

Audience: Why did you build a CLI tool instead of an IDE?

Boris Cherny: Two reasons. First, at Anthropic, people use a broad range of IDEs -- VS Code, Zed, Xcode, Vim, Emacs -- and it was hard to build something that works for everyone. The terminal is the common denominator. Second, at Anthropic we see up close how fast the model is getting better. There's a good chance that by the end of the year people aren't using IDEs anymore. We want to get ready for this future and avoid over-investing in UI layers on top, because the way models are progressing, those layers may not be useful work pretty soon.

Audience: How much do you use Claude Code for machine learning and modeling?

Boris Cherny: A lot. Both engineers and researchers at Anthropic use Claude Code every day. About 80% of technical people at Anthropic use it daily. This includes researchers who use tools like the notebook tool to edit and run Jupyter notebooks.