Give the model a failing test, not a description of the bug

Most people describe the bug:

The date parser breaks on inputs from the EU region.

You’ll usually get back something plausible. Plausible is the problem — you now have to verify it yourself, which is the expensive part.

Instead, hand over a test that fails:

def test_parses_eu_format():
    assert parse_date("14/08/2026") == date(2026, 8, 14)
    # currently raises ValueError: month must be in 1..12

Three things change:

1. The spec is unambiguous. No round-trip clarifying what “breaks” means.
2. The model can check its own work by running the test, instead of reasoning about whether the fix probably works.
3. You get a regression guard for free — the artefact you’d have wanted anyway is now written before the fix, not bolted on after.

When you can’t write the test first

Ask for the test first, then approve it before any fix is attempted:

Write a failing test that reproduces this, and stop. Don’t fix it yet.

Reviewing a five-line test is much cheaper than reviewing a fix to code you haven’t read. If the test is wrong, you’ve caught the misunderstanding before it propagated into an implementation.