Anthropic Claude · Claude Code

Claude Code

Claude Code is Claude as an agent that lives in your codebase — in the terminal, your IDE, or the desktop app. You describe a task; it reads the project, proposes a plan, and then edits files and runs commands to get it done, asking before anything risky. It’s the Claude-track counterpart to Copilot’s Agent Mode.

☺ Explain it like I’m 10

Claude Code is Claude sitting inside your computer’s projects. You tell it what to build; it first writes out a plan and shows you, and once you say “go,” it opens the right files, makes the changes, and runs things to check its work — pausing to ask before doing anything big, like a careful helper who double-checks with you.

🐧🦫Your hosts for this topic: Pico the Penguin (plans the code) and Benny the Beaver (edits across your project).

What it is

☺ Like you’re 10: Imagine a robot helper you keep in your school backpack: you unpack it once, then any time you open a project it climbs out, listens to what you want, and gets to work — think, try, look at what happened, try again, over and over.

You install it once (for example, npm i -g @anthropic-ai/claude-code) and run claude inside a project. From there it’s an agentic loop: understand the request, plan, act, observe, repeat — the same loop from Agentic AI, wired into your files, shell, and tools. The same engine also powers IDE extensions and the desktop app, and can run headless for automation.

The workflow: plan first, then act

☺ Like you’re 10: Before you build a LEGO castle, you show your friend the picture of what you’re going to make and wait for a thumbs-up — that way if the plan is wrong, you fix the picture instead of taking apart a whole castle later.

Claude Code’s signature is plan mode. Instead of editing immediately, it can lay out what it intends to do and wait for your approval — so you catch a wrong approach before any file changes.

🎬 At the AI Academy
🦊Foxy: The login’s broken across three files — can’t Benny just start fixing it right now?
🐧Pico the Penguin: Wait — I’ll write the plan first: which files change, in what order. Read it before we touch anything.
🦫Benny the Beaver: Plan approved! Now I’ll edit all three files together so the whole project stays in sync.
🐢Timmy the Turtle: And I’ll run the tests to make sure the fix really works before we call it done.
🐘Ellie the Elephant: I’ll jot “always plan before editing” into CLAUDE.md so we remember it every time.

Teaching it your project: CLAUDE.md

☺ Like you’re 10: It’s like a “house rules” note taped to the fridge that everyone reads before they start — and if your bedroom has its own extra note on the door, that closer note wins for things in your room.

A CLAUDE.md file at your repo root is always-on context — conventions, architecture notes, commands, “always/never” rules. It’s hierarchical: a global one in your home directory, one at the repo root, and more specific ones deeper in the tree, with the closest winning. Keep the most important rules near the top; put modular rules under .claude/rules/.

◆ You’ve seen this before

CLAUDE.md is exactly the idea from Customizing (Copilot’s copilot-instructions.md) and from a Claude Project’s instructions — write the rules once, and every run reads them.

Commands, memory, and hooks

☺ Like you’re 10: Commands are shortcut buttons you press to do a job fast, memory is the sticky note that remembers important stuff, and hooks are like an automatic chore that happens on its own — like the porch light that flicks on by itself every time someone walks up.

Slash commands — built-ins like /clear, /model, /agents, plus your own reusable commands as Markdown files in .claude/commands/.
Context control — /compact compresses a long session so it keeps going; memory carries key facts forward.
Hooks — shell commands that fire on events (before/after a tool runs, on session start), so you can auto-format, run a linter, or block an action.
Permissions — by default it asks before editing files or running shell commands; you can pre-approve specific tools to loosen the leash as trust grows.

Tools, MCP, and subagents

☺ Like you’re 10: MCP is like snapping new attachments onto a power drill so it can do more jobs, and subagents are teammates on a group project — the leader hands each helper their own piece and tells them exactly what they need, because they can’t read each other’s minds.

Claude Code gains new powers through MCP servers listed in an .mcp.json file — the same open standard from the foundations track, so a server you build works here and in other tools. For big jobs, subagents let a lead delegate to focused helpers, each with its own context (remember from Multi-Agent Systems: they don’t share memory, so the lead passes what each one needs).

Headless: Claude Code in CI

☺ Like you’re 10: Sometimes you don’t want to sit and chat — you just want a job done while you’re away, like setting a robot vacuum to clean every day at 3 o’clock all by itself without you pushing any buttons.

Run it non-interactively with print mode — claude -p "review this diff for security issues" — to wire Claude Code into scripts, git hooks, or a CI pipeline (an autonomous reviewer, a docs updater). That’s the delivery pipeline idea, powered by Claude.

🐢 Timmy’s checkpoint

You can explain plan mode and why it’s safer, what CLAUDE.md does and why it’s hierarchical, and how commands, hooks, permissions, MCP, and subagents extend Claude Code. Next: Building with Claude — the API underneath all of this — or the CCAR-F certification, where Claude Code is a whole exam domain.

Check your answers

Plan mode & why it’s safer: Instead of editing right away, Claude Code lays out what it intends to do — which files change and in what order — as a read-only preview and waits for your approval. It’s safer because you catch a wrong approach before any files are touched, fixing the plan rather than un-doing a bad change.
What CLAUDE.md does & why it’s hierarchical: A CLAUDE.md file is always-on context — conventions, architecture notes, commands, and “always/never” rules the model reads every run. It’s hierarchical because there can be a global one in your home directory, one at the repo root, and more specific ones deeper in the tree, with the closest file winning.
How commands, hooks, permissions, MCP & subagents extend it: Slash commands give reusable shortcuts, hooks fire shell commands on events (like auto-formatting or blocking an action), and permissions let you pre-approve tools so it asks less as trust grows. MCP servers listed in .mcp.json snap on new tools, and subagents let a lead delegate to focused helpers that each have their own context.