claude-code-lab

Chapter 2 · First contact · 10 min read

On this page9

Your first task

Open a sample project, ask Claude to make one real change, watch what happens — on your stack.

Two parallel streams below — pick the one that matches your day-job, skip the other. You don't need both.

Stream A — .NET Core · ASP.NET Core minimal API. For C# / .NET devs.
Stream B — Python + React · FastAPI backend, React frontend. For Python / JS devs.

Clone the repo once, then jump to your stream:

git clone https://github.com/ondrej-svec/claude-code-lab.git
cd claude-code-lab

Stream A — .NET Core

Open samples/dotnet-core/ in Claude. Goal: add a GET /health endpoint to the minimal API. One concrete change, end-to-end through the loop.

1. Ask for the change

In the Claude window:

Read Program.cs so you know the shape, then add a GET /health endpoint that returns { "ok": true, "uptime_seconds": n }.

Claude Code plan for the .NET /health endpoint, naming Program.cs as the file to edit and a dotnet test check to run — Claude plans first. Read it before pressing y.

What just happened. Claude didn't edit yet. It read Program.cs, drafted a plan, and named the exact file plus the verification step. No code moved. You get to approve the shape before a single character lands.

2. Approve and watch the diff

Say yes. Claude writes the change and shows it as a diff before applying.

Diff of Program.cs showing a using System.Diagnostics, a Stopwatch startedAt, and a MapGet /health route added — Small, focused diff. Two additions, no deletes.

Three lines of real code (using, startedAt, MapGet) plus two blanks. Nothing else touched. This is what "small diff" means in practice — if your first attempt sprawls, narrow the prompt and try again.

In the desktop app the same diff opens in a side panel alongside the session, not inline:

Claude Code diff review window showing a two-column diff with changes highlighted. — The diff viewer opens when a change touches files. Review before accept.

3. Run it

Accept. Then run the sample:

Start the app and hit /health to confirm it's wired up.

Terminal showing dotnet run followed by curl localhost:5055/health returning a 200 OK with ok true and uptime_seconds — 200 OK. Endpoint live. Loop closed.

You now have a running feature you can commit.

If something goes wrong

Build fails? Paste the error back: "build failed: [paste] — fix it." Claude sees its own change in context and usually fixes in one step.
Curl returns 500? Paste the server log. Don't guess; show Claude what it broke.

Stream B — Python + React

Open samples/python-react/ in Claude. Goal: same — add a GET /health endpoint to the FastAPI backend. One concrete change, end-to-end through the loop.

1. Ask for the change

In the Claude window:

Read backend/main.py so you know the shape, then add a GET /health endpoint that returns { "ok": true, "uptime_seconds": n }.

Claude Code plan for the FastAPI /health endpoint, naming backend/main.py as the file to edit and a curl check to run — Claude plans first. Read it before pressing y.

What just happened. Claude didn't touch a file yet. It opened backend/main.py, sketched the plan, and named the verification step it wants to run after. The plan is free — you can reject it, reword it, or approve it. The edit only starts after y.

2. Approve and watch the diff

Say yes. Claude writes the change and shows it as a diff.

Diff of backend/main.py showing an added time import, a _started_at monotonic timer, and a /health route — Small, focused diff. No side edits.

One import, one module-level timer, one route. That's it. Existing middleware and routes are untouched — good agent work doesn't spread.

3. Run it

Accept. Then run the backend:

Start uvicorn and hit /health to confirm it's wired up.

Terminal showing uvicorn running on port 8000 and curl returning a 200 OK with ok true and uptime_seconds — 200 OK. Endpoint live. Loop closed.

You now have a running feature you can commit.

Bonus (if you want a frontend beat): ask Claude to wire a small "Backend: OK" indicator in the React app that fetches /health on mount. One component, one fetch. Same loop, one layer up.

If something goes wrong

Uvicorn crashes? Paste the traceback: "uvicorn crashed: [paste] — fix it."
Curl returns 500? Show the server log. Don't guess; show Claude what it broke.

What you just felt

Both streams walked the same shape: describe → plan → diff → run. That shape is the spine of every agentic session. The rest of this lab earns its keep by getting progressively better at each of those four steps.

A few signals worth naming now, so you spot them later:

The plan saved you a retry. Reading the plan before pressing y is cheaper than reviewing a bad diff. Later chapters make plans much more powerful — written to disk, acted on by other commands, reviewed before any code moves. The Compound Engineering loop in chapter 6 is where that fully lands.
The diff was reviewable. Three to five lines, not thirty. Chapter 4 covers how to keep diffs small on purpose — plan mode, rewind, narrowed scope.
You didn't trust the agent — you verified. Running the endpoint was the real approval, not pressing y on the diff. Chapter 7 is the depth source on making that verification more automatic (tests, scans, CI review).
The agent worked on your stack, not a toy. Your own projects have context the agent will need. Chapter 3 is about giving it that context cleanly.

Four beats. One small feature. Do the same thing on a real repo of yours tomorrow — same shape, same rhythm.

Every chapter from here ends with a Practice: continue your sample block — your sample grows with you, or you take the same moves straight to a repo of your own.

This loop — describe, plan, diff, review, iterate — is the shape Anthropic recommends for everything. Their Claude Code best practices ↗ is worth a read once you've felt it.