Reconstructing repro steps from vague reports
Turn a vague user report, session recording or log trail into candidate reproduction steps, then have an agent try them against a test environment to see whether the problem appears.
How it works
Many incoming reports say little more than "it broke when I tried to pay". The model combines the report with whatever evidence exists — the user's session events, server logs for that user and time, the release they were on — and proposes one or more step sequences that could have led there. Where possible an agent then runs each sequence against a test environment and checks whether the reported symptom appears, adjusting the steps when it doesn't. A confirmed sequence turns a report nobody could act on into one that a developer can reproduce in minutes.
When to use it
Customer-reported bugs with little detail; problems that support can see in logs but nobody can reproduce; and backlogs full of "cannot reproduce" reports worth another look.
Limitations
Many failures depend on data, timing or environment state that a test environment doesn't have, so a failed reproduction proves little. The model will produce plausible step sequences whether or not the evidence supports them, and an agent that reproduces a similar symptom may have found a different bug. Using real users' session data requires the right permissions and handling of personal data.
Watch for
The agent triggers a payment error with an expired test card and the report is marked reproduced, but fixing that leaves the user’s real failure in place. Compare the reproduced error and its log signature with the user’s own logs first.
What you still own
Confirming the reproduction matches the reported problem, and the decision to close a report as unreproducible.
Cite this
Qlarify Labs. (2026). Reconstructing repro steps from vague reports. Retrieved from https://labs.qlarify.fi/ai-in-testing/reconstructing-repro-steps