What using Claude Code actually looks like

Using Claude Code is a loop, not a prompt. You say what you want in plain English, it changes something, you check the change, and you decide what happens next.

Most explanations skip that loop. They give you the install command and one clever example, then leave you at a blinking cursor. Here is what a normal hour looks like, including what to do when Claude changes the wrong file.

I built this site with it. Early on I asked it to clean up the footer, and it read that as "remove the unnecessary parts". My links, social icons and copyright notice went with them. Nothing there was a bug. I gave a vague instruction to something that edits real files, and it did what I asked.

What it is, in one paragraph #

Claude Code is Claude working inside a folder on your computer. It can read your files, edit them, run commands, and tell you what it did. You talk to it in a terminal window, in normal sentences, and it does the typing. There's no code to write to get started, which is why people with no development background can use it at all. Chapter 1 covers what that actually means if the idea is new to you.

The consequence that matters: it changes real files. In default mode it asks before changing them. You still need to understand what you're approving, which is why so much of this guide is about checking and recovering.

Getting it running #

Two steps, and the first one is the real hurdle for most people.

You open a terminal. On a Mac that's the Terminal app, on Windows it's PowerShell or Windows Terminal. If you've never used one, it's a window where you type commands instead of clicking. That's the whole concept. Opening the terminal walks through it slowly.

Then you install Claude Code and sign in. The install chapter has the current commands for Mac, Windows, and Linux.

One thing worth deciding before you start: which folder you point it at. Claude Code works inside the folder you open it in, so a new empty folder for your first project keeps the blast radius small.

Your first session #

Start it in your project folder, then type what you want. Plain English. No special syntax.

The mistake I see beginners make is being too vague. "Fix the header" is a reasonable thing to say to a colleague who can see your screen, and a bad thing to say to something that has fifty files and no eyes. Name the file and name the visible problem:

In pages/contact.html, fix the header spacing. The heading is
too close to the navigation bar.

That one habit makes the first week much less frustrating. Giving better instructions is the chapter on it, and your first conversation walks through a full session from the first line.

You'll also be asked to approve things. By default Claude Code reads on its own and stops before it edits or runs anything. That gets tiring after an hour, and approving on reflex is how people end up where I did with the footer. Pick a permission mode on purpose. Shift+Tab

cycles the common ones, and manual mode is the right place to stay while you're learning.

The commands that matter #

There are many. These are the six I use most:

I discovered /plan

late and now use it constantly. When a task touches several files, asking for the approach first catches a wrong direction while it's still free to change. (I reach for it on anything that will touch more than two files, which by now is most of what I do.)

Working on something real #

The pattern I trust on an actual project is boring, and boring is the point. Break the thing into steps small enough to check, then do one at a time.

"Add a blog to my site" is a project. A task is "create a blog listing page that shows post titles and dates, in the same style as the rest of the site". You review that, then ask for the next piece. If something goes wrong you know which step did it, and you lose one step instead of a day.

As the project grows, two habits start to matter. Write your project's rules into a CLAUDE.md

file so you're not repeating them every session. And plan before you build anything structural. The CLAUDE.md chapter covers the first part.

Module 4 takes this from an empty folder to a live site.

When it goes wrong #

It will. Plan the time for it.

The recovery order is worth knowing before you need it. Run /diff

and test the behaviour you asked for. The summary tells you where to look. Only the diff tells you what happened. If the change is wrong, press Esc

twice or use /rewind

and go back to the prompt before the mistake. Checkpoints keep snapshots for the 100 most recent points in a session and are cleaned up with the session after 30 days. They only cover Claude's direct file edits, not changes made through shell commands, subagents, databases, or deployments. For older file history, you need Git.

The failure that costs real time is quieter than a deleted footer. You ask for a fix, it doesn't work, you ask again, it still doesn't work, and five speculative changes later nobody can tell which one broke what. One change, one check. When a fix fails twice in a row, restore the last good state and start again with what you learned by then. When things go wrong is the full chapter, and staying safe covers permissions, secrets, and the recovery layers.

What this will not do #

It won't read your mind about a project it has never seen, which is what the CLAUDE.md

file is for. It won't stop you approving something you didn't read. And it doesn't remove the need to test, because a change that looks right in a diff can still be wrong in a browser.

Where to go from here #

If you've never opened a terminal, start at chapter 1 and go in order. If you're already installed and want the habits that make it stick, jump to the fundamentals module. If your project is bigger than a handful of files, working on bigger projects is where the one-task-per-session rule starts to pay off.

The loop does not change: ask, check, decide. With practice, you can let it do more before checking.