Chapter 4 · Craft · 7 min read

Iteration and control

The first prompt is never the last prompt. The value in Claude Code isn't the output — it's the loop that gets you to the right output in three or four rounds instead of one frustrated rewrite.

Over time the goal shifts. Early on you read every diff, watch every change, stay in control. Later you build a harness around the agent so the work becomes verifiable without your eyes on every line. This chapter is both halves — the daily iteration habits, and the posture that makes them scale.

Rewind

Double-tap Esc in the Claude window. You're back one message. File changes are rolled back. The conversation branches. Same effect as /rewind, just faster.

This is the single most useful keyboard shortcut in the whole tool. Use it whenever:

• Claude went down the wrong path and you want to retry the prompt
• You spotted a better way to phrase the ask mid-thought
• You want to branch an experiment without committing to it
• The diff surprised you and you'd rather not have it

Rewind is cheap. Re-prompting from scratch is expensive.

Narrow the scope

The fastest way to bad output is a prompt that asks for too much at once.

Wide:

Refactor this file to use dependency injection, add tests, and migrate it to TypeScript strict mode.

Narrow, three prompts:

Refactor this file to use dependency injection. Don't touch tests or types yet.

Now add tests for the refactored interface.

Now enable strict mode and fix what breaks.

Three narrow prompts land three times faster than one wide one. Each one gets a clean review.

"That's not quite right"

When Claude does something close but off, resist the urge to rewrite from scratch. Describe the gap:

The helper function is fine, but move it into utils/time.ts — we keep time-related helpers there.

Claude will move it. The structure holds. You didn't have to re-explain the whole task.

Managing context — /clear vs /compact

Context windows are large but not infinite. Two commands, different tools:

• /compact [focus] — same conversation, Claude summarises the history so far and throws the raw turns away. Use when you're mid-task and need breathing room.
• /clear — new conversation, old one archived (resumable via /resume). Use when you've pivoted to a different area of the codebase, or the conversation has 30+ turns and is drifting.

A clean conversation with good CLAUDE.md is almost always faster than a long one.

Pro move for the Compound Engineering loop (chapter 6): clear between phases. /clear before /plan means the brainstorming turns don't muddy the plan. /clear before /work means the plan debate doesn't colour the implementation. Each phase gets sharp context; /compound at the end has clean material to summarise.

The shift: from control to a harness you trust

Early in agentic work, the advice is simple: read every diff, review every change, don't trust the agent. That's the control reflex. It builds the skill.

As you work with Claude Code daily, that posture becomes the bottleneck. You can't read fifty diffs an hour. You can't simultaneously hold the plan + the diff + the codebase in your head. The longer you sit in control mode, the less the agent can actually accelerate you.

The better path: build a harness around Claude Code that makes its work verifiable without your eyes on every line. Your role shifts from reviewer to harness architect.

What the harness looks like in practice: testing discipline (tracer bullets, TDD, mutation checks), agent-driven review (/security-review, claude-code-action, Semgrep or Snyk in CI), security posture against the lethal trifecta, and automation (hooks, Playwright, benchmark assertions). Chapter 7 is the depth source — pick one, read the references, try it on a real task.

With the harness in place, the question changes from "did Claude make a mistake in this diff?" to "did the harness catch it if it did?" Diff review becomes a spot-check, not a mandate. You get faster. The agent gets trusted. Both grow together.

If you're just starting: read diffs carefully and build the reflexes. As the harness grows around you, read fewer of them. That progression is the point.

Permission modes

Claude Code has five permission modes. The active one controls what Claude can do without asking.

1. Ask permissions — Claude asks before each edit or tool run. (Default.)
2. Accept edits — Claude edits freely, you review the diff afterward.
3. Plan mode — Claude can read, think, and propose, but cannot edit or run until you leave plan mode.
4. Bypass permissions — Claude edits and runs without asking. Same state as launching with --dangerously-skip-permissions. Must be enabled in the desktop app settings before it shows up in the menu. Use only in sandboxed environments.
5. Auto mode — a classifier-driven "go fast" mode that learns safe operations and asks only on the ambiguous ones. Must be enabled in the desktop app settings. Prefer Auto over Bypass when you want speed — Auto keeps guardrails, Bypass removes them.

How to switch:

• Desktop app: press M, then a number 1–5. Modes that need settings enablement appear dimmed until turned on.
• CLI: Shift+Tab cycles through available modes. You can also start in a specific mode with --permission-mode <mode> (e.g. --permission-mode auto).

Plan mode is the one most worth knowing day-to-day. It lets Claude think as hard as it wants without doing anything destructive — you see the reasoning, accept or redirect, then leave plan mode to let it execute. Auto mode is the one most worth learning to trust, once your repo has the tests and harnesses to catch mistakes. Bypass is for sandboxes — don't make it a habit.

Plan mode doesn't persist the plan. The plan lives in the conversation and disappears with /clear. If you want plans written to disk — so you can review them later, share them with a teammate, or have /work act on them — that's what Compound Engineering's /plan skill does (chapter 6). That's the recommended flow once you have real multi-step work.

When plan mode is worth it:

• Multi-file changes where you want to see the shape before commits happen
• Anything with a destructive step (migrations, deletes, rewrites)
• Tasks where the "what" matters as much as the "how"

When it's not:

• Single-line fixes
• One-function refactors
• Quick questions

The recommended flow, when you're ready

This chapter is the daily habits. Chapter 6 is the practice that bundles them into a repeatable loop: brainstorm → plan → work → review → compound. Install the Compound Engineering plugin when you're ready — it's the shortest path from "I iterate one prompt at a time" to "I have a practice that produces reliably good work."

Practice: continue your sample

Working through the lab in order? Take what this chapter taught to the sample you started in chapter 2 — or to a codebase of your own, where it'll land harder.

1. In your project folder, ask Claude to add a second read-only endpoint — on the samples, something like GET /version returning { "version": "1.0.0" }. On your own repo, a small route with real data from your domain. Before running the prompt, hit Shift+Tab until you're in plan mode — Claude will plan but not edit.
2. Read the plan. If the shape is wrong — too many files, wrong location, missed a convention — don't bother correcting mid-plan. Double-tap Esc to rewind, then re-prompt with a narrower description. Better plan beats corrected diff.
3. Leave plan mode (Shift+Tab again) and approve. Claude writes the code, shows the diff, you run and commit when it works.

When it works: your sample has two endpoints, and you've felt plan mode + rewind on a real task — the two moves you'll use most often in the rest of the lab. The next chapter's practice has you build a small skill that scaffolds routes like this.