What done actually means

The command ran without errors.

For a long time I treated that as enough. The terminal was clean. The exit code was zero. Move on.

The problem is that a lot of things can run cleanly and still not have worked. A file pushed to the wrong branch. A page that builds but 404s on the live URL. A payment method configured but not activated. A message sitting in drafts instead of sent.

The absence of an error is not the presence of a result.

The check you skip when you’re moving fast

The fix is simple: after any action, verify the output. Not by reading the terminal — by checking the actual thing.

Published to GitHub Pages? Open the live URL. Configured a payment method? Go to the payments screen and check its status. Sent a message? Confirm it landed in sent.

The reason this doesn’t always happen is friction. When you’re moving through a list of tasks quickly, the check feels like overhead. You trust the process and keep going.

The time to catch a broken outcome is immediately. Not when someone else finds it.

What changes when verification costs nothing

One of the quieter shifts from working with Claude Code is that verification is now nearly free. Open the live URL, read the admin screen, check the file — thirty seconds from a single instruction.

When checking costs thirty seconds, skipping it feels wrong. The cost of verification has dropped below the cost of assumption.

This changes the habit. Not because the process is less trustworthy. Because looking is no longer the friction it used to be.

Done doesn’t mean the command ran. Done means the outcome exists.