When the assistant has written a function, don’t jump straight to the next task. Open a new conversation or set up a separate role: now it’s not the author but a picky reviewer.
Give it the code and ask it to find not “improvements” but scenarios where it will produce a wrong result: empty input, duplicates, race conditions, timeouts, partial API errors, unexpected data types.
You are a reviewer. Don’t rewrite the code. Find scenarios where it will break or return a wrong result. For each: input data, expected and actual behavior, severity of the problem.
This works because “write the code” mode pushes the model to confirm its own solution. “Find the failure” mode changes the goal: you get counterexamples, not yet another refactoring for the sake of refactoring.
Then I turn the scenarios it found into tests. A fix without a test is just hoping the same bug won’t come back.
You don’t need this for a ten-line one-off script, where the cost of a failure is lower than the time to check. But for integrations, payments, access rights and background jobs it almost always pays off.