Module 3 · Glossary

Words this module uses.

A short reference for the words this module uses. Bookmark this page. The end-of-module check is closed-book, but the glossary is allowed (looking up vocabulary is fine; looking up answers is not). New terms in Module 3 build on the Module 1 and Module 2 glossaries — keep all three reachable.

Words about coding agents

Suggester
An AI that returns text in response to a prompt. You read it, copy it, paste it. The human is doing the locating, deciding, editing, and verifying. Old-style "AI for coding" is mostly suggester.
Coding agent
An AI that doesn't just return text — it can read files, search across them, write new files, edit existing ones, run commands in a shell, and check the result of those commands. Same model as a suggester, plus tools and a loop. Module 1's four-part definition (model + loop + tools + state) describes this.
Directed edit
A single change you instruct a coding agent to make. The atom of Module 3.
The four moves
Every directed edit runs through locate (where does the change belong), plan (what will change), write (the actual diff), verify (did it do what was asked). You check locate and plan; you read the write line by line; you confirm the verify ran and signaled success.
Frontier model
A current top-tier large model from a major provider — as of 2026, Anthropic Sonnet/Opus, OpenAI's top tier, Google's top tier. The opposite is a smaller or older model. The boundary moves about every six months as new releases push it forward.

Words about diffs and review

Diff
The set of changes between what a file used to contain and what it contains now. Lines removed are usually shown with a - prefix and red highlighting; lines added with + and green; unchanged context lines plain.
The four diff-review questions
Run on every diff: (1) is the change in the right place? (2) does the change do what was asked, and only that? (3) does the deletion make sense — what behavior went away? (4) are there changes I didn't expect to see at all?
Misplaced change
Failure mode 1: the fix works here but in the wrong location, so it won't generalize.
Scope creep
Failure mode 2: the agent did more than you asked — extra files touched, extra "improvements" you didn't request.
Silent deletion
Failure mode 3: code that carried real behavior is removed without an equivalent replacement. Hardest to spot because the removed behavior is invisible in the new code.
Plausible wrong
Failure mode 4: the diff looks right, compiles, runs, passes the tests — and does the wrong thing on a case the tests didn't cover.
Minimal diff
The smallest change that satisfies the goal. If a diff is much larger than you expected, ask the agent for a minimal version before merging.

Words about zones and tripwires (Lesson 3.4)

Strong zone
A category of work where a coding agent reliably outruns a human — bounded changes, mechanical transformations across many files, exploring an unfamiliar codebase, first drafts of structured artifacts.
Tripwire
A category of work where coding agents confidently fail. Eight worth memorizing: unfamiliar libraries, need-to-run-to-know, illegible goals, unfamiliar codebase, rewrites over additions, security/safety-critical, weak tests, session drift.
Session drift
Tripwire 8: in a multi-hour session, agents propose larger changes and directors approve them faster. Counter by starting fresh sessions on purpose, especially past the two-hour mark.
The three reframe habits
Three moves that pull a tripwire-zone task closer to the strong zone: make goals legible, prefer additions to rewrites, build the verify signal you wish existed.
Recovery path
Three practices that let you survive a bad merge: small commits, a working baseline you can return to, willingness to revert.

Words about scoping (Lesson 3.5)

Scoping doc
A short planning artifact (200–400 words, five sections) you write before starting a feature-sized change. The five sections: goal, surface area, slices, verify signals, out-of-scope list.
Slice
A single bounded directed edit that is part of a larger feature. Each slice has a verifiable end state — the system works after every slice, even if the full feature isn't done until the last one.
Scaffold → path-through → polish
The slicing pattern that works on most features. Scaffold adds structure without behavior; path-through wires the structure to real working behavior end-to-end (even if rough); polish handles edge cases and error states.
Out-of-scope list
The part of a scoping doc that lists things adjacent to the feature you're explicitly choosing not to do in this plan. Defends against scope creep before the agent proposes it.

Words about source control (introduced lightly in Module 2; deepened here)

Git
A tool that tracks changes to files over time. Records snapshots called commits. Runs locally on your computer.
Repository / repo
A project tracked by git. Has a .git/ folder at its root.
Clone
Make a local copy of a repository, usually from GitHub. git clone <url> fetches it and sets up the local copy.
Commit
A saved snapshot of your project's state in git. git commit -m "message" creates one with the message you wrote describing the change.
git status
Shows you what's changed since the last commit. The first command to run when you're not sure what's going on.
git diff
Shows you the line-by-line changes since the last commit (or between any two commits). The command-line equivalent of VS Code's diff view.
git add
Stages a change for the next commit. You add a file (or all changed files) before committing.
Baseline
A known-good state of a repo you can return to if something breaks. Usually main (the default branch) on a fresh clone.
Revert
Undo a commit. git revert <commit> makes a new commit that reverses the changes from the named one. Different from reset, which rewrites history (don't use reset --hard from an agent's suggestion).
Branch
A named line of development in git. The default is usually called main or master. You can ignore branches for most of Module 3 — the lessons stay on main.

Words about Python and tests

Python
The programming language the starter repo uses. You'll run Python scripts (python3 script.py) and read short Python files; you won't write Python from scratch.
CLI (command-line interface)
A program you run from the terminal, not a graphical app. The tidy.py script is a CLI — you give it arguments on the command line and it does its job.
pytest
Python's standard test-running tool. Discovers files starting with test_ and runs the functions inside them. The starter repo includes a tests/ folder with pytest tests; python3 -m pytest tests/ runs them.
pip
Python's package installer. python3 -m pip install pytest installs pytest. Lesson 3.2 has you run this once.
Test suite
The collection of automated tests in a project. "The tests pass" usually means "running the test suite returned no failures."
Test coverage
Whether your tests actually exercise the behavior you care about. Tests can pass without covering the goal — that's the plausible-wrong failure mode (Lesson 3.3).

Words about agents and editor configuration

CLAUDE.md / COWORK.md
A convention some repositories adopt: a Markdown file at the repo's root that the coding agent reads at the start of a session, like a personal style guide for that codebase. Optional. Useful for storing the diff-review checklist (Lesson 3.3) so the agent shares the same review framing you use.
Slash command (Claude Code CLI)
Utility commands in the Claude Code CLI that start with /. Common ones: /status, /help, /exit, /clear. Type them at the same prompt where you'd ask a question; the leading / tells the CLI to treat the line as a command, not as input to the model. (Optional advanced — only relevant if you set up the CLI in Lesson 2.4.)
Folder picker (Code tab)
The Code tab's UI for selecting which folder on your computer the agent has access to. The Code tab can read and write only inside the folder you grant. To switch folders, look for the folder name at the top of the Code tab — usually with a small icon next to it for changing.
Session panel
The part of the Code tab's UI that shows what's active in the current session — connected folder, model in use, any tools enabled. The “is the Code tab live” check (Lesson 3.1) is “look at the project / folder picker and confirm a folder is connected; if no folder, you're in suggester mode.”

Keep going

Back to Module 3.

Open the Module 3 overview →