Claude Code

Why this chapter has no Colab

Every other chapter in this course has a notebook. This one doesn't. Claude Code is a CLI that runs on your machine, reads your files, edits them, runs commands, calls MCP servers. The whole point is that it lives where your work lives — your shell, your repo, your ~/.ssh/config, your local netmiko scripts. Putting it in Colab would defeat the purpose.

The artifacts for this chapter are a setup guide, a sample CLAUDE.md, and a sample Skill. You install Claude Code on your laptop, point it at a real project (we'll suggest one for practice), and run through the worked examples. By the end, you'll have a working setup that uses everything from chapters 01-06 — embeddings, RAG, agent loops, MCP tools — composed in your daily workflow.

The question this chapter answers: how do I use all the AI machinery we've built across this course in the actual hour-by-hour work of being a network engineer, without writing more infrastructure than I already had?

The answer is Claude Code. It is the container that makes the composition trivial. If chapters 01-06 taught you the parts, chapter 07 is the box they fit into.

The pain Claude Code addresses

Two practitioner complaints from the research phase converge into this chapter.

T6: automating broken processes at high speed. Network engineers have a healthy fear of automation that doesn't understand context. An Ansible playbook that pushes a config to 800 routers is one regex away from an outage. The conventional response is "automate carefully, review every line." The problem with that response is that it discourages automation entirely; the playbooks people would write to save themselves hours never get written because the risk-to-reward calculation feels wrong.

T10: AI generates over-engineered code by default. The r/devops complaint we collected — "AI generates enterprise-level complexity by default... we're spending all our time managing tools for the work" — captures the second failure mode. Ask a chatbot to write you a script to back up router configs and it returns 300 lines of TypeScript with dependency injection, abstract factories, and a Kubernetes manifest. You wanted twenty lines of Python that does the thing.

Claude Code is the response to both, when it's used well. It is not magic. It is a particular set of conventions for working with an LLM that minimize both failure modes: it makes changes incrementally and visibly (you watch every edit), it asks before running anything destructive, and you can configure it heavily to match your team's style so the over-engineering tendency gets cut at the prompt level.

This chapter is not a marketing pitch for Claude Code. It is the practical answer to "now that I've learned these AI techniques in chapters 01-06, what tool do I actually use every day?" If you find yourself reaching for Cursor, Continue, or Aider instead, the patterns in this chapter transfer to all of them — they are the same shape of tool.

What Claude Code actually is

Claude Code is a command-line tool. You launch it in a terminal, pointed at a project directory. It opens an interactive session with Claude. The session has three things going on at all times:

A working directory. Claude reads and writes files in this directory. It can list, search, edit, create, delete. Every change is shown to you as a diff before applying (in default permission mode). The directory might be a Python repo, an Ansible repo, a NetBox extension, a folder full of configs you exported, anything.

A tool surface. Bash (with permission), file edits, web fetches, MCP servers you've connected. Each tool call is visible. Each is approved (default) or auto-approved (if you've allowlisted the pattern). The tool surface is configurable; locking it down to "only read, no run" is one config flag away.

A loop. The same agent loop from chapter 05. Claude takes your prompt, plans, calls tools to investigate, edits files, runs tests, asks for confirmation when needed, iterates. You're inside the loop — every step is interactive in default mode, autonomous in opt-in mode.

That is everything. The CLI surface is small. The leverage comes from how you configure the surroundings — CLAUDE.md, skills, hooks, slash commands, MCP servers — all of which we'll get to.

The CLAUDE.md pattern

CLAUDE.md is a Markdown file you write that lives in your project root. Claude Code reads it at the start of every session. It is instructions to Claude about this codebase. The pattern is the single most important configuration mechanism in Claude Code and it is also the most underused.

A good CLAUDE.md includes:

• What this codebase is. One paragraph, not a sales pitch. "This is the team's netops automation repo. Python 3.11. Uses netmiko for SSH, NetBox API for source of truth. Runs from ops-jenkins host on Mondays at 03:00."
• What conventions to follow. Style choices, library preferences, naming patterns. "Prefer napalm for vendor-neutral operations; fall back to netmiko only when napalm doesn't support the operation. Never import requests directly; we wrap it in netops.http for retries and audit logging."
• What NOT to do. Negative space is as important as positive. "Do not add new dependencies without asking. Do not refactor modules I haven't touched. Do not edit vendored/ — that directory is mirrored from upstream."
• The mental model. A short explanation of why the code is shaped the way it is. "All device operations go through netops.connection.Connection because we need to plug audit logging into every SSH call after the 2024 incident. Don't bypass it."
• Where to look first. Pointers to the entry points and the canonical docs. "Read docs/runbooks/playbook-conventions.md before authoring a new playbook. Tests live in tests/; coverage target is 80% on new code."

The function of CLAUDE.md is to make Claude useful without making you re-explain context every session. Treat it as onboarding documentation for a smart engineer joining your team for one day. If the doc would help a human engineer ramp up, it will help Claude. If it's vague — "follow best practices" — it will help nobody.

A pathological pattern to avoid: stuffing CLAUDE.md with code conventions that contradict your actual codebase. The model believes what CLAUDE.md says. If you write "we always type-hint everything" but half your modules don't, Claude will add type hints unbidden. If you write "we never use threads" and you have one threading.Lock in a critical module, Claude will try to remove it. The doc and the code must agree.

A sample CLAUDE.md for a network operations project ships with this chapter as sample-CLAUDE.md. Read it. It's about 100 lines. It is approximately what your real one should look like.

Skills: when CLAUDE.md isn't the right scope

CLAUDE.md is global to a project. Skills are scoped to a task. The distinction matters because most teams have several recurring tasks that need different instructions: writing postmortems differs from writing change-management tickets which differs from writing customer-facing summaries.

A Skill is a folder containing a SKILL.md plus any auxiliary files. The SKILL.md has YAML frontmatter:

---
name: write-network-postmortem
description: Use when writing a postmortem for a network incident. Produces the team's standard format with timeline, root cause, blast radius, and remediation sections.
---

The description is what Claude reads when deciding whether to activate this skill. When a user asks something like "write a postmortem for last night's BGP flap", Claude scans available skill descriptions, sees this one matches, loads the SKILL.md content into context, and follows it.

The content of the SKILL.md is the instructions you'd give a junior engineer. The exact section order. The mandatory metadata fields. The tone — "first-person past tense, no blame language." The data to gather — "include exact start/end timestamps in UTC, the on-call engineer's notes, the affected customer count." The template at the bottom, ready to fill in.

Skills compose. A session can have many skills available; only relevant ones activate. The mechanism scales much better than putting every workflow into a giant CLAUDE.md.

The sample skill in this chapter — sample-skill.md — is a writing-network-postmortem skill that demonstrates the pattern. Use it as the template for your team's skills. The first three skills most networking teams should write: write-postmortem, draft-change-ticket, triage-customer-issue. They cover ~60% of the prose work on the team.

Hooks: when you need a guarantee, not a suggestion

Skills tell Claude what to do when the task matches. Hooks force Claude to behave a certain way regardless of the task.

A hook is a shell command Claude Code runs automatically on a configured event. The events: before a tool call (PreToolUse), after a tool call (PostToolUse), at session start, when Claude stops, on user prompt submission. The shell command runs; if it exits non-zero, the action is blocked.

Concrete network-ops examples:

Block destructive bash commands. A PreToolUse hook on the Bash tool that examines the command. If the command matches wr erase, clear bgp, format flash:, or anything else on your team's "never automate" list, exit 1 with a message. Claude can't run it.

Audit log everything. A PostToolUse hook that logs every tool call to a file or to syslog. Tag with timestamp, user, project. Now you have a permanent record of what Claude did in your codebase.

Re-format after every edit. A PostToolUse hook on file edits that runs black or prettier against the changed file. Claude can't leave files in an unformatted state.

Require git status before stop. A Stop hook that exits 1 if git status shows uncommitted changes Claude introduced without your knowledge. Now Claude has to commit or stash before claiming done.

Hooks are how you make Claude Code boring and safe without making it tedious. The hook is a guardrail; the agent works within the guardrail; you don't have to remember to enforce the rule every session.

MCP: the chapter that makes chapter 06 real

Chapter 06 taught you what MCP is and how to build a tool layer in its shape. Claude Code is an MCP client. To use your MCP server from Claude Code, you add one entry to ~/.claude.json (or similar config). The tool you defined in chapter 06's notebook becomes a real tool in your Claude Code session. The model can call it. The audit log captures it.

This is where the course compounds. Each chapter built a piece:

• Chapter 02's sentence-transformer embeddings → an MCP tool that returns similar tickets.
• Chapter 03's LoRA-classified log lines → an MCP tool that classifies an incoming log.
• Chapter 04's RAG over configs → an MCP tool that answers questions about your config corpus.
• Chapter 05's agent loop → not exposed as a tool because Claude Code IS the agent loop.
• Chapter 06's vendor-abstracting MCP server → connected directly.

A Claude Code session pointed at your netops repo, with all five of these MCP tools wired in, plus a CLAUDE.md that explains your team's conventions, plus three skills (postmortem, change ticket, customer triage), plus three hooks (block destructive commands, audit log, format on edit) — this is what a modern network operations AI assistant looks like in 2026. It is exactly the composition this course has been building toward.

Setup guide walks through the wiring.

The on-call workflow that ties it together

A worked example that makes the abstractions concrete.

It is 02:30. PagerDuty fires — packet loss between site-A and site-C. You open your laptop, navigate to your netops repo, and run claude. Claude Code starts; reads your CLAUDE.md; sees the MCP servers loaded.

You type: "Customer reports packet loss between site-A and site-C in the last 20 minutes. Investigate. Read-only first."

Claude reads its CLAUDE.md and learns your team's conventions. It picks up the investigate-network-issue skill (because the description matches). The skill says: "Start by querying monitoring for the time window, then check device states along the path, then check recent changes."

Claude calls the prometheus MCP tool, finds elevated drops on edge-isp-a Gi0/0/3. It calls mcp_show_interface (your chapter-06 tool), confirms the interface is up but errors are high. It calls rag_search_configs, finds the route-map on edge-isp-a that uses Gi0/0/3. It calls git_log_last_24h (another MCP tool), finds yesterday's change to that route-map.

Claude returns: "Root cause likely Layer 1 errors on edge-isp-a Gi0/0/3, which is the preferred path per route-map PREFER-LOCAL (last changed 17:42 yesterday by edy in commit a3f5d92). Confirm the change is intentional. Suggest checking the SFP first."

You confirm the change is intentional. You type: "Override the route-map to prefer Gi0/0/4 until the SFP is replaced. Dry-run first."

Claude calls mcp_apply_config_change(hostname='edge-isp-a', config_text='...', dry_run=True). Returns the dry-run diff. You read it. You type: "Confirm and apply. Token: I-CONFIRM-PROD-CHANGE."

The PreToolUse hook checks the command pattern. Passes. The MCP server validates the confirmation token. Passes. The change applies. The PostToolUse hook logs the change to your audit pipeline.

You then type: "Write a postmortem for tonight's incident, using the standard format." Claude activates the write-network-postmortem skill, gathers the timestamps and tool call history from the audit log, drafts the postmortem.

End-to-end this is maybe ten minutes of work. The 800-pound-gorilla version of the same incident — alert, hunt through Grafana, ssh to devices, check git log, decide on rollback, push change, write postmortem — used to be 60-90 minutes. The compression is what the chapter is about. Not the model. Not the algorithm. The composition.

What goes wrong (and how the hooks save you)

This sounds magical. It is not magical. The failure modes are predictable.

The model misreads the situation. Claude diagnoses the wrong root cause. This is when you, the human in the loop, override it. You read the evidence Claude gathered, see it pointing somewhere else, redirect. The cost of being wrong about diagnosis is minutes — you re-prompt. Compare to the cost of being wrong about a config change, which is outages.

The model wants to do something destructive. Hooks block it. The Bash hook intercepts clear bgp before it executes. The MCP server's confirmation-token requirement intercepts unauthorized writes. The user sees a clear error: "Operation blocked by team policy. Use the change-management workflow."

The session loses context. You restart Claude Code, the new session has no memory of the previous one. Mitigation: write findings to a file (an "investigation log") that the next session can read. Or use the --continue flag to resume the previous session. Or use external memory tooling (chapter 06's MCP server can be one).

The model invents a tool that doesn't exist. Claude Code's MCP client enforces the tool schema. Invented calls fail cleanly. Claude re-tries with valid tool names. The audit log shows the failed attempt — useful for debugging your tool descriptions if it keeps trying the wrong thing.

The model spends $100 in the night. Long autonomous sessions can rack up token costs. Budget caps go in the harness, not in the prompt. Set a daily token budget in your team's Claude Code wrapper script. Hard-stop at the cap.

All of these are tractable. None of them are reasons to skip Claude Code. They are reasons to deploy it with the guardrails this chapter teaches.

When NOT to reach for Claude Code

A short list of cases where the conventional tools are better.

One-line shell commands. ssh router show ip interface brief is faster typed than asked. Don't engage the LLM for things faster than the engagement.

Production change windows where every step needs human review. Use Claude Code to draft the change. Use your CI/CD pipeline to deploy it. Don't merge those steps.

Operations where speed matters more than correctness. If the network is on fire and you need to clear a session NOW, type the command directly. The LLM adds 30 seconds of latency. In an outage, 30 seconds is the difference between a 5-minute and a 5-and-a-half-minute downtime ticket.

Operations where the audit trail is the deliverable. PCI compliance demands a specific log format with a specific approver chain. Don't substitute Claude's audit log; use the system your auditor expects.

The point: Claude Code is a tool, not a worldview. Use it where it fits. The fact that it can do something doesn't mean it should.

What the setup guide will give you

setup-guide.md is the install-and-configure walkthrough. It covers:

1. Install Claude Code. A one-liner for macOS, Linux, Windows.
2. Authenticate. API key vs. Pro/Max subscription.
3. Initialize a sandbox project. A safe place to practice that can't touch production.
4. Write your first CLAUDE.md. Use sample-CLAUDE.md as a template.
5. Install one skill. Drop sample-skill.md into the skills directory.
6. Connect an MCP server. Use chapter 06's mock netmiko server as the first one.
7. Configure one hook. A PreToolUse hook that blocks wr erase patterns.
8. Run the worked example. The on-call workflow from this chapter, end-to-end.
9. Iterate. Add your second skill. Connect a second MCP server. Tune CLAUDE.md based on what you found yourself re-explaining.

By the end of the setup guide, you have a working Claude Code environment that uses chapter 06's MCP server, a chapter-04-style RAG-ish workflow inside Claude's tool surface, and the safety patterns from chapter 05. The course's pieces fit together for the first time on your own machine.

What comes next

Chapter 08 is full-stack Python — building a small web app (Streamlit-in-Colab) that puts the same AI-driven netops capability behind a UI for teammates who don't live in the terminal. Claude Code is the engineer's daily driver; the Streamlit dashboard is the version a junior NOC operator uses. Different tools, same engine.

Chapter 00 (the archive of curriculum-design conversations) is the meta companion — the place where this course's structure was iterated. You may or may not read it. The structure of these nine chapters was hard-won; the conversations show the alternatives we discarded.

For now: install Claude Code. Write your CLAUDE.md. Run a session. Internalize that Claude Code is not a different tool — it's the same tools from chapters 01-06, in a configuration that fits your daily workflow. That reframe is what makes the rest of your AI adoption sustainable. You're not learning a new framework every six months; you're using the same primitives, recomposed for new tasks.

Field exercise: initialize Claude Code in a sandbox repo. Write a CLAUDE.md that captures one piece of context about your real team's work. Run one session. Iterate on CLAUDE.md based on what surprised you. Repeat until Claude needs almost no clarification at session start. You may discover that the doc has become useful to your human teammates too.

Wrong way to use this chapter: treat Claude Code as a chatbot in a fancy terminal. Right way: treat it as the harness for the agent + tools + skills + hooks composition this course has been building, and put the configuration effort in once, then reap it daily.

Pain anchored: T6 (automating broken processes at high speed) + T10 (AI generates enterprise-complexity by default). The safety patterns and the CLAUDE.md conventions are the antidote — they keep the LLM narrow, deliberate, and aligned with your team's actual practice. Maps to: chapter 07-claude-code. No polished sibling chapters yet — the setup-guide.md, sample-CLAUDE.md, and sample-skill.md artifacts in this folder are the chapter's first content.