You open Claude Code for the first time and you see... an empty line you can type something into. No buttons, no wizard, no "click here" hint. And that's exactly what puts the most people off — because if the tool can do anything, where do you even begin?
I'll show you how I approach it: from the simplest move that breaks nothing, all the way to the habits used by people who get a great deal out of this tool. In order: questions about the project, editing code, planning, the feedback loop, context, and finally working in several sessions at once.
First, understand what it is
Claude Code is a completely different kind of assistant from the ones you may have known. Earlier programming helpers suggested the next line or two — like autocomplete in a search box. That's not what this is. Claude Code is agentic, meaning it acts on its own: it's given a goal and picks the steps to reach it itself. It can write a whole function, a whole file, fix a whole bug — not a single line.
The second important thing: it lives in the terminal. The terminal is that black window where you type commands as text instead of clicking. It sounds old-fashioned, but that's actually its strength — it works everywhere. Whatever you have on screen as your code editor (programmers call it an IDE — the environment where you write and run a program), Claude Code works with it without changing your habits. You don't have to switch to a new tool or rebuild the way you work. You simply add it to what you already have.
And that's exactly why an empty line greets you. It isn't unfinished — it's a deliberate choice. The tool is versatile enough that it doesn't want to push you into one prefab way of working. It gives you a free hand. It's just that a free hand requires knowing what to do with it — and that's what the rest of this text is about.
Start here: ask questions about your project
This is my one piece of advice I put above all the rest: before you change anything, ask questions first. Don't edit code, don't reach for advanced tricks. Just ask about your own project.
This is a common mistake I see — people throw a huge task at the tool right away and end up disappointed. The best road to fluency runs through conversation. You ask: "how is this piece of code used?", "why does this work the way it does?", "what did I actually ship this week?". Claude Code doesn't answer with a plain word search through the text. It goes deeper — it looks for real usage examples, pieces them together, and gives you an answer at the level of good documentation rather than a list of hits.
The project's history is a great thing to ask about too. Programmers keep code in a Git repository — something like a journal that remembers every change: who changed what, and when. You can simply say "go through the history and explain where this odd function came from" — and the tool digs through that journal itself, finds the moment something was added, and summarizes the whole story for you. You don't have to explain how to do it. It knows, because the model it runs on is genuinely good — no one told it to "dig through the Git history," it just can.
Two things worth stressing here, because they're reassuring. First: nothing is sent anywhere. The code doesn't land on any server, it stays on your computer. Second: there's no setup and no indexing — you don't wait for the tool to "digest" the project. You download, run, ask. And it's these questions that teach you the boundary: what the tool does on the spot, and what requires you to lead it by the hand.
Editing: you describe the goal, not the steps
Once you feel confident with questions, you can move on to changing code. And here the same logic applies.
Claude Code has a very small toolset at its disposal: it can edit files, run commands (bash is simply the language you issue commands to the computer in, in the terminal), and search the project. That's all. The magic is that it combines these tools in the right order itself. You say what should be built — and it decides to search first, then read, then change. You don't tell it "use this now, then that." You describe the goal, not the steps.
Planning: the highest-payoff habit
If I'm to name one habit that gives the most for the least effort, it's this: on every nontrivial task, ask for a plan before the tool starts writing.
I see someone toss out a command like "build me this huge three-thousand-line function," and sometimes it even works the first time. But sometimes something comes out completely different from what you wanted — and that's where the frustration starts. The simplest fix: have it think first. It's enough to write something like "think through the ideas, draw up a plan, show it to me, and wait for my approval before you write any code."
You don't need any special mode or settings for this. You simply ask — and the tool knows what to do. Five minutes to approve a plan saves an hour of fixing something that went the wrong way.
The big idea: give it a way to check its own work
This is, in my view, the most important thing in this whole text. If you remember only one sentence, let it be this: when the tool has a way to check its own work, it brings that work to a far better state on its own.
Imagine you give it a sketch of a page's interface and say "build this." The first time, it'll come out decent. But if you give it a way to see the result — a screenshot of the finished page, say, or a set of automatic checks (programmers call them tests — small checks that tell you whether something works as intended) — then the tool compares the result against the goal, fixes it on its own, checks again, and after two or three passes lands almost perfectly.
This is the feedback loop. The trick is always the same, regardless of domain: give it any way to see the result of its work, and it'll fine-tune itself. A screenshot, a test, a preview — anything that lets it judge for itself whether it did well.
Give it context, and it gets smarter
The more the tool knows about your project, the better the decisions it makes. You carry a great deal of context in your head — the history, the decisions, the knowledge of "why we do it this way here and not another." It can't guess that. You have to give it to the tool — and there are a few ways to do so, starting with the simplest.
The CLAUDE.md file. This is a short notes file the tool reads automatically at the start of every conversation. You write into it what you'd want to pass on to someone new on the project: the most common commands, a few key files, important decisions. One rule: keep it short. If it grows too much, it starts taking up room and stops helping. You can share the file with the team — then you write it once and everyone benefits — or keep a private, local version just for yourself.
Saved commands (slash commands). If you repeat some action every week, you can save it as a ready-made command — they're called slash commands because you invoke them with the slash character /. You save it once, use it with a single command. These can be shared with the team too.
Connecting the tools you already use. If your team has its own programs run from the terminal, or a system called MCP (the shared standard that lets Claude Code talk to external tools — your ticketing system, a database, whatever), you just tell it about them and show it how to use them. From then on it'll use them on your behalf. Say you have an in-house program at the company run by a terminal command — you tell the tool "use it, check its manual yourself" and it manages. This is very convenient when you start on a new project: you hand it the team's whole toolset at once.
Company-level settings. At a larger scale, you can spread context and rules across layers: separately for the project (saved in the repository and shared), separately globally for all your projects, and separately at the level of the whole company. That topmost layer is a powerful security tool: safe commands can be approved up front so no one has to click them every time, and dangerous ones blocked so that no one can get around them.
If you don't know where to start in this whole thicket of possibilities, start with shared project context. You write it once, share it with the whole team — and a network effect kicks in: one person does a bit of work, and everyone benefits.
A few handy moves and parallel work
Finally, a handful of small things that make everyday use easier:
- Auto-accept mode for changes — when you can see the tool is on the right track (fixing tests in a loop, say), you can stop approving each change individually. Terminal commands still need your approval, and everything can always be undone.
- The
#character to remember something — if the tool doesn't do something the way you want, you type#and say what's wrong. It'll remember it for the future by adding it to its notes. - Escape to stop safely — at any moment you can press Escape and halt what the tool is doing. Nothing breaks, the session isn't harmed. You interrupt, say what to change, and carry on.
- Resuming a session — when you're done, you can come back to the same conversation later and continue, instead of starting from scratch.
As for truly advanced use — the people who get the most out of this run several sessions at once. They have many separate copies of the same project or use Git "worktrees" (a way to keep several parallel versions side by side) so each session works in isolation. This lets you do many things at the same time. I usually run a single one myself — it's not a requirement, more a direction you can take once you feel comfortable.
It's also worth knowing that Claude Code can be driven not only by hand but from scripts — like a smart command-line tool that's given a task and returns a result. You give it a command, it hands back a finished result, and you wire that into a larger automated workflow. You don't have to touch this at the start — but it's good to know the path exists.
What to take away from this
This whole progression comes down to one rule: don't hunt for secret incantations — give the tool context and a way to check its own work. The rest is the model doing what it's good at.
The smallest move for today: open your project and ask one question about something you never quite understood. That's enough to begin.