The first hour with Claude Code

Two failure modes bracket a first session. Either you ask for something vague, get something mediocre, and conclude the tool is overrated. Or you ask for something it happens to be excellent at, get a working result, and conclude it can be trusted with anything.

An hour spent deliberately avoids both.

Start in a repository you know well

Familiar code, so you can judge the output. A scratch project teaches you nothing, because you have no opinion about whether the result is good.

Do not start on the thing you most need done. Start on something you could do yourself in twenty minutes, so you have a benchmark.

Ask it to explain before asking it to change

The first useful task is a question, not an edit:

Explain how request authentication works in this codebase. Point me at the files.

You learn several things at once: whether it can find its way around the repository, whether its explanation matches what you know, and what it does when it is unsure. That last one carries the most information and it is the one people skip past.

Then a small, checkable change

Something with an obvious right answer. A bug you have already diagnosed, a test you know is missing, a rename with a clear boundary.

Watch what it does before it edits. Anthropic's own research describes the working split as people making most of the planning decisions and Claude making most of the execution decisions. A first session is where you learn whether you are comfortable with that division, and where you find that handing over the planning too is where things go wrong.

Read the diff yourself

Every time, but especially now. You are calibrating: does it change what it said it would change, does it touch anything else, does the style match the surrounding code.

Files you did not expect to change, that changed, are the finding. See Reviewing agent-written code.

Notice what the session cost

Open Settings → Usage before and after. An hour of agentic work consumes noticeably more than an hour of chat, because the loop reads a great deal and re-sends it every turn. Better to meet that number now than on a Thursday afternoon with a deadline.

What to set up before the second session

A short list, and it comes from the first hour rather than from a guide.

A CLAUDE.md with the build command, the test command, and any convention you found yourself explaining. If you explained it once you will explain it every session until you write it down. See A CLAUDE.md that gets followed.

A permissions posture. Decide what it may run without asking. Doing this deliberately beats approving prompts reflexively for a week and then wondering what you agreed to. See Permissions: allow, gate, deny.

If this is a codebase you do not know yet, the first hour has a different shape — interrogate before you change.

What goes wrong

Starting with the hardest thing you have. No benchmark, high stakes, and you learn nothing transferable.

Skipping the explain step. It is the cheapest way to find out whether it understands the repository before you let it change one.

Accepting a diff you have not read because the tests passed. The tests pass because the code passes the tests.

Judging the tool from one session. One session tells you about one task. The useful judgement comes from noticing which kinds of task go well.

Leaving the permission prompts on default and clicking through. That is a decision, made badly, by accumulation.

How to check it worked

At the end of the hour you should be able to name one kind of task you would hand it unsupervised, and one you would not. If both answers are "not sure", run one more task at each end of the range rather than reading more about it.