Agentic Coding with Claude Code

1The context window is the real budget

First family: choosing what goes in. It all starts from a limit. Claude only sees a limited amount of text at once. Its window holds the instructions, the conversation and the files it has read. The book gives an order of magnitude: 10,000 tokens after the first exchange, 30,000 after the second, close to 100,000 by the fifth (ch. 39). When the window fills up with things unrelated to the task, quality drops. The book calls this "context pollution". It tells three forms apart. Poisoning is a hallucination that enters the context. Confusion is off-topic material weighing on the answer. Clash is two parts of the context contradicting each other.

Against that pollution, the book describes context engineering. Claude Code applies it with four strategies (ch. 0):

• Write: keep a memory that survives from one session to the next (idea 2).
• Select: load only what the task needs (ideas 3 and 4).
• Compress: /compact summarizes the conversation and keeps the key decisions. /clear starts over from an empty conversation.
• Isolate: hand a task to a subagent. A subagent is a second instance of Claude, with its own window (ideas 5 and 6).

2A CLAUDE.md saves you from repeating everything

The first strategy, write, goes through a file. Without memory, every session starts from zero. You then have to repeat everything, for instance that the project uses Prisma, a database access library (ch. 0). CLAUDE.md fixes that. It is a text file that Claude Code loads at the start of every session. It exists on several levels (ch. 11):

• ~/.claude/CLAUDE.md applies to all your projects.
• ./CLAUDE.md applies to the project, and is shared through Git.
• CLAUDE.local.md is personal, and Git ignores it.

/Users/edenmarco/
├── .claude/CLAUDE.md             # user memory
└── Desktop/my-company/
    ├── CLAUDE.md                 # project memory
    └── frontend/CLAUDE.md        # folder memory
# Launched from frontend/, Claude Code loads all three files.
# (the book's tree, abridged)

The book's demonstration is fun. The author puts "I like pizza" in the project memory. He puts "I like hamburgers" in the user memory. He clears the conversation with /clear, then asks what he likes to eat. Claude answers both (ch. 12). So both files were read again after the /clear. The book recommends short, precise files, because an overloaded memory wastes tokens (ch. 11).

What goes on which level, in practice: the CLAUDE.md of a PHP project says what the whole team needs to know. For example: "database access goes through PDO", or "tests run with vendor/bin/phpunit". CLAUDE.local.md keeps what only concerns your machine, like the port of your local server. The file in your home folder keeps habits that apply everywhere, like the language of your commit messages.

3A skill loads only when it is needed

CLAUDE.md has a limit: it loads every session, even when it isn't needed. The book starts from an ordinary request: "give this application Anthropic's style". Without help, the agent goes looking for that style every time. Putting it in CLAUDE.md would load it even for server code (ch. 51).

The skill answers that case, and it is the second strategy: select. A skill is a folder with a SKILL.md file, and sometimes scripts. Only its header stays in the context permanently: the name and description, 100 to 200 tokens per skill. Claude reads the rest only when it judges the skill useful. The book calls this progressive loading (ch. 55).

The book's example is called git-pushing. This skill forces the agent to go through a script instead of improvising Git commands (ch. 53):

.claude/skills/git-pushing/
├── SKILL.md
└── scripts/smart_commit.sh

# SKILL.md (excerpt)
---
name: git-pushing
description: Stage, commit, and push git changes with conventional commit messages. ...
---
Stage all changes, create a conventional commit, and push to the remote branch.
**ALWAYS use the script** - do NOT use manual git commands:
bash skills/git-pushing/scripts/smart_commit.sh

The book gives a simple rule (ch. 55). A heavy task that would bloat the context goes to a subagent. A method to follow every time goes in a skill.

How to choose at home, for example: a rule true for every task goes in CLAUDE.md, like "we use PDO". A method useful only for some tasks goes in a skill. For example: writing an SQL migration following the project's conventions, or preparing a production release. The session then carries only the skill's header. Claude reads the rest on the day you write a migration.

4MCP loads all its tools up front

A skill loads on demand. MCP does the opposite. MCP (Model Context Protocol) is a standard that plugs Claude into external tools. That can be a browser, a database or a search engine. MCP loads the description of all its tools up front. So 58 tools consume 55,000 tokens before the conversation even starts (ch. 23).

The book measures that weight with /context, a command that shows what fills the window. The test project has four MCP servers. Before the first message, the system prompt takes 2,000 tokens. The system prompt is Claude's base instructions. The base tools take 12,000 tokens, and MCP close to 20% of the window. Almost half is already gone (ch. 22).

The book's countermeasure: launch only one configuration file, here Tavily's, a web search engine. The strict option avoids loading the servers from the user configuration as well (ch. 22).

claude --mcp-config .mcp.json.tavily --strict-mcp-config

Result: "MCP-related context usage drops from nearly 20% to approximately 2.4%." Disabling two servers by hand brings it to "approximately 3.2%" (ch. 22).

Practical example: run /context at the start of a session and look at MCP's share. A database MCP server is only useful in the project that queries that database. So declare it in that project's configuration. In your user configuration, it would load everywhere.

5A subagent works in its own window

Second family: doing the heavy work outside the window. Reading dozens of files fills the conversation window. The subagent avoids that problem. It has its own window, its own instructions and its own tools. It comes back with a condensed answer, 15,000 or 20,000 tokens for instance (ch. 39). In the book's words: "Each sub-agent runs in its own isolated context window and does not inherit the full conversation history of the main agent." The book contrasts two cases (ch. 1):

• A code review agent: a narrow context.
• A research agent: a wide context.

A subagent is written in a Markdown file that starts with a YAML header. YAML is a configuration format that arranges settings by indentation. Only name and description are required (ch. 37):

---
name: code-reviewer
description: Senior code review agent. Automatically analyzes code changes for bugs,
  security flaws, and convention violations. Invoke after any code modification.
tools: Read, Grep, Glob, Bash
---
(the subagent's instructions, in Markdown)

The tools line of that header applies a principle: least privilege. You give a subagent only the tools its task needs. Take Mermaid, a text language that describes a diagram. A Mermaid diagram generator needs neither a command line (Bash) nor file writing. Every extra tool weighs down the subagent's window. The book talks about "tool pollution" (ch. 39).

Concrete case: you take over an old PHP project. You look for every call to mysql_query, a function removed in PHP 7. The search returns hundreds of lines. Hand it to a subagent that only has Read and Grep. The hundreds of lines stay in its window, and it gives you only the list of files to migrate.

6A subagent's description writes its brief

The subagent has a blind spot: it doesn't see your conversation. The main agent is the Claude you chat with. It picks a subagent from its description, added to its own instructions. The subagent receives nothing but the message the main agent writes: "the only information they receive is the prompt generated by the main agent" (ch. 39). Writing the description therefore means writing part of that message.

The book gives an example: the diagram of a RAG system. RAG stands for "Retrieval-Augmented Generation". Before answering, the model looks up the useful passages in a document base, then builds its answer on them. The first diagram it gets is dense: you can't see at a glance how the components fit together. The fix comes down to one sentence added to the description (ch. 39).

# BEFORE: description generated by Claude Code (beginning)
description: Use this agent when you need to convert textual descriptions,
  requirements, processes, or concepts into visual Mermaid diagrams. ...

# AFTER: one added sentence (verbatim from the book)
... The main agent should always and always simplify the concept to the GIST.
Also write some ascii drawing to the subagent representing the concept.

With that sentence, the message to the subagent contains the simplified concept. The diagram has fewer steps. This is the idea that taught me the most: one sentence of description changes what the subagent receives.

That power of the description has a downside. The book warns that "a subagent definition obtained from an untrusted source could include malicious instructions". So I read a subagent before installing it, like a script.

The book notes a second flaw: the subagent returns only a summary. The diagram code shows up only when you expand its output, and you have to copy it by hand. So the book adds a step to the subagent's instructions: "return the actual diagram without any additional fluff". The summary still comes back. The book puts it down to "a current limitation of how the agent harness surfaces subagent responses".

At home: in the description of a code review subagent, say what the main agent must pass on. For example: "always pass the full diff and the names of the SQL tables touched". The diff is the list of changed lines. Without that sentence, the reviewer may get only a vague summary of the change.

7CodeMode replaces round trips with a script

Back to MCP, which has a second cost, this time during the work. The book calls it "ping-pong": every action makes a full round trip (ch. 23).

1. The model asks for a tool.
2. The tool runs.
3. The result is added to the history.
4. The whole history goes back to the model, which decides what comes next.

A simple example: "search, summarize, save". With ping-pong, that is three round trips. Each one sends the whole history back, intermediate results included.

CodeMode, a Cloudflare approach, changes that mechanism (ch. 24). The tools become TypeScript functions, TypeScript being a programming language. The model calls them from a script. In the example, it writes a three-line script that calls the three tools in a row. That script runs only once.

The script runs in a sandbox. A sandbox is a closed environment, cut off from the Internet. It reaches only the tools provided. It returns only what the script prints with console.log (ch. 25).

8A hook runs every time

Third family: what Claude does to your files, outside the window. An instruction in CLAUDE.md goes into the window, and Claude reads it. A hook, on the other hand, runs. A hook is a small program that Claude Code launches on its own at a precise moment. It can format the code, run the tests or block a risky edit (ch. 10). You pick the moment among five events:

• PreToolUse: before a tool runs.
• PostToolUse: right after.
• UserPromptSubmit: when you send a message.
• Notification: when Claude Code notifies you.
• Stop: just before its answer ends.

The starter example is modest: play a sound when Claude is done (ch. 10, script path simplified). The setting is written in JSON, a data format with curly braces. It goes in a settings file of the project's .claude folder.

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          { "type": "command", "command": "uv run play_sound.py" }
        ]
      }
    ]
  }
}

In that setting, uv run simply launches the Python script play_sound.py. The empty matcher means "for every event of this type". A hook runs often. So the book recommends a lightweight system command rather than a Python script (ch. 10). For example, afplay on macOS and aplay on Linux play a sound.

On a PHP project: a PostToolUse hook can run php -l after every change to a PHP file. That command checks the syntax. An error goes straight back to Claude, without waiting for someone to open the page. On the JavaScript side, the same hook can run your formatter on the changed file.

9Rewind doesn't undo commands

A hook acts at the moment of the action. Rewind, on the other hand, undoes an action afterwards, but not every action. Before every prompt that changes files, Claude Code creates a checkpoint. It keeps it for up to 30 days (ch. 13). You go back with /rewind or by pressing Esc twice. The prompt timeline then opens, with three choices:

• Restore the code and the conversation.
• Restore the conversation only, files untouched.
• Restore the code only, conversation kept.

In the demonstration, the author restores the code only. Then he asks "make it a minimal one" (ch. 13). The book then sets the limits: "Bash commands executed by Claude Code are not tracked and cannot be reverted". Manual edits aren't tracked either. And "Rewind does not replace version control systems such as Git": it is a local, short-lived "undo".

10Parallelize only what is independent

One last question about what Claude does: can you run several at once? Yes. The book launches several Claude Code instances on the same project, like developers on the same branch (ch. 34). Each one takes its own task. It works when the tasks are independent, for instance two unrelated bugs.

The book's counterexample: a backend route and the page that calls it, given to two Claudes at the same time. "The frontend agent may attempt to consume an API that does not yet exist." It then invents mock data (ch. 34).

The book judges this setup fragile, and cites the teams' countermeasure: give each agent its own workspace. With Git, that is one branch per agent, or a worktree. A worktree is a second working folder of the same repository, on its own branch. The agents no longer touch the same files, and you merge afterwards.

The book also describes a variant that is costly in tokens (ch. 40). Several subagents implement the same feature, and you keep the best version.

How to choose: ask whether one task waits for the other's result. Fixing the contact form and the orders CSV export? Nothing links them, so two Claudes can work at the same time. A PHP route that returns JSON, and the JavaScript page that reads it with fetch? The page depends on the route. Build the route first, then the page.