Was it actually fixed, or just silenced

Three ways an error can stop appearing

Only one of them is a fix.

The cause was removed. The bad value is no longer produced. This is what you want.

The symptom was caught. The failure still happens and is now swallowed by a try/catch, an optional chain, or a default value. The screen looks fine and the data is wrong.

The timing changed. Nothing was fixed; the race is now usually won by the other side. It will come back on a slower connection, on a busier day, on somebody else’s phone.

An agent reporting success cannot reliably tell you which of the three occurred, because from inside the code all three look like the error stopping.

The tells

Read the fix diff for these shapes:

try { await save(booking) } catch (e) { console.error(e) }

The save can fail and the user still sees success. Catching is correct only when something is done about it: a message, a retry, a rollback.

const name = booking?.customer?.name ?? 'Guest'

Optional chaining is fine when a missing customer is allowed. It is a disguise when the customer should always exist, because now a broken booking renders as Guest forever instead of telling you something is wrong.

await new Promise(r => setTimeout(r, 500))

A delay inserted to make something work is not synchronisation. It is a bet on timing that you will lose in production.

// @ts-ignore

A type error silenced rather than resolved. Sometimes justified. Never without a comment saying why.

Two questions after any fix

Ask them in these words:

Which line caused the error, and which line prevents it now?

A real fix gives a specific answer to both. A vague answer (“there was a state issue and this handles it more robustly”) is a strong signal that nobody knows what happened, and you should not accept it.

If the underlying condition still occurred, what would the user see?

If the answer is “nothing”, the failure is now silent, which is worse than before. Errors that announce themselves are cheap. Errors that hide are the ones that reach a customer.

Prove it by making it fail

The strongest check available, and it takes a minute.

Undo the fix. Confirm the bug returns. Reapply. Confirm it goes.

If the bug does not return when you remove the fix, the fix was not what changed the behaviour; something else did, and you are about to ship a change nobody understands and keep a bug you think is gone. This happens more often than people expect, particularly after several rounds of patching in one session.

Then check the neighbours

A fix is a change, and a change can break something else. Before committing:

• Run the acceptance checks you wrote for this feature.
• Run the one adjacent feature that shares data with it.
• Re-run whatever test suite exists, and read what it says rather than the summary line.

The pattern to watch for is a fix that makes the failing case pass by weakening a rule everything else depended on. Loosening an overlap check to admit a booking that should have been allowed can admit three that should not.

Turn it into a permanent check

Every bug that took more than twenty minutes deserves a written test, or at minimum a line in your acceptance checks file. You now have the reproduction and the expected result (the two hard parts) and writing it down costs a minute.

Bugs recur. Generated code recurs particularly, because the next agent to touch that file has not read this conversation and will happily restore the original mistake. A test is the only thing in this course that argues with a model on your behalf while you are asleep.

Commit the fix on its own

One commit, one fix, a message naming the bug. Not bundled with three other changes.

When the same bug comes back in six weeks (and it will) git log for that file is a written record of what was tried and what it was supposed to do. That is the difference between fixing something twice and fixing it five times.