Claude Code for beginners
A practical guide to using Claude Code for real work: what it does, your first useful task, and the habits that stop it making a mess of your project.
By Nick
On this page
Real screenshot or sketch goes here
IT READS YOUR ACTUAL FILES.
- About 20 minutes
- Paid subscription or per-use billing
- Beginner
1. What makes it different
A chat assistant can only describe a change. You then have to find the file, make the edit and run the thing. Claude Code does that part itself: it reads your files, proposes edits, and runs commands to see whether they worked.
That makes it much faster, and much easier to make a mess with. Both are true at once.
2. Before you start: use Git
This is not optional advice.
cd my-project
git init
git add -A
git commit -m "Before Claude Code"
Now every change is reversible. If something goes wrong, git checkout . undoes it in a
second. Without this, an assistant with file access is genuinely risky.
3. Your first task
Start it in your project folder:
cd my-project
claude
Then pick something small and verifiable. Good first tasks:
- “Explain what this project does, based on the files.”
- “Why does the build fail? Read the error and tell me.”
- “Add a comment at the top of each file saying what it is for.”
Bad first tasks: “refactor this”, “make it better”, “add authentication”. Vague goals produce large, confident, hard-to-review changes.
4. Read what it proposes
Every edit is shown before it is applied. Read it. Do not skim. Read it.
Most of the time it is right. The times it is wrong, it is wrong plausibly: a change that looks reasonable, compiles fine, and does something subtly different from what you asked. The only defence is reading, and committing often enough that undoing is cheap.
5. Give it the error, not your guess
The most useful thing you can do is paste the actual error message rather than your
interpretation of it. “It says TypeError: cannot read property id of undefined on line 40”
gets a better result than “something is broken with the user thing”.
It can also run the command itself and read the output, which is usually better still.
6. Habits worth forming
- One task at a time. Small changes are reviewable; large ones are not.
- Commit after each success. Then a bad next step costs nothing.
- Say when you disagree. “That is not what I meant, the issue is X” works, and works better than starting over.
- Stop when it loops. If it tries the same fix three times, the problem is the framing. Back up and describe the goal differently.
7. When not to use it
When you are learning. If the point is to understand how something works, having it done for you defeats the exercise. Use a chat window and ask for explanations instead.
And when the change is genuinely one line. Opening a tool to fix a typo is slower than fixing the typo.