Use AI to reproduce a bug before asking it to fix anything

“Search sometimes shows the wrong customer” is enough to start an investigation but not enough to choose a fix. An assistant might add debouncing, clear state, or rewrite the API client. Any of those changes could hide the symptom temporarily while leaving the cause intact.

In an illustrative customer search page, typing one name and then another produces requests that finish out of order. The slower first response replaces the newer result. The investigation should establish that sequence before changing code. A reproduction is the bridge between a report and evidence that a correction works.

Convert the report into an observable sequence

Capture the starting state, actions, and visible outcome. “Open customer search, enter Ana, replace it with Ravi before the first response returns, and observe Ana's results under the Ravi query” is precise enough to investigate. Include browser, page, account role, and approximate network conditions where relevant.

Separate observations from interpretations. “The response for Ana arrived last” is an observation if supported by a trace. “React caches the wrong state” is a theory. Keeping those distinct prevents the assistant from treating a reporter's guess as a technical fact.

Use synthetic customer records in shared evidence. Preserve the distinguishing features needed to detect the problem: two queries, two result sets, and different completion times. Real customer names and tokens are unnecessary. A useful reproduction demonstrates the behavior without copying production data.

Establish whether the failure is local or remote

Inspect the request and response for each query. If the server returns Ravi's records for the Ana request, investigate the backend. If both responses are correct and the screen displays the older set, investigate client state and ordering. This distinction eliminates a large amount of speculative work.

Check whether the request parameters match the current input. A stale closure can send the wrong query before any response race occurs. Record query text, request identity, and response identity so you can distinguish incorrect submission from incorrect rendering.

Do not add diagnostic logs containing complete customer payloads. Query labels or generated identifiers are usually enough. If logging changes timing and makes the bug disappear, use controlled delays or browser tooling to reproduce the order without relying on extensive application instrumentation.

Make timing controllable

An intermittent race becomes easier to test when you control completion order. In a unit or integration test, create two deferred responses. Start the first search, start the second search, resolve the second response, then resolve the first. Assert that the second query's results remain visible.

This approach tests the relevant ordering directly. A test with a random timeout may pass hundreds of times and still miss the race. Browser network throttling can help demonstrate the symptom manually, but a deterministic double is often better for the regression test.

State what the double does not prove. It establishes client behavior under a chosen response order, not that a particular provider regularly produces that order. If the bug depends on actual server caching or authentication, a separate integration reproduction is needed. Use the smallest reproduction that includes the suspected boundary.

Ask the assistant to explain the failing case

Give the assistant the report, relevant handler or effect, and the controlled reproduction. Ask it to trace the state transitions without editing first. Require it to identify which response is allowed to update which state and where that condition is currently absent.

An illustrative prompt is: “The second request resolves first and the first request resolves last. Explain which state writes occur and why the final screen is wrong. Cite the function that commits results. Propose a minimal correction and a test that fails before it.” This is a bounded reasoning task with observable evidence.

If the assistant proposes debouncing, ask whether it prevents the stated execution order. It may reduce request frequency while leaving overlapping requests possible. A correction must address the demonstrated failure, not merely make it less likely under typical typing speed.

Implement the narrow correction

For the illustrative client race, an identity or generation check can prevent obsolete results from committing. Cancellation may also reduce unnecessary work, but the result-ownership rule is the core guarantee. Apply the same rule to errors and pending state so an old failure cannot overwrite current success.

Avoid combining the correction with unrelated changes to styling, API envelopes, or state libraries. A small diff makes it easier to connect cause and outcome. If the existing architecture prevents a clean ownership check, explain that constraint before introducing a broader state machine.

Keep the request lifecycle coherent. Starting a new search should define what happens to old results, the loading indicator, and errors. An empty query needs an explicit behavior. The related article on response ordering develops this client pattern more fully.

Prove the reproduction changes

Run the exact failing sequence against the corrected implementation. The final result must remain associated with the newer query even when the older request completes last. Test the inverse order as well so the correction does not discard legitimate current results.

Add a rejection case: the older request fails after the newer one succeeds. The current screen should not switch to an unrelated error. Add a pending-state case: finishing an obsolete request should not clear the active request's loading indicator. These cases expose incomplete fixes that protect only successful data writes.

When feasible, run the regression test against the earlier implementation and confirm it fails for the expected reason. If it passes before the fix, inspect the test setup and assertions. A test that never actually overlaps requests cannot demonstrate that an overlap bug was corrected.

Preserve the useful evidence

Save the reproduction steps, synthetic fixture, and regression test with the change. The original report may contain noise, but the controlled sequence is reusable knowledge. Future refactoring should retain the invariant that only the current request can own current search state.

Do not generalize one reproduction into a claim that every search bug is a race. Wrong filters, stale caches, permission errors, and incorrect rendering can produce similar symptoms. The reproduction justifies this correction for this execution path.

If the bug cannot yet be reproduced, report that honestly and continue narrowing conditions. An assistant can generate hypotheses and investigation steps, but a confident patch without a failing case remains difficult to validate. The practical outcome is an explanation tied to evidence and a correction that changes that evidence.

Sources

GitHub Copilot best practices covers specific prompts and validation.

MDN: AbortController documents browser cancellation primitives.