ailiteracynepal 🇳🇵
Text size

Chapter 01 · Section IV · 12 min read

The core edit-review loop

One turn of Claude Code is: you ask, it proposes a tool call, you approve, it does the thing, it summarises, you review. Internalising that loop is the single biggest determinant of whether the tool feels magical or infuriating.

There is a rhythm to working with Claude Code. Once you feel it, everything else falls into place. Miss it, and you spend your day fighting the tool. This section gives the rhythm a name.

The four beats

Every non-trivial turn looks the same:

  1. You ask. In plain English, you describe the outcome you want.
  2. Claude proposes. It picks a tool — Read, Edit, Bash, whatever — and shows you the exact call it wants to make: the file, the diff, the command.
  3. You decide. If it looks right, you approve. If it does not, you deny and correct — either by pushing back in words (“no, edit the other function”) or by narrowing the ask.
  4. You verify. After the action, Claude summarises what it did. You do not take the summary on faith. You read the diff, run the test, glance at the log — the work is the ground truth, not the paragraph describing it.

That loop, over and over, is the job.

Why the loop matters

Each beat is a check against a specific failure mode:

  • Ask fights the impulse to type “just make it good” and hope. Precise asks get precise work.
  • Propose exposes what Claude thinks you meant, before it does anything irreversible. This is where you catch it about to edit the wrong file.
  • Decide is where you say no. Denying is not rude; it is the tool’s designed check.
  • Verify is where you catch summaries that overstate. The most common failure mode of any coding assistant is a confident description of work that did not actually happen the way it claims.

When you can loosen the loop

Not every action needs a human in it. For low-stakes, easily-reversed operations — creating a new file in a scratch directory, running a read-only command, reading a file — you can set your permission mode to auto-approve and skip step 3. That is fine. What you do not skip is step 4, verification, when the work matters.

The safety chapter goes deeper on which knobs are safe to loosen and which are not.

When Claude gets stuck

Occasionally you will hit a loop where Claude proposes something, you deny with a correction, and it proposes the same thing again. This usually means:

  • You have not given it enough context to know what “right” is (fix by pasting the relevant file or spec).
  • The task is bigger than one turn (fix by breaking it down).
  • The ask is genuinely ambiguous (fix by picking a direction).

Denying five times in a row is a signal to stop and re-scope, not to keep denying.

Check your understanding

Quick check

You approve Claude's proposed edit and it says 'Done — I renamed the function and updated all call sites.' What is the right next move?