Verify the work

Work in small steps

Keep AI-assisted changes easy to understand, test, and reverse by moving through one meaningful behavior at a time.

A big request produces a big diff. When something in a big diff is wrong, finding it is slow and painful. So I break work at natural behavior boundaries: inspect, implement one result, verify it, move on.

Small doesn’t mean one file or ten lines. A step is small enough when you can:

  • state one expected result
  • pick a check that proves it
  • review the whole diff without skimming
  • undo it without throwing away unrelated progress

Split by behavior, not by layer

Say the task is add profiles, avatars, display-name validation, and account deletion.

One way to split it is by technical layer: all the database changes first, then all the API routes, then all the UI. That feels organized. But after the first step nothing user-visible works, and the diff carries assumptions that only later features need.

A better sequence:

  1. Trace how the profile update works today.
  2. Add server-side display-name validation, with tests.
  3. Show the validation error in the existing form.
  4. Add avatar upload as its own behavior.
  5. Design account deletion with its own safety review.

Each checkpoint produces one coherent result. A step can touch a route, a helper, and a test if that behavior needs all three.

Make the check fail first

For a bug fix, reproduce the problem before you edit anything. Add a focused regression test and run it. If it fails for the expected reason, the test actually reaches the bug.

Then make the smallest change that fixes that case. Run the focused test, then the nearby suite, before you widen the scope.

Write down the checkpoint

At each step, keep a short note:

Changed: reject display names longer than 50 characters
Evidence: request test fails before the fix and passes after it
Uncertainty: browser error message not implemented yet

This keeps a long task honest. One passing test doesn’t quietly turn into the whole feature is done.

Why this matters more with agents

An agent can produce a lot of code very fast. That’s the point. But speed also means a wrong assumption spreads through the project before you notice.

Small steps keep the feedback loop shorter than the mistake. You’re not supervising every keystroke. You’re making sure that when something goes wrong, it went wrong in the last ten minutes, not the last three hours.

Next time you plan a feature with an agent, ask it for the plan first. Then look at the steps. If one of them can’t be checked on its own, split it until it can.

Lesson completed