Getting started with Claude Code

TL;DR

It’s not magic. Claude Code is an LLM. It generates code based on the code that’s already there and on what you tell it. It doesn’t understand the story; you have to. Read the story, understand what you’re building, and judge every line it writes.

Start slow. Ignore the people online who claim to make thousands of commits a month with five agents at once. Work on one story at a time, and keep reviewing your code against the requirements yourself, for now. My main concern at this point is keeping the quality up.

Claude Code generates code, and it can help you think. But you have to understand what you’re building, and you’re responsible for what gets merged. Work in small slices you can demo, review and commit each one yourself, and keep the setup vanilla.

How it works

An agent, not a chat

In the chat on claude.ai, you paste code in, Claude guesses at the rest of your project, and you copy the answer back.

Claude Code is an agent: it runs on your machine, in your repository, and acts as you. It works with whatever it finds on your PC, through a shell (bash), the same way you would in a terminal. It can:

• read, search and edit any file
• run mvn, npm, git, docker, or any script in the repository
• start a local server, call it with curl, read the logs, and kill the process afterwards
• read the output of a failing test, change the code, and run the test again

Because it works in your repository, it works from your actual code instead of a guess, so it picks up your conventions, good and bad. And because it can run commands, it can check its own work, as long as you give it something to check with: a build, tests, a linter.

It acts as you

It runs with your permissions and your logins: your git credentials, your SSH keys, your kubectl context. Whatever you can do from a terminal, it can do too. So it can also commit, push, and delete branches. Be careful what you wish for: “clean up the old branches” means exactly that.

Conversations and context

Claude forgets everything by default. You work with it in conversations, and every new conversation starts empty: nothing from the previous one carries over. When you start one, Claude Code loads a few things into it, so Claude knows something about your project before you type anything: its own instructions, your CLAUDE.md, its memory, and the descriptions of your skills. Everything else, it finds itself, by searching and reading your code.

Everything in a conversation (what was loaded at the start, your messages, the files it read, the output of its commands) is its context. It’s measured in tokens, pieces of words. The longer a conversation gets, the worse Claude gets at paying attention to it, and the faster you use up your subscription, which allows only so many tokens every five hours and every week.

My take

• Understand what you’re building. Use it to think along: ask it for ideas, alternatives, and what you missed. But you decide, and you understand what gets built. Generating code you haven’t thought about is doing it wrong. When it goes to review, it’s your code. If you can’t explain a line, don’t commit it.
• Don’t start from what people post online. You’ll read about people who claim to make thousands of commits a month and run five agents at once. Don’t start there. Work slowly, one story at a time, and get a feel for how it works: what it does well, where it goes wrong, and what that costs. Stay in the loop: with five stories running at once, you don’t understand any of them.
• Check old advice before you follow it. Things move fast, and a lot of what you heard a year ago is no longer true. It used to make up functions and libraries all the time; now it reads your code and runs the build, so that’s rare. “Act as an experienced database administrator” doesn’t make it better at databases: it’s a pattern matcher with an internal brain. It already knows what a database administrator knows, and it matches on your code and your question, so put the effort there. “Keep a Markdown task list and tick off each ticket as you go” isn’t needed either: it keeps track of its own steps.
• Work in slices you can demo, and commit them yourself. Ask for one small change that works end to end, then stop. “Implement the story” in one go gives you a 40-file diff nobody can review. Review and commit each slice yourself, so a bad slice costs one revert.
• Pick the model for the task. Use Opus 5.5 on medium effort to implement a full story from scratch, and on high effort for complex refactors across the whole code base. Use Sonnet for simple tasks, like a rename or a change to a single page. /model switches both.
• Start a new conversation for every task. A fresh conversation is cheaper and sharper, and nothing from the previous task leaks into it.
• Leave it in auto mode. It’s the default: a second model reviews each command before it runs, and blocks the risky ones, like curl | bash or sending data outside your project. Approving every edit and command yourself trains you to click yes without reading. Review the diff before you commit instead.
• Keep it vanilla. Plugins, MCP servers, skill packs, custom agents: each one takes up context and changes behavior in ways that are hard to trace. Only add something when you feel a concrete pain.

Gotchas

• Plausible isn’t right. It writes code that compiles and looks reasonable, fast. That makes it easy to skim the diff and miss that it solves a slightly different problem.

Example

A first session on a small task:

1. Install Claude Code and log in, following the official setup guide.
2. Run claude in the root of the repository.
3. “Add X. Work in slices I can demo, and stop after each slice so I can review and commit.”
4. Read the diff and try it. Commit it, or tell Claude what’s wrong.
5. Ask for the next slice.

Later

Once that feels normal, in this order:

• From story to code with Claude Code: a workflow for a new story.
• Keeping Claude Code on track: what to do when it does something weird.
• Codebase-wide analysis and prototypes: using it for more than writing features.
• Tokens, context and usage limits: what a conversation costs, and why.
• How Claude Code remembers: the notes it keeps when you correct it.
• CLAUDE.md, skills and MCP servers: what to give Claude besides your code, and why it should be very little.
• T3 Code: an app to use instead of the terminal.