Ask Claude 'What Would Break This?' Before You Ship

An adversarial review move: instead of asking Claude if the code is correct, ask it to actively try to break the code — enumerate the inputs, timings, and conditions under which it fails. You're recruiting the model as a red team, not a rubber stamp.

Asking 'is this correct?' invites confirmation — the model tends to agree. Asking 'what breaks this?' inverts the incentive and produces the empty-array, off-by-one, timezone, and concurrency cases that happy-path code forgets. Enumerating failure modes before you ship is far cheaper than discovering them from a production incident, and each one becomes a test.

Before merging anything that touches money, auth, data integrity, or user input; when writing a new function you'll depend on; and as the second pass after a checklist review.

Cosmetic or throwaway code where an exhaustive failure hunt is theatre. Match the paranoia to the blast radius.

Here is <function/endpoint>. Your job is to break it, not approve it.
List every input, sequence, or environmental condition under which it produces wrong output, throws, or corrupts state — ranked by how likely and how damaging. For the top three, give me a concrete failing input.
Then suggest the smallest guard for each.

<code>

For a date-range filter, Claude surfaces that a start date after the end date silently returns everything, that a timezone-naive comparison drops the last day for users east of UTC, and that a null end date throws — three real bugs the code's author never hit locally.

Turn the top failure modes straight into a parametrised test table and ask Claude to generate it, so the red-team pass leaves behind permanent coverage instead of a one-time conversation.

• Stopping at the list — the value is guarding or testing the cases, not reading them.
• Letting Claude invent exotic failures for code that never sees that input; keep it grounded in real usage.
• Not giving it the surrounding contract, so it flags 'issues' that callers already prevent.