CCLearn

What agentic coding actually changes (and what it doesn't)

verified against Claude Code 2.1.191 · 2026-09-06review9 min

By the end you can

  • Describe the three phases of the agentic loop and name which phase a given tool call belongs to
  • Explain why a second run of the same prompt can take a different path
  • Identify the two things that do not transfer to the agent - accountability and taste

Most tools you have used are functions. You give them an input, they give you an output, and the same input gives you the same output tomorrow. prettier is a function. tsc is a function. Autocomplete is a very fast function.

Claude Code is not a function. It is a loop that decides what to do next based on what it just learned. That single difference is the whole subject of this course, and almost every mistake people make with agentic coding comes from still treating it like a function.

The loop has three phases

Anthropic's documentation describes the loop as three phases that blend into one another: gather context, take action, and verify results — repeating until the task is done (How Claude Code works).

Watch it happen. Ask for a failing test to be fixed and you will see something like this:

terminal
> fix the failing tests
 
● Bash(pnpm test)
  ⎿  1 failed, 23 passed
     FAIL src/cart.test.ts > applies the member discount
 
● Read(src/cart.ts)
  ⎿  Read 84 lines
 
● Edit(src/cart.ts)
  ⎿  Updated src/cart.ts with 1 addition and 1 removal
 
● Bash(pnpm test)
  ⎿  24 passed

Four tool calls, three phases. Bash(pnpm test) and Read gather context. Edit takes action. The second Bash(pnpm test) verifies. The last step is the one people skip when they write prompts, and it is the one that turns a plausible change into a checked one.

Why the same prompt takes a different path twice

Because each step is chosen from what the last step returned, and because the model is sampling rather than looking up, two runs of the same prompt can differ. Not usually in the outcome — a correct fix is a correct fix — but reliably in the route: which file it reads first, whether it greps before it reads, how many turns it takes.

This has a practical consequence that catches everyone once:

You cannot fix a bad result by re-running the same prompt and hoping.

If a session went badly, the useful move is to change the inputs — narrow the scope, name the file, state the symptom instead of your diagnosis, or start a fresh session so the failed attempt is not still in the context. Levels 2 and 3 are entirely about that. Re-rolling the dice is not a technique.

What it does not change

Two things stay exactly where they were.

Accountability. The commit has your name on it. Claude Code snapshots files before it edits them, so Esc Esc rewinds a bad change, and permission modes decide what runs without asking you (How Claude Code works). Both are safety nets under your decision, not replacements for it. Checkpoints cover file changes; they cannot un-deploy a deploy or un-drop a table.

How much you are delegating is written on the screen at all times. Shift+Tab cycles the permission mode, and the status bar names the one you are in (Permission modes):

terminal
⏸ manual mode on
⏵⏵ accept edits on
⏸ plan mode on
⏵⏵ auto mode on
⏵⏵ bypass permissions on

Level 10 is about choosing between those deliberately. For now, notice only that the line exists and that you can read it. A surprising number of "Claude deleted my file" stories are a session that had been left in a mode nobody looked at.

Taste. The model will happily implement the architecture you asked for. It will not tell you the architecture was the wrong idea unless you make room for that question. "Should we do this at all" remains a human job, and the faster the implementation gets, the more expensive it is to skip.

What actually gets faster

It is worth being precise, because the marketing answer ("everything") makes people expect the wrong wins.

Gets much fasterGets slower or stays the same
Reading unfamiliar codeDeciding what to build
Mechanical, wide changes (rename, migrate, lint)Reviewing a large diff you did not write
Writing tests for code that has noneAnything you cannot describe precisely
Getting from "no idea" to "one working thread"Debugging a problem you have misdiagnosed out loud

The right-hand column is not a defect. It is where your remaining leverage is, which is why this course spends Level 2 on describing problems and Level 5 on verification rather than on prompt tricks.

Checkpoint

You should now be able to look at a session transcript and say, for each tool call, which phase of the loop it belongs to — and spot a session that never reached phase three.

Sources