For about a year our team had a recurring ghost: a date-rollover bug in a billing function that we 'fixed' three separate times. Each fix made the symptom go away in manual testing and then quietly came back the next time the clock did something inconvenient. The third time it resurfaced — on the 1st of a month, naturally, during invoicing, while a customer was watching — I finally admitted the obvious thing I'd been avoiding. We never actually proved we'd reproduced it. We patched the line that looked guilty, ran the app once by hand, saw the right number, and called it a day. Three times. We were fixing our guess about the bug and then celebrating when the guess stopped complaining.
The reason we kept doing this is that writing a reproduction by hand is genuinely fiddly. You have to mock the clock, pick the exact cursed date, set up the fixture, and get the assertion right — and at 5pm with a customer waiting, 'it works when I click it' is a very seductive substitute for all that.
Reversing the order
The fix wasn't more willpower from me at 5pm; it was making the right thing cheap enough that I'd actually do it. I started every bug with the Write a Failing Test That Reproduces This Bug Before I Fix It prompt. I described the rollover bug, pasted the function, set the framework to 'Jest / TypeScript', and noted observed-vs-expected: 'on the last day of February, billing_period_end lands in January, expected March 1.' GPT 5.2 came back with one test — not a suite, one surgical test — that pinned the clock to 2025-02-28 with fake timers, called the function, and asserted the period end. It failed for exactly the reason I'd described, and it printed the line I now consider the whole point: 'This fails because: billing_period_end asserts 2025-03-01 but receives 2025-01-31.'
That one red test was worth more than all three previous green deploys combined, because for the first time I had proof I was looking at the actual bug. I fixed the off-by-one in the month arithmetic — we were adding a month by setting the month field, which wraps weirdly on the 31st — the test went green, and the bug has not been back since. I can say 'has not been back' with real confidence because the reproduction is sitting in CI, ready to scream the instant anyone reintroduces it.
Why GPT 5.2 and why exactly one test
I deliberately wrote this prompt in the numbered-system-rule style — 'RULE 1: produce exactly ONE failing test', 'RULE 2: it must fail today' — because GPT 5.2 follows an explicit do-this-not-that list with almost legalistic literalness. If you tell it 'one test, must be red against current code,' it gives you one red test, full stop. A vaguer model or a vaguer prompt tends to hand you a whole speculative suite, half of which passes, and now you're auditing the AI's test suite instead of fixing your bug. The 'This fails because' output line is the secret sauce: it forces the model to name the exact assertion that trips, which is how I verify in two seconds that it reproduced MY bug and not some adjacent one it found interesting.
- It used fake timers instead of a real sleep, so the test runs in single-digit milliseconds and never flakes on a slow CI box
- When I once handed it a bug that depended on unseeded randomness, it refused to pretend it could pin it and instead showed me how to inject a seed so the failure became deterministic
- It asked me one clarifying question when it genuinely couldn't tell the function's return shape, instead of inventing a field that didn't exist and writing a confidently wrong test against it
- It mocked the currency dependency at the function boundary, not three layers deep, so the test stayed readable
The honest caveat
It is only ever as good as your observed-vs-expected. The very first time I tried it I was lazy and wrote 'dates are wrong sometimes,' and it correctly refused to play along — it asked me to give it a concrete case, which felt annoying for about four seconds until I realized it was right and I was the problem. A reproduction needs a specific input and a specific expected output; if you can't state those, you don't understand the bug well enough to fix it yet, and the prompt politely forces that reckoning. Garbage in, courteous request for less garbage out.
This is now literally step one of every bug ticket on our board, enforced before anyone is allowed to touch the fix. The cultural shift was bigger than the tooling: 'show me the red test' became a normal thing to say in standup, and our reopened-bug rate dropped to nearly nothing. Grab the Write a Failing Test That Reproduces This Bug Before I Fix It prompt on Prompt Dock and run it on the next bug you're tempted to patch on a hunch — and when a confusing stack trace is what's blocking you in the first place, pair it with my Explain a Stack Trace and Give Me the Minimal Safe Fix prompt to find the cause before you write the reproduction.