Claude Code & Agentic Development with Claude

What Claude Code is intermediate

Picture the difference between an assistant that tells you what to type and one you can actually hand the keyboard to. A chatbot can describe the fix — "open server.py, find the handler, add a null check" — but you still do every keystroke, every file open, every test run. That gap between advice and action is exactly what Claude Code closes, and it's why this chapter matters: you're about to see the agent loop you built by hand in C2 turned into a tool that lives in your terminal and does the typing.

The mental model to hold: it's your C2 tool-use loop, but the tools reach into your real project. In C2 you wrote a loop where the model proposes a tool call, your code runs it, and the result goes back. The "tools" there were toys — a calculator, a mock lookup. Claude Code is the identical shape, except the tools are the ones a working developer actually uses: read a file, edit a file, grep the codebase, run a shell command, hit the web, spawn a helper. Same engine, real steering wheel.

A common beginner mistake is to imagine Claude Code as a smarter autocomplete, like the inline suggestions in an editor. It isn't. Autocomplete guesses the next few characters; Claude Code takes a goal ("add a --version flag") and runs a multi-step loop — reading files, making edits, running tests, reacting to failures — until the goal is met or it needs your input. It's an agent, not a suggestion engine, and that changes how you talk to it (a whole section below) and why the safety gate exists at all.

Claude Code is Anthropic's official agentic coding tool. It's the Chapter 4 agent loop, hardened and given a real tool surface: it can read files, edit them, run shell commands, search the codebase, call the web, and spawn subagents — all under a permission system that stops before anything destructive. Under the hood it's the same Messages API and the same tool-use loop you just wrote in C2, running against a frontier model at high effort.

The agent loop, productionized intermediate

Here's the moment where "an AI that edits my code" stops being scary and starts being understandable. The word agent sounds like magic — some autonomous thing making its own decisions in your repo. It isn't magic. It's a loop you can draw on a napkin, and once you see the four boxes, the whole tool loses its mystery and you know exactly where you're in control.

Think of it like a contractor renovating your kitchen. The contractor doesn't silently knock down a wall — they say "I'd like to remove this wall," you say yes or no, then they swing the hammer, and they show you the result before proposing the next step. Claude Code runs that exact rhythm: the model proposes an action, a gate checks it (auto-approve the safe stuff, ask you about the risky stuff), the tool runs, and the result feeds back so the model can decide what to do next. Round and round until the job's done.

Why give this its own section when you already wrote a loop like it in C2? Because the stakes changed. In C2 the "tools" couldn't hurt anything — worst case, a wrong number came back. Here the tools touch your real files and run real shell commands, so the loop grows one new organ: the permission gate in the middle. The single most common misconception is that the model just does whatever it wants; in reality nothing state-changing happens without passing that gate first. Read the diagram below as "the C2 loop, plus a checkpoint" — the checkpoint is the whole reason you can trust an agent with your keyboard.

You already know this shape from C2. Claude Code is the same round-trip, with a real file/shell tool surface and a permission gate wrapped around every action.

Lab C3.1 · Install & first session intermediate

Permissions: the trust ladder intermediate

Imagine hiring a brilliant new engineer on day one and handing them production database credentials before lunch. Nobody does that — not because the person isn't capable, but because trust is earned, and the cost of a mistake before it's earned is enormous. Claude Code bakes that same instinct into software. It won't refuse to help, but it won't quietly run rm -rf or push to main either. It classifies every action by how much damage it could do, and stops to ask before the dangerous ones.

The useful analogy is a set of doors with different locks. Some doors are wide open — reading a file, searching the code, listing a directory. These can't hurt anything: worst case, the agent looks at something and moves on, so they run automatically and never interrupt you. Other doors need a key you turn each time — editing or creating a file. And some doors open onto the street — running a shell command, installing a package, pushing to git — where a mistake escapes your machine or is hard to undo. Those always pause and ask, and you decide door by door.

The mistake to avoid is thinking of approval as a one-time switch you flip to "trust this agent." It isn't binary and it isn't blanket — that's why we call it a ladder. You climb it one rung at a time: allow a specific safe command, watch what happens, allow a slightly broader pattern once you've seen it behave. Approving npm test is not the same as approving npm publish, and treating them as the same is exactly how people get burned. This is the productionized version of the human-in-the-loop gate from Chapter 4 — the difference between an agent that suggests and one that acts, made concrete as a policy the tool enforces on your behalf.

Claude Code classifies actions by risk and asks before the risky ones. This is the productionized version of the human-in-the-loop gate from Chapter 4.

Lab C3.2 · Steering with CLAUDE.md & slash commands advanced

Two mechanisms turn Claude Code from generic to your project's agent:

Subagents & parallelism advanced

You've almost certainly done this in real life without naming it. Faced with a big question — "does our codebase use this deprecated library anywhere?" — a smart team lead doesn't grind through every folder alone. They split the repo three ways, hand a slice to each teammate, and stitch the answers together at the end. What took one person a day takes three people a few hours. Claude Code does the exact same thing with subagents, and knowing when to reach for them is what separates fast agent work from slow.

A subagent is a fresh, separate Claude Code instance that the main agent spins up to handle one independent chunk of a task. Each gets its own clean context window and works on its own piece — search subsystem A while another searches subsystem B — then reports its findings back. The main agent collects those reports and synthesizes them into one answer for you. The technical name for the shape is fan out, then converge: spread wide across independent work, then pull the results back to a single point. It's the same concurrency pattern you'd build by hand with threads or async tasks in your own systems, just wrapped up so the agent manages it for you.

The trap — and it's the one worth flagging loudly — is over-delegation. Because modern models spawn subagents readily, it's tempting to think "more agents = faster," but that's backwards for the wrong shape of task. Subagents only help when the work is genuinely wide: many independent things that can happen at once. For a single sequential edit — read one file, change one function — spinning up a subagent just adds startup latency and burns extra tokens for a result the main agent could have produced directly. The rule of thumb: fan out for breadth, not for depth. If the subtasks depend on each other's output, they're not parallel, and a helper adds nothing but overhead.

For big tasks, Claude Code can spawn subagents — separate agent instances that work in parallel on independent pieces, then report back. This is the same "fan out, then synthesize" pattern you'd build with concurrency in your own systems.

Prompting a coding agent well advanced

The single biggest reason people are disappointed by coding agents is that they prompt them like a chatbot. "Fix the bug" works fine when a human reads it — the human asks a clarifying question, uses judgement, fills the gaps. An agent that can act won't pause to ask; it will confidently interpret your vague request and go do something, and if your words left room for a wrong reading, you'll get a wrong-but-plausible diff. Sharper input isn't politeness here — it's the difference between a task that closes and an afternoon of undoing damage.

The mental shift is from chatting to briefing. Think of how you'd hand a task to a capable contractor you can't interrupt for a week: you wouldn't say "make the kitchen nicer." You'd say what "done" looks like, what's off-limits, and how they'll know it worked. A good agent prompt has the same three parts — a fully specified goal, explicit bounds ("don't touch X"), and a verification step ("run the tests and fix failures"). Modern Claude does its best work when the whole task is stated once, up front, rather than dripped out over ten back-and-forth turns.

Two failure modes trip up newcomers, and they pull in opposite directions. The first is vagueness: "clean up the code" gives the agent no target, so it guesses at scope and often refactors things you never wanted touched. The fix is to bound the work — say what not to do as clearly as what to do. The second is shouting: because Claude follows instructions literally, ALL-CAPS demands and piled-on emphasis don't make it try harder, they over-trigger and distort its behaviour. The winning register is calm, literal, and specific. "Fix the login bug" is weak; "the /login endpoint 500s on empty passwords — reproduce it with a failing test, then fix it so an empty password returns a 400" is a task an agent can actually finish, because there's nothing left to guess.

An agent that can act needs sharper prompts than a chatbot. The habits that work:

What to steal for your own agents expert

Here's the reframe that makes this whole chapter pay off twice. It's easy to treat Claude Code as a finished product you consume — a clever black box from Anthropic. But you just spent C2 and Chapter 4 building the pieces it's made of, which means you can flip the relationship: instead of only using it, you can read it as a worked example of how a production agent is assembled. Every feature you've met in this chapter is a design decision you'll face in your own agents, already answered well.

The analogy is learning to cook by eating at a great restaurant with an open kitchen. You don't just enjoy the meal — you watch how they plate it, and you steal the techniques. Claude Code's permission gate is a technique. Its CLAUDE.md context loading is a technique. Its subagent fan-out, its read-only-first default, its slash commands — each is a concrete answer to a question every agent-builder must answer: how do I stop it doing damage? how do I give it standing context? how do I parallelize? how do I make prompts reusable?

The mistake worth naming is believing these features are proprietary magic you couldn't reproduce. They aren't — that's the entire point of the mapping table below. The permission gate is your human-in-the-loop approval plus risk classification from Chapter 4. CLAUDE.md is your system prompt plus retrieved conventions from Chapters 2 and 3. Slash commands are your versioned, reusable prompts. Subagents are your fan-out-and-synthesize pattern. Read each row as a promise: "you already know how to build this." If you can name the course chapter behind every feature, you've stopped seeing Claude Code as magic and started seeing it as engineering you can do too.

Claude Code is a reference implementation of everything this course teaches. Map its features to the patterns you build:

Common pitfalls expert

Almost every bad experience with a coding agent traces back to one of a handful of avoidable habits — not to the tool being weak. That's good news: it means the fixes are cheap and mostly about discipline, not cleverness. The reason a pitfall table earns its place here is that these mistakes are seductive precisely because each one feels efficient in the moment — skip the read-only pass, blanket-approve to stop the interruptions, dash off a one-line prompt — and the cost only shows up later, when a diff is wrong or a command did something you didn't want.

Notice the through-line as you read the table: every pitfall is a shortcut around one of the safety ideas this chapter taught, and every fix is simply not taking that shortcut. Skipping read-only-first trades a minute of orientation for a bad edit. Blanket-approving trades the permission gate — your one real safety net — for slightly less clicking. Re-typing conventions instead of writing a CLAUDE.md trades five minutes once for friction every session. The pattern is always the same: a small convenience now, a larger correction later. Reading this list before you start is how you skip learning each one the expensive way.

Exercises expert

shell:
  claude

prompt:
  Explain what this project does and how it's structured.
  Don't change anything yet.

# Project conventions
- Run tests with `pytest -q`; lint with `ruff check`.
- All API code targets the Anthropic Python SDK, model `claude-opus-4-8`.
- Never edit files under `generated/` by hand — they're built by `make gen`.

.claude/commands/review.md:

Review the current git diff for correctness bugs and
security issues. Report findings with severity; don't fix yet.

prompt:

The /login endpoint 500s on empty passwords.

Goal: reproduce it with a failing test, then fix it so an empty
password returns a 400 with a clear error.

Do NOT: refactor unrelated code, or add error handling for cases
that can't happen.

First: show me a short plan and the files you'll touch — wait for
my OK before editing.

Then: make one change at a time and run `pytest -q` after each
change; fix any failures before moving on.

prompt:

Refactor payments/charge.py to extract the retry logic into a
reusable helper.

1. Show a plan and the exact files you'll touch first.
2. Wait for my OK.
3. Then make ONE change at a time and run `pytest -q` between each.
4. Stop and report if any test fails; do not proceed.

Don't change public function signatures or unrelated modules.

Claude Code feature            -> Your agent's equivalent
-----------------------------------------------------------------
Permission gate on risky tools -> Human-in-the-loop approval +
                                 risk classification (Ch 4 /
                                 capstone safety gate)
CLAUDE.md project context      -> System prompt + retrieved
                                 conventions (Ch 2, Ch 3 RAG)
Slash commands                 -> Versioned, reusable prompts (Ch 2)
Subagents                      -> Parallel fan-out with a
                                 synthesis step (Ch 4)
Read-only-first workflow       -> The autonomy ladder — earn trust
                                 before acting (Ch 7 FDE)

Knowledge check check yourself