Claude Code is Anthropic’s coding assistant that runs in your terminal, and I’ve been reading a transcript of a talk its creator, Boris Cherny, gave about how to use it. The talk mentions the GitHub app being announced “today”, which puts it at around May 2025, so it’s well over a year old now. Claude Code moves fast, so I wanted to know two things: which of his tips are actually any good, and which of his claims are true.
I checked what I could against the version I’m running now (2.1.281, on 6 October 2026) and sorted everything he said into three piles:
- Accurate and useful – correct, and worth doing
- Accurate but not much use – true, but trivia, a bit of marketing, or out of date in practice
- Not accurate, or misleading – wrong, overstated, or no longer true
Worth remembering that he built it and works for the company that sells it, so this is the official view. Nothing wrong with that, but it’s why I checked.
Accurate and useful
It’s not line completion
He opened by saying earlier coding assistants mostly finish a line or a few lines at a time, whereas Claude Code is “fully agentic”. You ask for a feature, a whole function, a whole file or a whole bug fix and it goes off and does it. Because it lives in a terminal it works alongside whatever editor you use, over SSH, inside tmux, wherever. That’s right, and it’s the main reason I can run it on a server with no desktop at all.
The setup commands
His first-run list was /terminal-setup (gives you Shift+Enter for a new line, so no more backslashes), /theme (light, dark or colour-blind friendly), /install-github-app (so you can mention Claude on any issue or pull request) and customising the allowed tools list so it stops asking about the same safe commands every time. All real, and the allowed tools one is the one that saves you most faff.
He also dictates his prompts using the Mac dictation shortcut, because specific prompts get better results and talking is quicker than typing them. I don’t have a Mac so I can’t tell you about that bit, but the principle is sound – a long, specific prompt beats a short vague one every time.
Start with questions about the codebase
His number one tip, and the best one in the talk. Before you let it edit anything, just ask it questions about your code. “How is this class created?” “Where is this function used?” It doesn’t do a text search and give up, it goes and finds real examples. Anthropic apparently does this with new starters on day one.
The other benefit he mentioned is that it teaches you how to prompt it. You learn what it gets right first time, what needs a second go, and what you need to hold its hand on, before it can do any damage.
No indexing, no setup
There’s no index of your code to build, so you install it, start it and it works. It explores on demand using search tools. That’s how it works, and it’s why it’s useful on a folder you’ve only just cloned.
Git history and GitHub issues
Ask it “why does this function have 15 arguments?” and it will go through the git history, find the commits that added them and follow any linked issues. He does the same with GitHub issues, and every Monday before the team stand-up he asks “what did I ship this week?”. It reads the log, knows his username and gives him a list he pastes into a doc. Steal that one!
Make it plan first
If you ask for a huge feature in one go, it sometimes gets it spot on and sometimes builds something nothing like what you wanted. His fix is to say “before you write any code, make a plan and check it with me”. No special mode needed, you just ask. (There is a plan mode too, if you’d rather use that.)
“Commit, push, PR”
He types something like that and it makes a branch if it needs one, commits in the style of the repository (it reads the git log to work that out), pushes, and opens the pull request. Works well. His explanation for why it works is only half right though, see the last section.
Your own command line tools and MCP
Tell it a command line tool exists and tell it to use --help to learn it. If you keep using the tool, put a note about it in your CLAUDE.md so it remembers next session. MCP servers work the same way: add the server, tell it how to use it. His advice for a new codebase was to give it every tool your team already uses.
Let it check its own work
The most useful idea in the whole talk, I think. If Claude Code can see the result of what it did, it can iterate on its own. Unit tests, screenshots through Puppeteer, the iOS simulator. His example was giving it a mock of a web page and asking for the UI. First go it’s “pretty good”, after 2 or 3 loops it’s often “almost perfect”. Whatever you work on, find a way for it to see the result.
CLAUDE.md
A file called CLAUDE.md in the folder you start Claude Code in gets read into the context at the start of every session. Check it into source control and the whole team shares it. A personal one that you don’t check in is for your own preferences, and nested ones in sub-folders get pulled in when it works in those folders. Companies can have an enterprise one for everybody. What goes in it: common commands, MCP tools, architecture decisions, key files, style guide. His one big warning is to keep it short, because a long one eats context and stops being useful.
I have a global one on my server that it reads every session. Two of my rules in there are that it has no sudo, so anything needing root has to be handed to me as a command to run myself, and that it must back up a database table before any UPDATE or DELETE. It’s 99 lines, which Boris would probably say is too long!
Slash commands, @-mentions and tuning your context
Custom slash commands are just files in a .claude/commands folder, either in your home directory or in the project. His example was the Claude Code repository itself, where a slash command run by a GitHub Action labels new issues so humans don’t have to. You can also @-mention files to pull them in. He said it’s worth taking time to tune your context (even running it through a prompt improver) and to think about who it’s for: always loaded or on demand, shared or just you.
Settings at different levels
Settings work in layers: the project (shared or just you), global across all your projects, and enterprise policy for a whole company. That covers slash commands, permissions and MCP servers. A company can auto-approve a command for everyone (the test command, say), or block one, or block a URL, and nobody can override it. An .mcp.json file checked into the repository means anyone opening the project is offered the shared MCP servers. His advice if you don’t know where to start was shared project context. Write it once, everyone benefits.
His example was the Anthropic apps repository, which has a Puppeteer MCP server checked in so every engineer can run end-to-end tests and screenshots without installing anything.
/memory
Type /memory and you can see every memory file being loaded (enterprise, user, project, nested) and edit them.
Key bindings
- Shift+Tab switches to auto-accept edits. Bash commands still need your OK, and you can ask it to undo things later. He uses it when it’s on the right track or iterating on tests.
- ! at the start drops you into bash mode. The command runs locally and the output goes into the context, so Claude sees it on the next turn. Good for long-running commands.
- Escape stops it at any time and he says it never corrupts the session. So if it suggests a 20 line edit and 19 are perfect, hit Escape and tell it about the one. (Handy to know, because it’s tempting to wait for it to finish.)
- Escape twice jumps back through the history.
claude --resumeandclaude --continuepick up an earlier session. Both are in the help of my version.
Using it from scripts with -p
The -p flag (print) runs it non-interactively. You give it a prompt, a list of allowed tools and an output format (plain, JSON or streaming JSON), and Anthropic uses it in their CI, for incident response and in pipelines. He calls it a “super intelligent Unix utility”, and you can pipe into it. I tried it with a 4 line file:
cat words.txt | claude -p "How many lines are in this input? Answer with just the number." --output-format jsonIt took about 6 seconds, and the result field in the JSON it printed was 4. The same JSON also had the session ID and the cost (about $0.14 for that one tiny question, mostly because of the context it loads each time). So it works, but it isn’t free.
Running several at once
He calls himself a “Claude normie” with one session at a time, but says power users run lots in parallel, using tmux or SSH sessions with several checkouts of the same repository, or git worktrees to keep them separate. Worktrees are the tidiest way and there’s now a --worktree (-w) option in the help that creates one for you.
How it keeps bash safe
Asked what the hardest part of building it was, he said making bash commands safe without you having to approve every single one. Some commands are known to be read-only, there’s static analysis to work out which can be safely combined, and there’s a tiered permission system so you can allow-list and block-list at different levels. It explains why some commands just run and others stop and ask.
Images
It’s multimodal. Drag an image into the terminal, give it a file path, or paste it in. He often drops in a design mock, asks it to build it and gives it a Puppeteer server so it can screenshot the result and keep going.
Notebooks
Researchers at Anthropic use it for machine learning work, including a notebook tool that edits and runs Jupyter notebooks. That’s real, and handy if you work in notebooks.
Accurate but not much use
The install bit
He asked who had used it, then told newcomers to install it (it needed Node.js) so they could follow along. True then, but the install route has moved on and the npm one isn’t the main one any more, so check the current instructions rather than copying a command off a slide.
“It’s a power tool” and no set workflow
He said you get a prompt bar and nothing else because Anthropic doesn’t want to push you towards one way of working. Fair enough as a design idea, but not a lot of help if you’ve just opened it for the first time. Which is why the rest of the talk exists, I suppose.
“The model is awesome”
More than once he said it knows how to use git because “the model is awesome” and the team are lucky to build on such a good model. The ability is real, the line is a bit of a plug.
“A small set of tools”
He said it only has a few tools: edit files, run bash and search files, and it strings them together. In spirit that’s right, and it’s a good way to build an agent. In practice there are more (reading, writing, web fetching, task lists, sub-agents), but you don’t need a list of them to use it.
Everyone has a 15 argument function
Fair, but it’s a joke to set up the git history tip.
Terminals are hard to build for
He said building for a terminal is hard but fun, “like rediscovering a new design language”, and that key bindings are hard to discover because it’s so minimal. True, and it’s why he put the key bindings slide in. Not a tip as such.
The “insane matrix” of settings
He admitted the settings slide is “information dense” and that it’s a lot because every company works differently. Honest, and I appreciated that. The useful bit is the advice to start with shared project context.
Shortcuts and names that have changed
A few things he said were true at the time but have since moved, so check them in your version before relying on them:
- Ctrl+R for the full output – this has changed in later versions (I believe it’s Ctrl+O now, but check
/help). - The # shortcut to tell Claude to remember something and write it into CLAUDE.md. I wouldn’t count on it in newer versions. These days you can just ask it to update CLAUDE.md, or use
/memory. - “The Claude Code SDK” has since been renamed and widened (it’s the Claude Agent SDK now), and
-pis often called headless mode. - The GitHub app being announced “today” is of historical interest only.
Not accurate, or misleading
“There’s nothing in the system prompt about git”
He said twice that Claude Code knows how to read git history, copy your commit style and make pull requests because the model is good, and that “we’re not system prompting it to do this”. That isn’t right. The instructions that come with Claude Code’s bash tool have a long, detailed section on committing and on creating pull requests: check the status, the diff and the recent log first, match the repository’s commit message style, never force push, never skip hooks, use gh for the pull request, and so on. The model is clever, but a good chunk of that behaviour is written down for it. It doesn’t change how useful the “commit, push, PR” tip is, but “it just knows” overstates it.
“Your code stays local”
He said that because there’s no indexing there’s no remote database of your code, “we don’t upload it anywhere”, “your code stays local” and “we do not train generative models on the code”. The first bit is true, there’s no permanent index. But Claude Code sends the contents of the files it reads, your prompts and the output of commands to the model over the API, otherwise it couldn’t answer anything. So your code does leave your machine as part of using it.
On training, Anthropic’s business terms (API, Team, Enterprise) say customer content isn’t used for training by default. The consumer plans (Free, Pro, Max) have different terms, which changed after this talk and depend on a setting. So don’t rely on one line from a talk. Read the current privacy policy for the plan you’re on, especially before you point it at client code or anything confidential.
“People won’t be using IDEs by the end of the year”
Asked why a CLI rather than an IDE, he gave two reasons. The first was that people at Anthropic use all sorts of editors (VS Code, Zed, Xcode, Vim, Emacs), so the terminal is the common denominator. That one’s fair. The second was that models are improving so quickly that “there’s a good chance that by the end of the year, people aren’t using IDEs anymore”, so they didn’t want to put effort into a UI. That didn’t happen, and it’s October 2026 as I write this. IDEs are still everywhere, and Anthropic has since made extensions for VS Code and JetBrains, plus desktop and web versions, so it’s a forecast that was too bold rather than a fact.
“Works with every single IDE”
Overstated. It works next to any editor because it runs in a terminal, and there are official VS Code and JetBrains integrations. But there’s no first-party Xcode integration that I know of, so for Xcode you just run it in a terminal alongside. “Every IDE” really means “anything with a terminal next to it”.
Onboarding “from 2 or 3 weeks to 2 or 3 days”
Not verified. It’s Anthropic’s own figure, given without any data. Plausible, because asking questions about a codebase really does speed things up, but I’d treat the exact numbers as marketing until you’ve measured it on your own team.
“About 80% of technical staff use it every day”
Also not verified. Another internal figure I can’t check. It tells you they use their own product, which is nice to know, but it doesn’t tell you whether it will suit you.
The superlatives
“Incredible”, “extremely powerful”, tuning context “will improve performance dramatically”. The advice behind them is sound (see the first section) but there were no benchmarks, so it’s opinion. Try it on your own work.
“You can run as many sessions as you want”
Only with a big caveat. There’s no hard limit in the tool, but your plan’s usage limits (or your API bill) still apply, and lots of sessions at once will use them up quickly.
Posted 13 October 2026. Checked against Claude Code 2.1.281 on 6 October 2026. Shortcuts change quickly, so if something here doesn’t match what you see, check /help in your own version.