Time to let Claude Code touch the code. We keep the first change small on purpose: a health endpoint and one test for it. What we practise here is reading what the agent did, and checking it.
Opening a Session
Most runs in this course use the Sonnet model at medium effort. Sonnet 5.5 costs half as much per token as Opus 5.5 (API prices, October 2026), so it uses less of your plan, and you can repeat our runs without spending much. Where a run uses another model or effort, its lesson says so.
A new session starts on Opus 5.5, so open a terminal in your module-01 folder and start Claude Code like this to match our runs:
claude --model sonnet --effort medium
Inside a session that is already open, /model sonnet and /effort medium do the same. We recorded our runs in September 2026, when sonnet meant Sonnet 5. Today it starts Sonnet 5.5, one more reason your answers will read a little differently from ours.
Module 3 explains the models and the effort levels and how to choose between them.
Before you type anything, look at the line under the prompt bar. It shows the mode the session runs in, and on a current Claude Code a new session starts in auto mode.
In auto mode the agent edits files and runs commands without asking you each time, and a second model checks each action before it runs.
If yours says something else, that is fine for now. Lesson 1.6 explains every mode and how to switch between them.
The Prompt
Here is the exact text we typed. It asks for the endpoint, for a test, and for the two commands that prove both:
Add a GET /health endpoint to src/RepairDesk.Api/Program.cs that returns 200 with the JSON body {"status":"ok"}. Add one integration test for it in tests/RepairDesk.IntegrationTests/ApiTests.cs, in the same shape as the tests already there. Then run dotnet build and dotnet test and tell me what they printed.
What the Agent Did
Here is the answer we got. We shortened it to the tool calls and the reply, and we did not change a word:
Read 2 files
● Update(src\RepairDesk.Api\Program.cs)
● Update(tests\RepairDesk.IntegrationTests\ApiTests.cs)
● I need a small HealthStatus record for the test to read the
JSON. Adding it next to the other test-side records at the
bottom of ApiTests.cs.
● Update(tests\RepairDesk.IntegrationTests\ApiTests.cs)
Ran 1 shell command
● Build worked. Now running the tests.
Ran 1 shell command
● I did the job. It worked.
What I did:
1. I added a /health page to the API. It sends back
{"status":"ok"}.
2. I added one test for it in ApiTests.cs.
Build result: Good. 0 errors, 0 warnings.
Test result: Good. All tests passed.
- Unit tests: 3 passed.
- Integration tests: 5 passed (4 old ones + 1 new health test).
What you do now: Nothing. It is done and working.
Your answer will read differently, as lesson 0.5 said. Ours added a small record for the test. Yours may compare the body as text instead, or run the build in the background.
What should match is the outcome: the same two files changed, and the same counts, three unit tests and five integration tests.
Let’s read this from the top. The lines that are not the agent talking are the tool calls. The terminal folds reads and commands into a grey line with no dot.
“Read 2 files” is two reads, and each “Ran 1 shell command” is one command. An edit gets a line of its own, Update and the file.
The agent read both files and edited both. It went back once to add a record the test needs. Then it ran the build and the tests, in that order. This is the part to read first every time, because it tells you what happened.
Then read the summary. It names the two files it changed and gives the build result with its counts. It gives the test counts per project: three unit tests and five integration tests, one of them new. A good answer says what changed, and it backs the word passed with numbers we can check ourselves, which is what we do next.
The Code the Agent Wrote
Let’s look at what the agent wrote. The endpoint is in Program.cs in the RepairDesk.Api project, directly above the customers group:
app.MapGet("/health", () => Results.Ok(new { status = "ok" }));
var customers = app.MapGroup("/customers");
It returns 200 with a small JSON object. The route sits above both endpoint groups, because it belongs to neither of them.
The test is in ApiTests.cs in the RepairDesk.IntegrationTests project, next to the four tests that were already there:
[Fact]
public async Task Health_returns_ok()
{
var response = await _client.GetAsync("/health");
Assert.Equal(HttpStatusCode.OK, response.StatusCode);
var body = await response.Content
.ReadFromJsonAsync<HealthStatus>();
Assert.NotNull(body);
Assert.Equal("ok", body!.Status);
}
It calls the endpoint, checks the status code, then reads the body as JSON into a small record and checks the value. Checking the body matters, because a 200 with the wrong content is still a 200.
The record is one line at the bottom of the same class. Our agent wrote it without the word sealed, and yours may add it. Either way, the checkpoint has it, because the code analyzers module 7 turns on ask for it:
private sealed record HealthStatus(string Status);
Checking the Build and Tests
The agent told us the build and the tests passed. We do not take its word for it. We run the same two commands ourselves, in the same folder:
dotnet build dotnet test --no-build
The build:
Restore complete (1.0s) RepairDesk.Data net10.0 succeeded (0.2s) → src\RepairDesk.Data\bin\Debug\net10.0\RepairDesk.Data.dll RepairDesk.UnitTests net10.0 succeeded (0.4s) → tests\RepairDesk.UnitTests\bin\Debug\net10.0\RepairDesk.UnitTests.dll RepairDesk.Billing net10.0 succeeded (0.4s) → src\RepairDesk.Billing\bin\Debug\net10.0\RepairDesk.Billing.dll RepairDesk.Api net10.0 succeeded (0.8s) → src\RepairDesk.Api\bin\Debug\net10.0\RepairDesk.Api.dll RepairDesk.IntegrationTests net10.0 succeeded (0.5s) → tests\RepairDesk.IntegrationTests\bin\Debug\net10.0\RepairDesk.IntegrationTests.dll Build succeeded in 2.7s
And the end of the test output, eight tests in all:
RepairDesk.UnitTests test net10.0 succeeded (2.1s) RepairDesk.IntegrationTests test net10.0 succeeded (5.8s) Test summary: total: 8, failed: 0, succeeded: 8, skipped: 0, duration: 5.8s Build succeeded in 6.1s
Eight tests, where the starter had seven. Zero warnings. That is our first change: a green test we asked for, in a test suite we did not write.
We build on this habit for the rest of the course. The agent does the work, and the build and the tests decide whether the work is done.
Where We Are
Two files changed and no file is new: src/RepairDesk.Api/Program.cs and tests/RepairDesk.IntegrationTests/ApiTests.cs. The build has zero warnings, and the tests pass with 3 unit tests and 5 integration tests. If your solution looks different, module-01-complete in the source code is this exact state.
In the next lesson, we take a proper look at the Claude Code screen, and we ask the agent for a map of the whole solution.