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

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).

You can watch it happen. Ask for a failing test to be fixed, and the run takes a shape like this one — the tool calls in order, with the phase each belongs to:

text

you:  fix the failing tests

      Bash    run the test suite            gather context
      Read    open the file that failed     gather context
      Edit    change the line               take action
      Bash    run the test suite again      verify results

Four tool calls, three phases, and the shape is the point rather than the particular commands. The first Bash and the Read gather context. The Edit takes action. The second Bash verifies — and that last step is the one people leave out when they write prompts, which is the difference between a change that is plausible and a change that is checked.

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):

text

⏸  manual mode on
⏵⏵ accept edits on
⏸  plan mode on
⏵⏵ auto mode on
⏵⏵ don't ask on
⏵⏵ bypass permissions on

The first of those strings is a label, not the mode's real name. The mode that reviews every action has the config value default, and the CLI has labelled it Manual — and accepted manual as an alias wherever you type the value — only since v2.1.200 (Permission modes). So on an unfamiliar install match on the ⏸ and on which mode you asked for rather than on the word. Lesson 1.3 takes the whole bar apart.

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

The marketing answer is "everything", and it sets people up to expect the wrong wins.

Gets much faster	Gets slower or stays the same
Reading unfamiliar code	Deciding what to build
Mechanical, wide changes (rename, migrate, lint)	Reviewing a large diff you did not write
Writing tests for code that has none	Anything 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 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. For a run that went badly, you should be able to name one input you would change — and say why re-sending the same prompt is not on that list.