# How a turn works

Course: Claude Code from Zero — https://zero2vibecode.com/learn/claude-code
Canonical URL: https://zero2vibecode.com/learn/claude-code/0-4-plan-edit-review-loop

Every piece of work with an agent is the same four beats: you ask, it plans, it edits, you review. Learning where you sit in that loop is most of the job.

Whatever you are building, a turn has the same four beats.

## 1. You ask

One request, in plain English, about one thing.

> Add a Clear button under the todo list that empties it.

Specific beats clever. You do not need magic words, a persona, or a template. You need to say what you want in a sentence you would be comfortable saying to a colleague.

The most common beginner mistake is asking for five things at once. Then when something is wrong you cannot tell which of the five caused it.

## 2. It plans

Before touching anything, a good turn starts with the agent saying what it intends to do: which files it will open, what it will change, what it thinks the tricky part is.

You can ask for this explicitly — *tell me the plan first, do not change anything yet* — and Claude Code also has a plan mode where exploring and proposing happen but edits are held back until you approve. Level 1 covers it properly.

Read the plan for one thing above all: **did it understand the request?** If the plan is aimed at the wrong file, you have just saved yourself twenty minutes for the price of reading four lines.

## 3. It edits

Now it changes files. Depending on how you have set things up, it will either ask before each action or apply edits as it goes — Claude Code has modes for both, and level 3 is where you choose deliberately.

It may also run commands: your tests, a build, a script. It reads the output and reacts to it. That is not a gimmick; an agent that can run the test suite can catch its own mistakes before you ever see them.

## 4. You review

The agent shows you what changed as a diff: the lines it removed and the lines it added.

Read it. Every time. Three questions, in order:

1. **Is this what I asked for?** Not "is it good code" — is it the thing.
2. **Did it change anything I did not ask about?** Extra "improvements" are how surprises get in.
3. **Does it run?** Start the thing, click the button, run the tests.

**The honest failure mode.** 
It will sometimes call a function that does not exist, import a library you do not have, or use an option that was never in that API. It will do this in fluent, confident, well-formatted code. The only reliable detector is running it — reading alone catches maybe half.

## Then you go around again

*Almost. The button clears the list but the counter still shows the old number.*

That sentence is a whole turn. Short, specific, one problem. Three or four of these and the feature is done — and you understood every step, because you were in the loop for each one.

**When the loop stops working.** 
If you have gone around three times on the same problem and it is not converging, stop. Do not go round a fourth. Level 2 has a whole lesson on why starting over beats correcting five times, and it is one of the most useful habits in this course.

<Faq>
  
  
</Faq>

## Try it yourself

One full turn, all four beats. The last one is the easiest to skip and the most expensive to skip.