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.

An install command and one clever example do not show that loop. 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

This article covers the terminal version of Claude Code: 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 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. How often it asks first depends on the permission mode, your settings and where you run it. You still need to understand what the tool is doing, which is why so much of this guide is about checking and recovering.

Getting it running

Two steps. Opening the terminal is the unfamiliar one if you've never used it before.

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 uses the folder you open as its working directory, so a new empty folder narrows what is in scope. It is not a security sandbox.

Your first session

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

The easy mistake at the start 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 gives Claude Code less room to guess. Giving better instructions is the chapter on it, and your first conversation walks through a full session from the first line.

You'll also need to choose how much Claude Code can do without asking. Shift+Tab cycles the common permission modes in the terminal. Start in Manual mode while you're learning, because reviewing each edit and command shows you what the tool is doing. Looser modes are useful later, but approving on reflex defeats the point.

The commands that matter

There are many. These are the six worth learning first:

Use /plan before a task touches several files. Asking for the approach first catches a wrong direction while it's still free to change.

Working on something real

The safe pattern 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.