What agentic coding actually changes (and what it doesn't)
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:
> 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 passedFour 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):
⏸ manual mode on
⏵⏵ accept edits on
⏸ plan mode on
⏵⏵ auto mode on
⏵⏵ bypass permissions onLevel 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 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 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.