Claude Code, From the Inside: Same Equation, Hardened
You now hold the theory: a stateless model, a loop that calls it repeatedly, tools an external harness actually executes, and a context window that both parties read and write. Claude Code, the tool this class's later lessons and the rest of this course lean on, is that same equation, hardened into something you'd trust with real work. This lesson opens it up properly, the way you'd tour a factory floor with someone who already understands the machines rather than someone seeing gears turn for the first time.
The previous two lessons built the theory: what an agent is, and how to brief one. This lesson maps that theory onto Claude Code specifically, then covers the one design decision that turns it from a coding assistant into an organizational tool: the folder you run it in becomes the agent's entire world.
Same equation, production-grade
Nothing about Claude Code required a new theory. Every term of the equation from the first lesson of this class is present, just built out further than a hundred-and-twenty-line demo needs to go.
| Term | In the toy agent | In Claude Code |
|---|---|---|
| Model | A single API call, messages.create(...) | The same frontier model, called the same way underneath |
| Loop | for turn in range(20) | The same loop, plus interrupts (Escape mid-run), streaming output, retries, and the ability to rewind |
| Tools | Three plain functions | Twenty-plus tools: Read, Write, Edit, Bash, Grep, Glob, WebSearch, subagents, MCP connectors, all standing behind a real permission system |
| Context | A growing Python list | The same growing list, plus CLAUDE.md auto-loaded at the start of every session, skills loaded on demand, and /compact to reclaim space mid-task |
Two additions on that table deserve more than a row each, because they're the difference between a demo and a tool you'd actually run against real files.
The permission system is the safety story
Recall from the first lesson of this class: the model never touches your machine, the harness does, and safety in an agentic system lives entirely in that harness because the model has no capacity for it. Claude Code's permission system is that principle, built out into an actual feature you interact with on every run. Where the toy agent executed anything it was asked to execute, no questions asked, Claude Code inserts a real approval gate between the model's request and the actual execution of it.
The gate isn't a single switch. Permissions are configurable per tool and per pattern: a project's .claude/settings.json can pre-approve read-only operations like listing files or running tests, while still requiring an explicit yes for anything that writes, deletes, or touches the network. This is the same idea from the harness discussion in this class's first lesson, made concrete: the harness decides what's allowed, and it can decide differently for different kinds of requests instead of applying one blunt rule to everything.
This matters more than it sounds like it should, because it's the entire explanation for why an agent with real filesystem and shell access doesn't need to be treated as inherently dangerous. The danger was never really in the model requesting things. It's in what gets executed without anyone checking. A permission system that asks before anything consequential happens moves the actual risk from "can the model imagine a bad action" (it can imagine almost anything) to "does the harness let a bad action through" (a question you can answer by reading a settings file).
The folder is the workspace
The second addition is a design decision, not a feature in the usual sense, and it's the one that makes Claude Code an organizational tool rather than just a capable coding assistant. You cd into a directory, start Claude Code, and that directory becomes the agent's entire world for the session: the files it can see, the context it can read, the workspace it operates inside.
That single design choice is what lets a repository be a company. If an agent's world is scoped to whatever folder you're standing in, then a folder containing a CLAUDE.md handbook, a set of skills encoding standard procedures, a couple of subagents playing specific roles, and a data/ directory of real records isn't just a codebase anymore. It's an organization, represented as files, that an agent can be briefed into the same way a new hire is walked through their first day. The next lesson this class goes deep on exactly what lives inside that folder. For now, hold onto the mechanism: scoping the agent's world to a directory is what makes the directory-as-organization metaphor literally true rather than just a nice way of talking about it.
What twenty-plus tools buys you over three
It's worth pausing on why the tool count jumping from three to twenty-plus is a meaningful difference and not just a bigger number for its own sake. The toy agent's three functions were enough to prove the mechanism: request, execute, re-enter context. They weren't enough to do real work, because real work touches more surfaces than "list a directory, read a file, run some code."
Claude Code's tool set breaks roughly into a few real categories, each answering a different kind of request the model might make.
| Category | Examples | What it actually buys |
|---|---|---|
| File operations | Read, Write, Edit | Inspect and modify a codebase the way a person would with an editor open |
| Search operations | Grep, Glob | Find things without reading every file in a project one at a time, which matters once a project has more files than fit comfortably in a context window |
| Shell access | Bash | A general escape hatch to run arbitrary commands, and exactly why the permission system exists: an unconstrained shell is the single most consequential tool on the list |
| External information | WebSearch | Pull in information beyond training data when a task actually needs something current |
| Delegation and integration | Subagents, MCP connectors | Extend the tools term outward: a subagent is a whole separate instance of this same loop with its own context and narrower toolset; an MCP connector is a standardized way to plug in a database, a ticketing system, or an internal API without hand-writing the integration |
The last row is worth flagging even though it's covered properly in the next lesson this class: subagents and MCP connectors aren't new ideas bolted onto the equation. They're the same four terms, model, loop, tools, context, reapplied at a smaller scale inside a larger run.
None of this changes the equation from the first lesson of this class. It's still model plus loop plus tools plus context. What's different is the width of the tools term and the sophistication of the harness deciding what to do with each request, which is precisely the direction "hardened" points in throughout this lesson.
First day on the job
The clearest way to understand what a fresh Claude Code session actually experiences is to walk through what it looks like to onboard one into a real, existing project, the way you'd walk a new hire through their first morning.
The first move, before asking for any real work, is a question: "What is this project, and what rules do you operate under?" A well-configured project answers this itself, because Claude Code loads CLAUDE.md automatically at the start of every session and folds it into the system prompt. Ask that question and the agent recites back the actual rules it's operating under, the same way a competent new hire, handed the employee handbook on day one, could tell you what's in it before doing anything else. This is worth doing deliberately rather than skipping straight to a task, because it's the fastest way to confirm the handbook actually reached the session before you find out the hard way that it didn't.
Running /context shows the actual breakdown of what's currently occupying the window: how much is system prompt, how much is CLAUDE.md, how much is tool definitions, how much is accumulated transcript. This is context engineering made visible rather than theoretical. Where the first lesson of this class described the context window as finite and degrading in the abstract, /context lets you see the real numbers for the session in front of you, which is the difference between knowing a resource is scarce and knowing exactly how much of it you've already spent.
With orientation done, a real task gets the same five-part treatment the previous lesson built out in full: inputs named specifically, output specified as an exact artifact, rules stating the constraints that matter, an evidence requirement, and a stop point. A brief like "reconcile the invoices against the bank deposits for June, output a report at this exact path, match on invoice ID and never on names, include control totals that fully explain any gap, and show me your plan before executing" is the same brief this class's second lesson built from scratch, now actually typed into a real terminal against real files.
As the agent works, permission prompts appear at the moments the harness has been configured to pause: a Bash command that runs Python, a file write, whatever the project's settings mark as needing explicit approval. Each prompt is the safety story from earlier in this lesson happening in real time, not as an abstraction. Read-only operations that the project's settings pre-approved pass without interruption; writes still ask.
After the run, /cost reports what the session actually spent. For a bounded task like a monthly reconciliation, the number tends to be small, often closer to the price of a coffee than any figure that would give a finance department pause, and it's worth actually looking at rather than assuming, because "AI is expensive" and "AI is cheap" are both claims this course asks you to measure rather than take on faith.
Session hygiene: the four commands that matter
Everything in this section is, once again, context engineering, applied at the level of managing a whole session rather than a single prompt. Four commands do almost all of the real work.
/context: an X-ray of the window, showing exactly what's eating your tokens right now. The right habit is to look before wondering why quality dropped, not after./clear: a fresh window. New task, new session, every time. The single most common self-inflicted failure in agentic work is the kitchen-sink session: one long conversation asked to do five loosely related things, its context slowly filling with material irrelevant to whichever of the five is currently being worked on./clearis the discipline that prevents it./compact: summarizes the existing history to reclaim space mid-task. It's lossy by design, which makes it the right tool for the middle of a task you can't cleanly break, and the wrong tool at a task boundary, where/clearis the better, non-lossy choice.- Plan mode, via Shift+Tab: a read-only mode where the agent explores and proposes without executing anything. This is "plan before act" from the previous lesson, now enforced by the harness itself rather than left to your own discipline to remember to ask for it. It's the right default for anything that actually matters, because a correction costs ten seconds inside a plan and can cost twenty minutes once it's already in the output.
Where /clear leaves the question this lesson doesn't answer
Here's the question that should be nagging at this point, and if it is, that's the correct reaction: if /clear wipes the conversation completely, where does anything durable about a project actually live? Not in the chat. A conversation you can wipe with one command was never going to be the place an organization stored anything it cared about keeping.
Where this leaves you
You now have a real, mechanical account of what Claude Code is: the same model-loop-tools-context equation from earlier this class, with a real permission system standing between requests and execution, and one design decision, folder-as-workspace, that turns a coding tool into something an organization's structure can actually live inside. You've also picked up the session-level discipline, orient, brief in five parts, watch the gate, check the cost, clear at boundaries, that turns a capable tool into one you actually trust with recurring work.
What you haven't seen yet is the answer to the question this lesson deliberately left open: what specifically lives inside that folder, and why does each piece of it belong exactly where it is rather than somewhere else. That's the next lesson, and it's the one this entire course treats as its architectural center.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
