What Claude Code actually does

Last week I built a full Stripe integration (checkout flow, webhook handler, database updates, error handling) in one prompt. Fourteen files created or modified. Two build failures caught and fixed automatically. I did not write a single line of code.

That is not autocomplete. That is not a chatbot generating snippets you paste in. That is an autonomous agent reading your codebase, making decisions, executing changes, and checking its own work.

To understand why this works (and, more to the point, how to make it work well) you need the mechanical reality, not the marketing version. And the first thing the marketing version hides is that "Claude Code" is not one thing. It is two, wired into a loop. Get that wiring right in your head now, because everything else in this course is a consequence of it.

The model and the harness

There are two pieces to every agentic coding tool. Most people treat them as one. They are not.

The model runs on Anthropic's servers. Claude Opus, Claude Sonnet: these are language models. They take in text, reason about code, and produce text. They are exceptional at deciding what to do. On their own, they cannot read your files, run your build, or edit your project. Brains without hands.

The harness runs on your machine. Claude Code is a harness, a program in your terminal that sits between you and the model. When you type a prompt, it does not just forward your message to Anthropic. It assembles a request: your message, the relevant context, and the list of tools the model is allowed to call. Then it executes whatever the model decides, locally, and feeds the result back.

The model never touches your files. It returns structured instructions. The harness carries them out.

The harness conducts; the model plays

Here is the framing to hold onto for the rest of the course: the harness is a conductor, the model is the orchestra. The model has the talent: it can reason, write, decide. But it does not choose when to come in, in what order, or against what score. The harness does. It sets the tempo, points to the next section, and cuts a part off when it has played enough.

That metaphor is not decoration. It maps to three concrete jobs the harness performs on every turn, none of which the model controls.

Tool routing. The model does not have raw access to your disk or your shell. It emits a tool call, a structured request like Read("src/app.ts") or Bash("pnpm build"). The harness owns the actual tools. It receives that request, matches it to a real implementation, runs it, captures the output, and hands the result back as the next thing the model sees. The model is choosing from a menu the harness wrote, and the harness is the one walking to the kitchen. Swap a tool, restrict a tool, add a new tool, and you have changed what the agent can do without touching the model at all.

Permission flow. Before the harness runs a routed tool, it checks whether it is allowed to. This is a harness decision, not a model decision. The model can ask to run rm -rf, but the harness is what stands between the request and your filesystem. Each call is checked against your permission settings: auto-approved, allow-listed, or held for you to confirm. (As of Code with Claude London 2026, Auto mode is the recommended default position, with allowlists and hooks making it safe, not Strict mode that you loosen. We cover the full dial in Chapter 6.) The point for now: the model proposes, the harness disposes. You configure the harness, so you set the boundary.

Context assembly. The model is stateless. It remembers nothing between calls. Every turn, the harness rebuilds the entire picture and sends it fresh: your prompt, the conversation so far, your CLAUDE.md, the tool definitions, and the results of previous tool calls. The model only ever knows what the harness chose to put in front of it on this turn. That is why context is the resource the whole course revolves around (Chapter 4): you are not managing the model's memory, because it has none. You are managing what the conductor hands it each time it plays.

The tools

The harness exposes five categories of tools. Each plays a different part in the loop.

One distinction worth banking now: Edit finds a specific string and replaces it; Write specifies the entire file. On a 500-line file where you change two lines, Edit uses roughly 1% of the context Write would. That single fact comes back hard in Lesson 4, when context becomes the constraint behind everything.

Why a terminal tool

There are plenty of agentic coding tools: Cursor, Windsurf, Cline, Copilot Workspace. This course focuses on Claude Code because it runs in your terminal, and that matters more than it sounds.

You own the tool system. The model gets exactly the tools the harness gives it. You can add tools: your database, your browser, your docs. You can restrict them so a review agent reads but never edits. You can automate around them, firing a script every time Claude touches a file. IDE agents hand you their toolset. A terminal harness lets you build yours.

It is composable. A CLI program can be scripted, looped, piped, and automated. claude -p "review this file" runs as a one-shot. Drop it in a bash script. Chain three calls into a pipeline. Run it in CI. None of that is on the table when your agent lives inside an editor window. (It also has a billing consequence we get to in Chapter 4: scripted runs are metered differently from interactive ones.)

The default loop, and why it doesn't march in a line

Anthropic's own documentation describes the agentic loop as three phases that blend together: gather context, take action, verify results. The word doing the work in that sentence is blend. The phases are real, but they are not a checklist you tick top to bottom.

Read it as a clean 1 → 2 → 3 → done and you will misread what Claude actually does. The phases interleave, and the shape of the interleaving depends on the task:

• A question ("where is auth handled?") is almost pure gather. No action, no verification. One phase, done.
• A typo fix collapses gather and act into a single beat: Claude already knows the file, edits it, and may not verify at all if you gave it nothing to check against.
• A bug fix spirals through all three, repeatedly. Gather (read the failing test) → act (patch) → verify (run it) → it still fails → gather again (read the dependency you missed) → act → verify → green. The loop tightened around the problem; it did not walk a straight line.
• A refactor front-loads gather (map every call site) and back-loads verify (the build is the judge), with action sandwiched in the middle, and a single failed build kicks it right back to gather.

That blending is not sloppiness; it is the model deciding, after each result, what the next step needs to be. A failed build is new context, so verification feeds gather. A surprising file read changes the plan, so gather feeds action mid-stream. The loop bends to the task.

Here is one bug-fix run, with the phases marked so you can see them overlap rather than queue:

Bash("pnpm test")                         [verify]  → 1 test red: null user
Read("src/auth/session.ts")               [gather]  → finds the getter
Edit("src/auth/session.ts")               [act]     → guards the null case
Bash("pnpm test")                         [verify]  → still red: different line
Read("src/auth/middleware.ts")            [gather]  → the real caller, missed first pass
Edit("src/auth/middleware.ts")            [act]     → fixes the actual bug
Bash("pnpm test")                         [verify]  → green

Three verifies, two gathers, two acts, and the order is dictated by what each result revealed, not by a fixed sequence. The first fix was wrong, verification said so, and that failure became the context for the second pass. This is the loop working as designed.

What the loop does not do on its own

Two things the default loop will not do unless you ask:

It does not plan explicitly. Plan Mode (Shift+Tab) separates exploration from execution: Claude reads, thinks, and shows you a plan before changing anything. But it is opt-in. Left on default, Claude may jump from a thin gather straight to action. When to reach for it is Chapter 3.

It does not always verify. Verification is criteria-dependent. Claude checks its work when you give it something to check against: "run the tests," "the build must pass," "match this screenshot." With no criteria, it may skip the verify phase entirely and hand you something untested. Supplying verification criteria is the single highest-leverage habit in this whole practice; it is the next lesson's spine.

One system, not just a model

Step back, because this is the frame the rest of the course is built on. People say "Claude wrote the integration," and they picture the model doing it, the clever bit, the part with the reputation. But the model alone could not open a file, run a test, or stop itself from deleting your repo. What shipped that Stripe integration was the model and the harness, working as one system: the model deciding, the harness routing every action, enforcing every permission, and assembling the context that made the next decision possible.

That distinction is where your leverage lives. You cannot retrain the model. You can shape the harness completely: the tools it offers, the permissions it enforces, the context it assembles, the loop it runs. When this course teaches CLAUDE.md, skills, hooks, subagents, and permission modes, every one of those is you reaching into the harness side of the system and tuning it. "Better results from Claude Code" almost never means a better model. It means a better-configured harness around the same model.

The tradeoff you cannot ignore

More power, more risk. The agent reads, edits, and executes across your whole project. A misunderstanding is not a wrong suggestion you backspace away. It is a wrong architectural decision executed across a dozen files before you look up.

That is exactly why the harness owns the permission flow. You tune what runs without asking, from confirm-everything to full autonomy, in Chapter 6. The dial exists because the tradeoff is real.

The rest of this course is about managing that tradeoff: structuring your codebase so the agent gathers well, configuring the harness so it acts safely, and building a system where more autonomy buys better results instead of bigger blast radius.

What comes next

You now understand the machine: the model reasons, the harness conducts, the loop bends to the task until it is done. Understanding the machine and getting the most out of it are different skills. Next lesson, eight things you can do today that immediately lift your results, and then a look at what opens up when you push further.