.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Claude Code is Anthropic's AI coding agent that lives in your terminal: you describe what you want in plain language and it reads your codebase, edits files and runs commands to get there. The difference from a chat window is the loop it runs on its own, gathering context, acting, then verifying the result before it reports back. That loop is what makes it feel less like autocomplete and more like handing a task to a colleague who happens to type at machine speed.
This guide walks one real task end to end: a Node.js repo with a failing test, from the first question to the commit that fixes it. Every command here ran on my machine before it went into the article. If the CLI isn't on your system yet, installing Claude Code on Ubuntu takes about a minute and Anthropic's quickstart covers the other platforms.
Start Claude Code in your repository
Claude Code operates on the current directory, so start it where the code is:
cd ~/projects/shop-api
claudeThe first launch signs you in through the browser with your Claude account (any paid plan works, or a Console API key on pay-as-you-go). After that you're at a prompt inside your repo. Nothing has been read yet; context gets pulled in as you ask for things, which keeps sessions cheap until you make them expensive.
Ask questions about the codebase
Before changing anything, I use the first few minutes of any session as a guided tour. Plain questions work:
> how does this repo calculate cart totals, and where are the tests for it?Claude searches the project, reads the relevant files and answers with concrete file and function references, something like "totals are computed in src/cart.js in calculateTotal(), tested in test/cart.test.js". Reading and searching don't need your approval, so exploration flows freely. This is also the cheapest way to onboard onto an unfamiliar codebase I've found; asking "what would break if I renamed this field?" beats an hour of grepping.
Fix a failing test with Claude Code
Now the actual job. Our example repo has a test that fails on floating-point rounding: a cart of three items at 19.99 comes out as 59.97000000000001. Hand the whole problem over rather than pre-chewing it:
> npm test is failing on the cart totals test. find the cause and fix itWatch the loop happen. Claude asks to run npm test (the first permission prompt you'll see), reads the failure output, opens the test and the implementation, then proposes an edit to calculateTotal() that rounds at the money boundary. The edit shows up as a diff for you to approve. After you accept, it reruns the test on its own to confirm green. That verify step is the habit worth noticing: you didn't ask it to rerun the tests, it does that because an unverified fix isn't a fix.
When the suggested change is wrong, say so in plain words ("don't round inside the loop, round the final total") and it revises. Treat it like code review in fast-forward.
How permission prompts work
By default, Claude Code asks before it edits a file or runs a command, and each prompt offers to allow that action for the rest of the session. Pro, Max and Team accounts in the terminal and VS Code now default to an auto mode instead, where a classifier waves through clearly safe actions and only interrupts you for the risky ones. You can cycle modes any time with Shift+Tab, and there's an acceptEdits mode when you trust file changes but still want a say on commands.
For bigger or riskier tasks, I start read-only: claude --permission-mode plan makes Claude research and propose an approach without touching anything until you approve the plan. It changes the quality of large refactors enough that I've written about Claude Code plan mode separately.
Set up CLAUDE.md with /init
Once a project is worth returning to, run /init. It analyzes the repo and generates a starter CLAUDE.md holding your build commands, test instructions and conventions, and it folds in existing Cursor or Copilot rules files if it finds them. That file loads at the start of every future session, which is why the second session in a project always feels smarter than the first. What belongs in it (and what wastes context tokens) is a topic of its own, covered in the guide to CLAUDE.md configuration.
Commit the fix through Claude Code
Git is just another set of commands Claude can run, so the commit works conversationally:
> commit the cart fix with a sensible message, don't touch the other modified filesIt stages the relevant files, writes a message describing the change and shows you the git commands before running them. Pull requests work the same way when the GitHub CLI is installed and authenticated: "open a PR for this branch" produces a description summarizing the diff. I still read every commit before pushing. Old habit, and it has caught the occasional staged file I didn't want in there.
Switch models and watch your usage
Two slash commands cover the practical daily controls.
Pick a model with /model
/model lists what your account can use, with aliases like sonnet, opus, haiku and fable; Sonnet is the default on API accounts. Pressing Enter saves your choice as the default while s applies it to the current session only. My split: Sonnet for the everyday loop, the heavier models for gnarly debugging or architecture work, Haiku when the task is mechanical. There's also an opusplan alias that plans with Opus and executes with Sonnet, a nice compromise documented in the model configuration docs.
Track tokens with /usage
/usage shows where the session's tokens went, and /context visualizes what's occupying the context window right now. Subscription plans meter Claude Code against a rolling 5-hour window plus a weekly limit, shared with your claude.ai and desktop usage, so a heavy agent day draws from the same pool as your chats. How the limits behave in practice, and what to do when you hit them, is in the Claude Code cost and usage limits guide.
Resume a session with claude --continue
Sessions persist on disk per project. claude --continue reopens the most recent one in the current directory with full history, and claude --resume gives you a picker when you juggle several threads in one repo. Yesterday's context, restored in a second, is one of those features you stop noticing until you use a tool without it. Session storage, forking and exports have enough depth for their own piece on Claude Code sessions.
CLI, IDE, desktop or web: Which surface to use
The same agent runs in five places, and after months of switching between them my picks are settled. The CLI is home base; everything works there and it's the only surface that scripts. The VS Code extension (JetBrains has a plugin too) is what I switch to when a change spans many files, because reviewing diffs in an editor beats reviewing them in a terminal. The desktop app is the answer for people who don't want a terminal at all.
Then there's Claude Code on the web, which is a different animal: cloud sessions at claude.ai/code that run on Anthropic-managed VMs against a GitHub repo and come back to you as branches and pull requests. You can launch one from the terminal with claude --cloud "fix the flaky checkout test", list running ones with /tasks and pull one down into your local terminal with /teleport when it needs hands-on attention. I use the web for parallel background chores (dependency bumps, test cleanups across repos) and the CLI whenever I expect to iterate. Local wins any time the feedback loop matters.
That's the whole beginner arc: question, fix, verify, commit. Once it feels routine, the habits that separate productive daily use from expensive flailing are collected in Claude Code best practices. The next capability jump comes from giving the agent more tools than your shell provides, which is exactly what MCP server configuration unlocks.
