The loop, and why exploration is not the optional part

You have a stack trace, you have read it, and you are fairly sure what is wrong. So you type add a null check in user.ts and Claude does exactly that, quickly and correctly. Twenty minutes later the same crash returns from a different caller, because the null was arriving from upstream and your null check was a correct implementation of your guess.

Nothing went wrong mechanically. You issued an instruction with only one phase in it, and got a loop with only one phase back.

Three phases, four phases, and which is which

Two numbers get confused here. The loop has three phases; the recommended workflow — the one this level is named after — has four. Different objects.

When you give Claude a task, it works through three phases: gather context, take action, and verify results. These phases blend together. — How Claude Code works

Level 1 Lesson 1 introduced those three. The four-phase workflow — explore, plan, implement, commit — is not pure advice: its Explore step tells you to enter plan mode, where "Claude reads files and answers questions without making changes" (Best practices). The docs map neither vocabulary onto the other, so the right-hand columns are this course's reading, not a quotation:

Notice that half the recommended workflow is the first loop phase. That is the whole argument of this lesson in one row.

The phase you skip by accident

The loop is not a script you wrote. Each step is picked from what the last one returned:

Claude decides what each step requires based on what it learned from the previous step, chaining dozens of actions together and course-correcting along the way. — How Claude Code works

The docs give an example of what "fix the failing tests" might expand into: run the test suite, read the error output, search for the relevant source files, read those files, edit the files, run the tests again. Four steps of gathering before a single edit — and the edit is chosen from what those four returned, not from what you assumed before you typed. Compare add a null check in user.ts. You ran those four steps in your head and typed the conclusion, so the only gathering left is mechanical: open the file you named, apply the diff you named. The loop still runs. You have pre-empted the one phase that could have disagreed with you.

Letting Claude jump straight to coding can produce code that solves the wrong problem. — Best practices

Read that as a claim about correctness, not speed. You do not get worse code. You get correct code for the problem you asserted, and the real defect survives with a plausible fix sitting on top of it.

The documented bug-fixing recipe shows both, in order. It opens with I'm seeing an error when I run npm test, then asks for candidate fixes, and only its third message is update user.ts to add the null check you suggested (Common workflows). The sentence you should not open with is the right thing to say once the reading has happened.

Exploration is spending

Nobody teaches "always explore more", because exploration is the example the docs reach for when they name what empties a window:

A single debugging session or codebase exploration might generate and consume tens of thousands of tokens. — Best practices

Lesson 3.1 accounted for where a window goes. The window holds every file Claude reads and every command output, so the implementation runs in whatever is left after exploration — and when it stops fitting, Claude Code clears older tool outputs first and then summarises the conversation (How Claude Code works). An oversized explore phase does not evaporate when it ends: it either occupies the window or is compressed with loss. So the skill is not "explore", and not "explore less" — it is to spend the reading on the question you actually have.

Delegate, don't dictate

There is a reflex that looks like helping and is not: listing the files. Having decided the reading matters, you tell Claude which files to read and which command to run — and you have re-collapsed the phase into a script you wrote.

You don't need to specify which files to read or what commands to run. Claude figures that out. — How Claude Code works

The docs' own well-delegated example supplies a symptom and a directory and stops: the checkout flow is broken for users with expired cards, the code is in src/payments/, investigate and fix it. That is enough because the agent is not looking at one open file — because Claude sees your whole project, it can work across it (How Claude Code works). Which halves of the job belong to whom:

The last row is the one people leave blank, and the next section is what happens when they do.

The opposite failure: exploration that never ends

Deleting the explore phase is one of two failure modes. The other is what you get if you read this lesson as "explore harder": the documented infinite exploration antipattern, an unscoped "investigate" that reads hundreds of files until the window is gone. Its two documented fixes are to scope the investigation narrowly, or to hand it to a subagent that reads in its own window so the summary comes back rather than the files. Lesson 1.4 builds that failure and both escapes in full; Lesson 11.3 turns them into bounds you can write. What this lesson adds is the diagnosis, because the two failure modes look nothing alike from inside the session:

Scoping an investigation in one sentence

A bounded investigation names a question and a boundary. "Investigate the auth system" has neither: no answer ends it, so nothing tells Claude to stop.

Each right-hand cell has a stopping condition inside it. When the question is answered the phase is over, and the answer — not four hundred files — is what occupies the window while you implement. A quick test before you send: if you cannot imagine a paragraph-sized reply, you have asked for a tour rather than a finding.

A question is a legitimate use of the loop

Not every session ends in a diff, and stopping after the first phase is not a half-finished loop:

The loop adapts to what you ask. A question about your codebase might only need context gathering. A bug fix cycles through all three phases repeatedly. A refactor might involve extensive verification. — How Claude Code works

Onboarding onto unfamiliar code is the clearest case, and the documented technique is progressive narrowing: start with broad questions, then narrow down to specific areas (Common workflows). Overview, then architecture patterns, then data models, then how authentication is handled — each answer telling you what to ask next. Nothing is edited and the session is still a proper use of the loop. It pairs with Lesson 3.3: when the answering is done, clear before you implement, so the tour is not still in the window during the work.

What the rest of this level does

Explore is the phase you now have a grip on. Lesson 4.2 turns it into a mode rather than a good intention, Lesson 4.3 is about reading the plan that comes out of it, Lesson 4.4 is about when the plan is not worth its overhead, and Lesson 4.5 closes the workflow with commits you could revert one at a time.

Checkpoint

1. A colleague's transcript shows: a grep for retry, two file reads, an edit to client.ts, and a test run that passes. Which loop phase is each one, and which of the four workflow phases left no trace at all?

   ›Show answerAnswer

   The grep and the two file reads are gather context; the edit to client.ts is take action; the passing test run is verify results. Mapped onto the workflow that is Explore and then Implement, with verify folded into it — which is why the transcript feels finished.

   Commit never happened: nothing went to git, and the change lives only in the working tree. Plan is absent too in the narrow sense that no written proposal appears, but its loop phase did run — the grep and the reads are gather context. Commit is the phase that left no trace at all.

2. You are 80% sure the fix is a null check in user.ts. Write the prompt you should send instead, say what it leaves the gather-context phase to do, and say at what point the null-check sentence becomes the right one.

   ›Show answerAnswer

   Send the symptom and the location, not the diff — something in the shape of the docs' well-delegated example: "users are hitting a crash on the profile page when the account has no owner; the code is in src/users/ — investigate and fix it." A symptom in the terms you observed it, roughly where it lives, and what "fixed" looks like. You do not list the files or the commands.

   What that leaves the gather-context phase is the one thing your original prompt deleted: room to disagree with you. Claude chooses what to open and what to search, and can find that the null arrives from upstream, so the edit is picked from what the reading returned rather than from your 80%. The null-check sentence becomes right at the documented third message — after you have shared the error and asked for candidate fixes, update user.ts to add the null check you suggested. It is the wrong thing to open with and the right thing to say once the reading has happened.

3. Your teammate says "I asked Claude to investigate our caching layer and it burned the whole window without producing anything." Name both documented fixes, and rewrite their request so it has a stopping condition.

   ›Show answerAnswer

   The two documented fixes for infinite exploration are to scope the investigation narrowly, or to hand it to a subagent that reads in its own window so what comes back is the summary rather than the files. "Investigate our caching layer" has neither a question nor a boundary, so no answer ends it and nothing tells Claude to stop.

   Rewritten: "Which module decides that a cache entry is stale? Start in src/cache/." Question plus boundary. When the question is answered the phase is over, and the answer — not four hundred files — is what occupies the window while the implementation runs. The test before sending: if you cannot imagine a paragraph-sized reply, you have asked for a tour rather than a finding.