CLI

A CLI coding agent — Claude Code is the reference example — is a model that lives in your terminal with permission to act: read files, edit them, run commands, commit. The chat window asks you to be the hands; the CLI is the hands. That one change is what makes the entire back half of this course possible, and it changes what "using a model" means day to day: your job stops being typing code and becomes setting direction, granting capability, and reviewing consequences. This lesson is the operating manual for that job.

The loop, and where you fit in it

A session is a rhythm: you state an outcome; the agent proposes and executes actions — read these files, edit this one, run the tests — showing you each step; you steer. Three habits determine whether that loop compounds or thrashes:

Close the verification loop inside the agent. "Make the change, run the tests, and iterate until they pass" outperforms "make the change" followed by you testing manually — not marginally, categorically. A model is far better at fixing a failure it can see than at writing perfect code blind, and every cycle you keep inside the loop is a round-trip you don't spend. This single habit — give the agent the checker, not just the task — is the seed that grows into evals (lesson 21) and CI gates (lesson 28).

Interrupt early. When you see a wrong turn forming, stop it (Escape in Claude Code) and redirect. Watching a wrong approach complete "to see where it goes" costs tokens and pollutes the context with a failed attempt that then influences everything after it (lessons 1 and 2). The best operators interrupt more, not less — a five-second redirect beats a five-minute wrong diff every time.

Work the session controls. /clear between tasks (lesson 2's task-clear-task rhythm), /compact at milestones to carry a summary forward, /model to switch brains mid-session (plan on the strong model, grind on the cheap one — lesson 10), plan mode for anything multi-file (lesson 1's propose-then-approve, built in). These aren't conveniences; they're the context and cost levers made into keystrokes.

Permissions: the real interface

The defining design question of a terminal agent is what may it do without asking. Claude Code's default is conservative — reads are free; edits and commands prompt for approval — and the tool offers graduated trust: allow once, allow always for a tool or command pattern, per-project allowlists in .claude/settings.json (shared with the team) and settings.local.json (yours). Treat this configuration as the security boundary it is, and grow it in a deliberate sequence:

1. New codebase: prompt for everything. The prompts are a guided tour of what the agent wants to do — valuable in themselves for the first few sessions.
2. Allowlist the safe, high-frequency verbs once you trust the setup: test runners, linters, git status/diff/log, the build. These are read-mostly and reversible; prompting on them is pure friction that trains you to approve reflexively — and reflexive approval is the real danger, because it spends the attention you need for the prompts that matter.
3. Keep prompts meaningful for the destructive verbs: pushes, installs, deletes, anything network-facing, anything with credentials in reach. Two facts should anchor this line: the agent's shell runs as you — your env vars, your ~/.ssh, your cloud config (lesson 5) — and an agent can be steered by content it reads (a poisoned README, a hostile tool description — lesson 26). The permission prompt is where you catch that. Full-autonomy mode (--dangerously-skip-permissions) has legitimate uses — inside a container, in CI — and that's lesson 18's territory, not day one's.

The environment does the briefing

A CLI agent reads the project's CLAUDE.md at session start (lesson 8): conventions, commands, boundaries, supplied automatically, every time. The compound-interest consequence: time spent briefing the repo improves every future session, for everyone — including the you of next month and the CI agent of lesson 28. The professional tell of a team that's serious about agents isn't clever prompts; it's a well-tended CLAUDE.md, a .claude/commands/ directory with their procedures (lesson 9), and hooks guarding their invariants (lesson 15). The environment, not the operator, carries the quality.

That's also the answer to "the agent keeps doing X wrong": fix it once, in the environment, rather than correcting it per-session forever. Correction that lives in conversation dies with the conversation (lesson 2); correction that lives in the repo compounds (lesson 16 builds a whole practice on this reflex).

The failure catalog

• The unwatched 200-line diff. Autonomy plus inattention. Fix: review agent diffs like a fast confident junior's — git diff before anything merges, always. Ask for small, frequent commits; they make review cheap and rollback surgical.
• Reflexive approval. Twenty prompts in, you're pressing "allow" without reading. Fix: that's the signal to widen the allowlist for the safe verbs — so the remaining prompts regain meaning.
• Environment drift. "Works in the agent session, fails in CI" usually means your shell and CI's disagree — node versions, env vars — not that the agent lied. The agent runs in your environment; keep that fact in the diagnosis.
• Marathon sessions. The CLI makes six-hour conversations easy. Lesson 2 says don't; here's where you feel why — quality sag, reintroduced bugs, rising cost. Task, clear, task, clear.
• Chat-grade prompting. In a chat UI, vagueness costs a clarifying round-trip. In a CLI with edit rights, it costs real changes to real files. Lesson 1's precision stops being style advice and becomes safety equipment.

Master the terminal agent as an attended tool first — direct, interrupt, review — until your instincts calibrate. Everything after lesson 15 is about progressively removing your attention from this loop, and it goes well exactly in proportion to how deeply you understand the loop you're removing yourself from.