What a coding agent actually is.

From “suggester” to “agent” CORE

The most common way people use AI with code today is as a suggester: paste a snippet, ask for a fix, get back a different snippet, paste it into the editor. The human is the one reading files, deciding what to change, opening the editor, saving, and running the result. The AI is a clever autocomplete.

A coding agent is a different kind of thing. It does not just return text. It can read files in your repository, search across them, write new files, edit existing ones, run commands in a shell, and check the result of those commands. The human is still the one setting the goal and reading the diff — but the steps in between are the agent’s.

Put it in terms of the agent loop from Module 1. A suggester is doing one half of one pass: reason, then respond. A coding agent is running the full loop — reason, pick a tool, call the tool (read a file, run a test, write a change), observe the result, reason again — on a codebase. That is the gap you are learning to direct.

The difference is not a feature — it is a category. A suggester speeds up the typing of code, but the human still does everything else: finding the right file, deciding what to change, saving the change, running it, and checking the result. A coding agent can do those steps too. Your job shifts from doing the change yourself to directing the change — telling the agent what to do, then reading the diff and verifying the result. Once making a change is no longer the slow part, the skill that matters is choosing which changes to make and confirming they are right. That is most of what programming actually is.

The four moves of a directed edit CORE

Every time a coding agent makes a real change, it runs through four moves. Naming them gives you the handles you need to direct and review the work.

Locate. The agent figures out where the change belongs. It reads the relevant files, searches for the function or module the change touches, and narrows in. A good agent spends real time here; a bad request — or a bad agent — skips this step and starts writing in the wrong place.

Plan. The agent decides what it is going to change. Sometimes the plan is one line: “replace the buggy date parser.” Sometimes it is a short outline: “add a new field to the data model, update the form, update the save function, add a test.” The plan may be explicit (the agent writes it down and asks you to confirm) or implicit (the agent just goes). Explicit is better for anything non-trivial.

Write. The agent produces the actual change. New code, edits to existing code, new files, deletions. This is the part you see most clearly — it is the diff that will show up in your editor — but it is not the part that most often goes wrong.

Verify. The agent checks that the change did what it was supposed to do. Did the test suite still pass? Did the script run without error? Did the output match what was expected? A good agent does not trust its own writing until it has seen the result. The verify step is the one that distinguishes a coding agent from an elaborate text generator.

As the director, you check two of those moves and the agent’s output on the other two. You check locate by asking “did it change the right file?” — any file the agent touched that you didn’t ask it to touch is a signal to stop and ask why. You check plan by reading the plan before the agent writes, or by reading the agent’s summary of what it did afterward and asking whether that matches what you asked for. You do not re-do write — that is the whole point of using the agent — but you scan the diff for shape: did the right files change, was the edit roughly the size you expected, did anything get added or deleted that you didn’t ask for? You don’t need to read or understand every line of code. You do not re-do verify, but you check that the verify step ran and passed — and most of all, you run the result yourself and confirm it does what you asked for. If it doesn’t, that’s the iteration: tell the agent what is still wrong and ask for the next pass. This back-and-forth is what directing an agent actually looks like.

Where the model lives CORE

Lessons 2.1 and 2.3 walked through local vs. cloud at the model level. The same four axes — capability, cost, privacy, reliability — apply when you pick the model behind your coding agent, but capability is weighted heavier than for most other tasks.

Here is why. Coding is long-chain reasoning: the agent has to hold the structure of a file or a repo in its head, plan a change across several places, and keep the plan consistent while it writes. That is exactly the kind of work where frontier cloud models pull clearly ahead of 7–13 B local models. On a real bug — especially one that touches more than one file — a local model is markedly more likely to produce confident wrong answers. For coding specifically, the capability gap is not small.

So the default recommendation for Module 3 and the rest of this course’s coding work is: cloud model behind your coding agent. Your directed edits should route through a frontier cloud model by default.

Two situations flip the default to local:

Privacy-sensitive code. If you are editing a repository that contains secrets, personally identifying information, or proprietary work you have promised not to ship to a third party, local is the right call — even at the capability cost. A slower, rougher local agent that never exfiltrates is strictly better than a brilliant cloud agent you should not have shown the code to.

High-volume small edits. If you are running dozens of small, mechanical edits a day — rename this variable, add this docstring, convert this loop — a local model is perfectly capable of that kind of work and your per-edit cost drops to zero.

Both situations will come up. Most students’ coding work, most of the time, is cloud-default. The course is honest about that because “always local for coding” is a posture that sounds disciplined and actually costs you capability you need.

Where Module 3 lives: the Code tab CORE

You met the three tabs of the Claude desktop app in Lesson 2.4. Module 3 lives almost entirely in the Code tab — the interactive coding mode where the agent reads and writes files in a folder you've granted it access to, and proposes each change with a real-time diff for you to accept or reject.

The Code tab is the right fit for Module 3 because every lesson here teaches a piece of directed file editing: locate the bug, plan the fix, write the change, verify, review the diff. That whole motion is what the Code tab is built for — point at a folder, give the agent a prompt, watch it propose changes, accept or reject each one.

The other two tabs of the desktop app do show up around Module 3, just less:

Chat is for thinking out loud about a directed-edit problem before you give it to the Code tab. Use it when you're not ready to point at specific files yet, or when you want to brainstorm an approach without giving the agent file access.

Cowork is the autonomous tab for tasks the agent works on independently — the home base for Modules 4 through 8. You'll barely use it in Module 3, and that's by design: the pedagogy of “review every diff in real time” doesn't fit Cowork's “go work on this in a cloud environment and come back when you're done” shape. Different tab, different shape of work.

Optional advanced — the Claude Code CLI. If you set up the CLI version of Claude Code in Lesson 2.4's optional advanced section, it's the same engine as the Code tab with a terminal interface. Some students prefer working in a shell. Both the Code tab and the CLI work for everything in Module 3 — the recipe sidebars below show the Code tab as the default and call out CLI differences where they exist.

What “directing” a coding agent means in practice CORE

If you take only one thing from this lesson: the skill you are building is not prompting for code. It is directing an agent that happens to write code. Those sound the same and they are not.

Prompting for code is: I want a function that sorts a list of dates. The model writes it. I copy-paste.

Directing an agent is: I have this CLI script that sorts files by extension; it is mis-sorting .tar.gz files because it is splitting on the first dot; please locate the bug, propose a fix, show me the diff before applying it, and run the existing tests after. That sentence does four things: names the goal, names the suspected location, requires a plan, requires confirmation before writing, and requires a verification step. A good coding agent uses every one of those.

Same shape, no code required: The folder ~/Documents/Family Recipes has a few hundred photos, PDFs, and Notes-app exports mixed in. I want it organized so each family member's recipes have their own subfolder, and any duplicates are flagged but not deleted. Please scan the folder first and tell me how many items belong to each person before you propose a structure. Don't move anything until I confirm. Five things again: goal, suspected scope, plan first, confirmation, verify.

You will get better at this over the rest of the course. By the end of the module, a sentence like that will feel obvious, and the edits you direct will be harder, larger, and safer than the ones you would have copy-pasted your way through a year ago. Lesson 3.2 is where you run your first one on a real repository.