Your first task: the agent loop

What you’ll be able to do

Give Claude Code a small but real change, follow what it’s doing at each step, pick the right permission mode for the situation, and undo anything with a checkpoint, without being afraid of breaking your project.

Why this lesson matters

Most frustration with AI coding tools comes from one of two habits. Some people approve everything without looking, and then can’t explain the changes they’ve accepted. Others interrupt constantly because they don’t trust what’s happening. Both come from not seeing what the agent is doing.

Claude Code is transparent by design: every file it reads, every command it runs and every edit it makes appears in your terminal as it happens. Once you know how to read that stream, and when to step in, you can hand over larger tasks with confidence. This lesson builds that skill on a small, safe example.

The agent loop

Every task, from a one-line fix to a multi-file feature, runs through the same loop:

1. Gather context. Claude reads files, searches the codebase and checks git history to understand the problem before changing anything.
2. Act. It edits files and runs commands.
3. Verify. It runs tests, a build or a linter, and reads the output.
4. Repeat until the task is done, then summarise what changed.

Step 3 is what separates an agent from autocomplete. Without a way to check its work, Claude can only produce code that looks right. With tests or a build to run, it sees failures and fixes them itself, often several times, before handing the result back to you.

In the terminal, the loop looks roughly like this (exact formatting varies between versions):

> Add a slugify helper with tests and make them pass

● Read(package.json)
● Write(slugify.js)
● Write(slugify.test.js)
● Bash(npm test)
  ⎿  ✖ accents are removed: expected "creme-brulee", got "crme-brle"
● Update(slugify.js)
● Bash(npm test)
  ⎿  ✔ 6 tests passed

Created slugify.js with a slugify(text) helper and 6 tests…

Notice the failed test followed by a fix. That’s the loop working as intended, not something going wrong.

Permission modes: who approves each action

Before Claude edits a file or runs a command, Claude Code decides whether to ask you first. The permission mode controls that. Press Shift+Tab to cycle through the modes; the status line at the bottom shows the current one.

Mode	Status line	What runs without asking	Use it when
Manual	⏸ manual mode on	Reading files and a few harmless read-only commands (such as ls or git status). Every edit and every other command asks you	Learning, or working in code you don’t want touched without review
Accept edits	⏵⏵ accept edits on	Reads, file edits and basic file commands in your project	You trust the direction and will review the diff at the end
Plan	⏸ plan mode on	Read-only exploration; Claude proposes a plan for you to approve	Bigger or riskier changes (lesson 2.3)
Auto	⏵⏵ auto mode on	Most actions. A classifier reviews each one in the background and blocks risky ones	Everyday work once you’re comfortable

Auto mode is the default for new interactive sessions in current versions. Reading files and editing inside your project run straight away. Other actions, such as shell commands and network requests, go to a separate classifier model first, which blocks anything that goes beyond what you asked for or looks dangerous: force-pushing, piping a downloaded script into a shell (curl … | bash), git reset --hard on work you didn’t ask to discard, deploying to production, or sending sensitive data to unknown servers. If it blocks several actions in a row, Claude Code goes back to asking you. Auto mode is fast and safe for daily work, but it hides most of the loop’s decisions from you. That’s why this lesson starts in Manual mode.

Set up a practice repo

Use a throwaway project so you can experiment without worrying about your real code. The exercises use Node.js (version 22 or later). Check with node --version, and if it isn’t installed, get the LTS version from nodejs.org.

mkdir loop-practice && cd loop-practice
git init
npm init -y
claude

Then press Shift+Tab until the status line shows ⏸ manual mode on.

Exercise: build a small feature with tests

Paste this prompt:

Create a small plain-JavaScript Node module `slugify.js` exporting slugify(text):
lowercase, trim, replace any run of non-alphanumerics with a single "-", strip
leading/trailing "-". Add tests using node:test in slugify.test.js covering at
least 5 cases including unicode accents ("Crème Brûlée" -> "creme-brulee").
Add an npm "test" script and run the tests until they pass.

Notice what makes this a good prompt: it states the behaviour precisely, names the files, gives a tricky example (“Crème Brûlée”), and says how to verify (“run the tests until they pass”). Lesson 2.1 covers this in depth.

What you’ll see, step by step

1. A short plan. Claude often starts by saying what it’s going to do. Read it. If it misunderstood something, this is the cheapest moment to correct it.
2. File creation prompts. For each new file, you’ll see its full contents and options to approve or decline. Skim the code. You don’t need to understand every line yet, but check that it matches what you asked for.
3. A command prompt for npm test. The choices include approving once (Yes), “Yes, and don’t ask again”, and No, which declines and lets you tell Claude what to do instead. Some prompts also offer to switch to auto mode. Choose “Yes, and don’t ask again”. Claude Code saves this as a permission rule, so it won’t ask about npm test again in this project.
4. Self-correction. The accented example often fails at first, because a naive implementation deletes “è” instead of turning it into “e”. Watch Claude read the failure, adjust the code (typically by normalising the text before removing symbols) and re-run the tests. This is the loop doing its job.
5. A summary of what was created and the final test result.

Now try the same thing in auto mode

Press Shift+Tab until you see ⏵⏵ auto mode on, then ask:

Add a maxLength option that truncates on a word boundary, with tests.

You’ll get few or no prompts this time: edits inside your project run straight away, and the classifier judges running the project’s own tests as safe. Compare the two experiences. In Manual mode you saw and approved every decision. In auto mode you’ll review the result at the end instead. Both are valid; experienced users switch between them depending on how much they trust the task.

Steering: the controls you’ll use daily

You’re never just a spectator. These controls let you redirect Claude at any point:

Action	How	When to use it
Interrupt the current step	Esc	Claude is heading the wrong way. Stop it, then explain what you want instead
Open the rewind menu	Esc Esc on an empty prompt, or /rewind	You want to go back to before a prompt (see checkpoints below)
New line without sending	Shift+Enter, or Ctrl+J in any terminal	Writing a multi-line prompt
Run a shell command yourself	Start with !, e.g. !npm test	Checking something quickly. Claude sees the output and responds to it
Point Claude at a file	Type @ and pick the file	Saving Claude the search, and being explicit about scope
See every detail	Ctrl+O	Understanding exactly what a step did

Try interrupting now: while Claude is working on something, press Esc, then type “Also handle empty strings by returning an empty string.” Claude continues with your correction added, and nothing is lost.

Checkpoints: undo without fear

Claude Code automatically saves a checkpoint of your files before every prompt you send. To go back:

1. Press Esc twice on an empty prompt (or run /rewind).
2. Pick the prompt you want to return to.
3. Choose what to restore:
   • Restore code and conversation: go back completely, as if the later prompts never happened.
   • Restore code: undo the file changes but keep the conversation, so Claude still remembers what you discussed.
   • Restore conversation: keep the files as they are, but rewind the chat.
   • Summarize from here / up to here: compress part of the conversation to free up context (lesson 1.3).

Try it: ask Claude to “rename slugify to toSlug in both files, using your file editing tool rather than a shell command”. Check that the files changed, then rewind to before that prompt and choose Restore code. The rename disappears.

Why the wording “rather than a shell command”? Claude sometimes does bulk renames with a shell command such as sed, and rewind can’t restore changes made that way. That’s the limitation in the caution box below.

Reviewing the result

Before you consider a task finished, check it yourself:

!git status
!git diff
!npm test

Or run /diff to review every change in your working tree at once. You’re looking for three things: changes you didn’t ask for, code you don’t understand, and tests that don’t actually test the behaviour you care about. If you find any, tell Claude. It can explain or fix them.

Common mistakes

• Approving without reading. Skim every diff, at least at the start. You’re responsible for what you commit, not Claude.
• Staying in Manual mode forever. Once you trust the loop for routine work, auto mode saves a lot of time. Review the result instead of every step.
• Not giving Claude a way to verify. “Write a function” produces code that looks right. “Write a function and tests, and run them until they pass” produces code that is right.
• Waiting to correct a wrong direction. Press Esc as soon as something looks off.
• Relying on rewind instead of git. Rewind is for quick, in-session undo, and it can’t restore changes made by shell commands. Commit working states so you can always get back to them.

Verify it worked

• slugify.js and slugify.test.js exist, and npm test passes, including the accent case
• You worked in Manual mode, then in auto mode, and can describe the difference
• You interrupted Claude at least once with Esc and redirected it
• You restored code from a checkpoint with the rewind menu
• You reviewed the final diff before considering the task done

Next: working across a longer session: slash commands, resuming work, and managing context.