AI Prompt to Turn a Bug Report Into a Test

A client messaged me last week with a bug report that said "sometimes the discount code doesn't apply, can you check?" That's it. No order ID, no browser, no steps. I used to spend the first twenty minutes of a report like that just trying to reproduce it before I could even start debugging — and most of that time wasn't spent fixing anything, it was spent guessing at what "sometimes" even meant.

An AI prompt to turn a bug report into a reproducible failing test fixes exactly that problem, and it's a different use of AI than most people reach for. Everyone talks about AI writing code or AI reviewing code. Fewer people use it for the unglamorous step that actually unblocks debugging: converting a vague human description into a concrete test case you can run, watch fail, and then fix with confidence that it's actually fixed.

The Real Problem With Vague Bug Reports

A bug report like "sometimes X doesn't work" is actually three separate problems disguised as one. There's the ambiguity of "sometimes" — is it a race condition, a specific input, a specific user role? There's the missing reproduction context — what data, what sequence of actions? And there's the fact that until you have a failing test, you can't prove your fix actually worked; you're just hoping the bug doesn't show up again.

Most developers skip straight to reading code and guessing. I think that's backwards. Writing the failing test first, even from an incomplete report, forces you to turn vague language into a precise claim about the system — and that precision is often where you spot the bug before you've even run anything.

Using AI to Generate the Reproduction, Not the Fix

Here's the prompt structure I use now whenever a bug report comes in without steps to reproduce:

Bug report (verbatim): [paste the exact words the reporter used]

Relevant code:
[the function or endpoint most likely responsible]

Known facts:
[anything concrete you do have — a timestamp, an order ID, a user role]

Task: Based on this, write the most likely test case that would make
this bug visible. Use our existing test framework conventions. Don't
fix the code yet — just write a test that should fail given the
described behavior, and explain your assumption about what triggers it.

The "don't fix the code yet" instruction is the part people skip, and it's the part that matters most. If you ask AI to fix the bug directly from a vague report, it'll produce a plausible-looking patch based on a guess about the cause — and you'll have no way to verify the guess was right. Asking for a failing test first gives you something falsifiable: either the test actually fails for the reason you expect, or it doesn't, and either outcome teaches you something real.

Walking Through the Discount Code Bug

Back to that client's checkout issue. The only concrete fact in the report was "sometimes." I fed the AI the checkout controller, the discount validation function, and that one word. It noticed the discount check ran against cart.subtotal calculated before a quantity-based promo was applied, but the actual charge happened after — and proposed this test to confirm it:

test('discount applies when quantity promo changes subtotal after validation', async () => {
  const cart = buildCart([
    { sku: 'ABC', price: 20, qty: 3 }, // triggers buy-2-get-1 promo
  ]);

  const subtotalAtValidation = calculateSubtotal(cart); // before promo
  const discountResult = validateDiscount('SAVE10', subtotalAtValidation);

  applyQuantityPromos(cart); // promo recalculates subtotal after validation
  const finalCharge = calculateCharge(cart, discountResult);

  expect(discountResult.valid).toBe(true);
  expect(finalCharge).toBeLessThan(subtotalAtValidation);
});

That test failed immediately, and failed for exactly the reason the AI predicted: the discount validated against a subtotal that hadn't accounted for the quantity promo yet, so on carts where the promo kicked in, the discount check and the final charge disagreed and the discount silently got dropped. "Sometimes" turned out to mean "whenever a quantity promo and a discount code land on the same cart" — a precise, testable condition instead of a vague complaint.

Why I Don't Trust an AI-Generated Fix Without This Step First

I'll say this plainly because it goes against a lot of the "just let AI fix it" advice floating around: I don't accept an AI-proposed fix for a bug I can't already reproduce on demand. A fix that happens to make the reported symptom go away isn't the same as a fix that addresses the actual defect, and without a failing test you genuinely can't tell the difference. I've seen AI-suggested patches that silently papered over a symptom — adding a null check instead of fixing why the value was null in the first place — and they look identical to a real fix until the underlying issue resurfaces somewhere else three weeks later.

The failing test is what separates those two outcomes. Once I have it, I'm comfortable letting AI draft the actual fix, because now there's a concrete, automatic way to check whether the fix is real: the test flips from red to green, and stays green on every future change, not just this one.

Make the Habit Stick

The prompt structure above works best when the bug report is thin, which is most of them in real client work — people report symptoms, not root causes, because that's all they can see. Save a version of this template somewhere your team will actually reach for it under deadline pressure, and get in the habit of pasting the exact wording of the report rather than paraphrasing it yourself; the AI often picks up on a specific word choice, like "sometimes" or "randomly," that hints at the actual trigger before you've consciously noticed it. The test you get out of this isn't just a debugging shortcut — it's the permanent, automated proof that whatever you ship next actually closes the gap between what the user reported and what the code does.