Make one change you can trust

The service is running. The deployment monitor says it is down. Before you reach for an agent, there is a useful question to ask: what would convince you which one is right?

In this chapter’s worked scenario, you have inherited a small payments service. It answers a health check at /health; a new monitor expects /healthz. Your ticket is to support the new address without breaking the old one, and add a test that proves both still work. No payment logic needs to change. You can state the whole job in a sentence.

That makes it a good first encounter with a coding agent. The change is small enough to understand completely, yet it gives the agent several opportunities to be plausibly wrong: rename the old route, test a helper without sending an HTTP request, or announce success after running the wrong tests. You will learn to spot those differences while the code still fits on your screen.

The project on your desk

The examples use an Express service written in TypeScript. Its routes begin in src/index.ts, its payment code lives under src/payments/, and its Vitest tests live in tests/. You need basic Git and TypeScript familiarity, a terminal, and access to Claude Code. Keep your usual editor open; you will use it to inspect what changes.

Following along

This chapter is a worked walkthrough of the course’s payments example project. A public starter repository with versioned lesson checkpoints is not supplied here yet. If you have the project from your course host, use a working copy set aside for the course. Otherwise, read the examples as a walkthrough or adapt the task to a disposable Express project you own; the paths below are specific to the payments project.

If you have that project, install its dependencies with npm install and record the result of npm test before making changes. The starter includes deliberate bugs. An existing failure belongs in your baseline; it is not a reason to let a health-check task rewrite the payment processor.

One ticket, five decisions

First, install Claude Code and open it in the project. Then sign in and ask it to find the existing health route. You will compare the answer with the code before asking for an edit.

With that evidence in hand, give it the change and its acceptance conditions. Watch which files it reads, what it changes, and what its checks actually establish. Next, review the diff and decide whether the result is ready to commit. Finally, put the same workflow beside your editor.

By the end, you should be able to take a small agent-assisted change through that sequence and explain your decision to accept or reject it. The endpoint is practice. The ability to judge the work is what you carry into the rest of the payments project.