Claude Code in action

Tool use is interesting as a concept. It gets a lot more interesting when you see Claude Code chaining dozens of tool calls to solve a real problem. This lesson walks through four scenarios that show what that looks like in practice — a performance hunt, a data analysis session, a styling loop using a browser, and an infrastructure-aware pull request review.

None of these demos are about the click-by-click mechanics. They are about the shape of the work: what Claude Code was asked to do, which tools it reached for, and what came out the other end.

Scenario 1 — Optimising the Chalk library

The setup: Chalk is the fifth-most-downloaded package on npm, pulling roughly 429 million weekly downloads. A few percent off its runtime is a meaningful amount of compute saved across the ecosystem.

What Claude did: it ran the existing benchmarks to establish a baseline, then used CPU profiling to identify hot paths. It kept a running todo list of candidate optimisations, tried each one, re-ran benchmarks to confirm the impact, and discarded changes that made things worse.

Outcome: a 3.9x throughput improvement on the benchmarks. The point is not the number — it is that Claude Code drove a closed optimisation loop (measure → hypothesise → change → re-measure) using the same profiling tools a human engineer would reach for.

Scenario 2 — Churn analysis in a Jupyter notebook

The setup: a video streaming platform wanted to understand churn patterns in its subscriber data.

What Claude did: it worked inside a Jupyter notebook, executing cells to load and inspect the data, viewing the results of each cell, and then writing follow-up cells that built on what it had just learned. When an early query returned something unexpected, the next cell adjusted the analysis rather than blindly continuing.

Outcome: an iterative analysis session that mirrors how a data scientist actually works — not one giant script written upfront, but a conversation between code and results.

Scenario 3 — UI styling with the Playwright MCP server

The setup: Claude Code was asked to restyle a UI generation app. To do that well, it needed to actually see the app, not just read its source.

What Claude did: it used a Playwright MCP server — an external tool plugged into Claude Code — to open a real browser, navigate to the app, take screenshots, and evaluate the current styling. It then updated the generation prompts, reloaded the app, took another screenshot, compared, and iterated.

Outcome: a visual design loop driven entirely through tool calls. This scenario is the first concrete preview of MCP — the extension mechanism that lets Claude Code grow new capabilities without code changes to Claude Code itself.

Scenario 4 — PII detection in an automated PR review

This is the scenario that best demonstrates what "infrastructure-aware" review actually means, so it gets more detail.

The setup: a codebase defines its AWS infrastructure with Terraform. The flow is: a Lambda function is triggered, writes a record to a DynamoDB table, and that table's stream exports into an S3 bucket that is shared with an external partner. Standard serverless plumbing.

The change: a developer opened a pull request adding a new field — the user's email address — to the record the Lambda writes to DynamoDB. Taken in isolation, it looks like a one-line tweak to a Lambda handler.

What Claude did: Claude Code, running as an automated PR review via the GitHub integration, did not just look at the Lambda diff. It followed the data flow through the Terraform files — DynamoDB table, stream configuration, S3 bucket, bucket policy — and noticed that the bucket was shared with an external partner. It then flagged the PR: adding email to this record exposes user PII to a third party.

Outcome: a security issue that no linter or type checker would catch, surfaced automatically on a routine PR. The catch was only possible because Claude Code could read Terraform, trace resource relationships, and reason about where the data actually ended up.

What these four scenarios have in common

Each demo is doing the same core thing: using tool calls to gather information about a system, reasoning over what it found, and taking action. The tools change — benchmarks, Jupyter cells, Playwright screenshots, Terraform traversal — but the shape is the same.

The practical implication is that Claude Code is a flexible assistant that grows with your team's needs through tool expansion. You are not locked into a fixed set of capabilities. As you add MCP servers, custom commands, and hooks, you are shaping what Claude Code can do for your specific workflow. The rest of this course shows you how.