Skip to content

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

3 min read

Claude Code Beginner
On this page
Time
About 20 minutes
Cost
Paid subscription or per-use billing
Level
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.

Common questions

Do I need to be a developer?

It helps, but the useful floor is lower than people expect. If you can describe what is wrong and read a proposed change critically, you can get value from it.

Will it break my project?

It can. That is why every step here happens inside Git: a bad change becomes one command to undo rather than an evening of repair.

What is the difference from using Claude in a browser?

The browser version talks. This version reads and edits the real files, and runs commands to check whether the change worked.

What to do next

Related reading

Last reviewed 1 September 2026 by Nick.

Software changes fast. If something here is out of date, tell me and I'll fix it.

Get new guides by email

Occasional and practical. No spam, no hype, unsubscribe whenever.

Sign-ups are not open yet. The form is a placeholder for now.