Chapter 2 · First contact · 10 min read

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

The samples are both The Guide — a small Hitchhiker's-styled knowledge base. First run greets you with a Sub-Etha boot sequence (in the terminal on .NET, on screen for python-react). Browse the seeded entries, then come back here for your first real change.

Stream A — .NET Core

Open samples/dotnet-core/ in Claude. Goal: add DELETE /api/entries/{id} so the Guide can lose entries it shouldn't have collected. One concrete change, end-to-end through the loop.

1. Ask for the change

In the Claude window:

Read Program.cs and Stores/EntryStore.cs so you know the shape, then add a DELETE /api/entries/{id} endpoint. Return 204 on success, 404 if the entry doesn't exist.

What just happened. Claude didn't edit yet. It read both files, drafted a plan, named exactly which files would change, and proposed 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.

A Remove method on the store, a MapDelete route in Program.cs. 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:

3. Run it

Accept. Then run the sample:

Start the app and hit DELETE /api/entries/3 to confirm it's wired up. Then GET /api/entries to confirm the count dropped.

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.
• DELETE 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 DELETE /api/entries/{id} 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 DELETE /api/entries/{id} endpoint. Return 204 on success, 404 if the entry doesn't exist.

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.

One handler. The existing routes and middleware are untouched — good agent work doesn't spread.

3. Run it

Accept. Then run the backend:

Start uvicorn and hit DELETE /api/entries/3 to confirm it's wired up. Then GET /api/entries to confirm the count dropped.

You now have a running feature you can commit.

Bonus (if you want a frontend beat): ask Claude to wire a small delete button on each entry card in the React app that hits the new endpoint. One component change, one fetch. Same loop, one layer up.

If something goes wrong

• Uvicorn crashes? Paste the traceback: "uvicorn crashed: [paste] — fix it."
• DELETE 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 7 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 curl was the real approval, not pressing y on the diff. Chapter 8 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.