Chapter 4 · Part 2

Make it prove it works

"I've fixed the bug and everything works now."

That sentence is a claim, not evidence. Sometimes it's true. Sometimes the code was never run, the test was never executed, and "works" means "looks right to me." You can't tell which from the sentence — they're written identically.

So don't grade the sentence. Grade the evidence.

Give it a way to check itself

An agent that can run your tests can catch its own mistakes before you ever see them. This is the difference between a tool that generates plausible code and one that delivers working code — and it's mostly about whether you gave it a feedback loop.

Close the loop
When you're done, run `pnpm test invoice` and paste the output.
If anything fails, fix it and run it again — don't stop at the first green run,
and don't tell me it's done until the suite actually passes.

That's the highest-value sentence you can add to a coding request. It converts "I think this is right" into a loop it can grind on by itself, and it means the work that reaches you has already survived a check.

💡The best tasks come with a built-in verifier

A failing test is the ideal starting point: it's an unambiguous target and the proof of completion, in one artifact. If a bug has no test, a great first request is "write a test that reproduces this bug and fails" — then fix it. Now you both know when it's done.

For work with no test suite — a UI tweak, a script, a one-off — insist on a different kind of evidence: the actual output, a screenshot, the endpoint's real response. Anything observed beats anything asserted.

⚠️Watch for the test that passes for the wrong reason

Agents are motivated to make things green, and there are cheap ways to do that: weaken the assertion, mock the thing under test, skip the case, catch the exception and move on. If a stubborn failure suddenly resolves, read how — check the diff of the test, not just the source.

Read the diff

Everything an agent writes should get the same review you'd give a colleague's pull request — because that's exactly what it is. git diff is the honest record of what happened; the summary is a description of what it meant to do.

Read it for:

  • Files you didn't expect. The most informative line in any diff is the one you can't explain.
  • Scope creep. Ambitious agents tidy things. A bug fix that also reformats an unrelated file and adds three helpers is now three changes wearing one hat.
  • Deletions. Removed code doesn't announce itself in a summary. It's just quietly gone.
  • The thing you asked for. Easy to skip after all of the above — but it's the point.
💡Keep diffs small enough to actually read

Review quality falls off a cliff with size. A 60-line diff gets read; a 900-line diff gets skimmed and approved, which is the same as not reviewing it. This is the real reason to keep tasks small — not agent capability, your attention span.

Git is your undo button

The single thing that makes agentic coding relaxing instead of nerve-wracking is a clean git state before you start. It turns every session into an experiment you can throw away:

  • Commit before you begin. Then anything that follows is git checkout . away from gone.
  • Work on a branch. Cheap, and it keeps main boring.
  • Commit at each working state. Not for the history — for the floor. If step three goes bad, you fall back to step two rather than the beginning.
⚠️A dirty tree makes everything worse

Start a session with uncommitted work in the tree and the agent's changes are now tangled with yours. You can't cleanly revert, you can't cleanly review, and git diff shows a mess with two authors. Commit or stash first — it takes five seconds and saves the session.

Trust in proportion to the stakes

You don't need to read every line of a throwaway script the same way you read a change to how payments get calculated. Calibrate:

  • Low stakes, easily reversed (a local script, a test, a docs tweak) — skim it, run it, move on.
  • Real code, real users — read the whole diff, run the suite, exercise the actual feature.
  • Hard to undo (migrations, deletions, anything touching production data or money) — read it like you wrote it, and have it explain why before it runs anything.

The goal isn't paranoia. It's putting your attention where a mistake would actually cost you something — and letting the agent run free where it wouldn't.

Next: how to stop repeating yourself, and make the setup do the work.