Turn a vague bug report into a failing test and then a fix

Turn 'it doesn't work' into a passing test suite in one session instead of three days of email tennis.

For anyone who fields bug reports from people who are not engineers · 8 steps · 7 min

How it works today.

A user writes in: 'The checkout button is broken on my end.' You ask what browser, what they clicked, whether they saw an error. They reply a day later with half the answers. You try to reproduce it on staging with your best guess at their setup, fail, ask more questions, wait another day. Eventually you discover they meant the button on the invoice page, not the cart, and only when their account has a expired payment method.

You write a fix based on what you think happened, deploy it, and ask them to try again. If it works, you never write a test because you're not certain what the original issue was. If it doesn't work, you're back to guessing. The bug may resurface in three months because nothing in your suite actually covers that path.

Before you start.

All of it has to be true, or step one fails in a way that is annoying to debug.

Access to your codebase repository and permission to create branches.
A runtime sandbox or staging environment where agents can execute code against your application.
Read access to your bug tracker or support inbox where reports arrive.
Your existing test framework's documentation or a sample test file the agent can reference.
Write access for the agent to create pull requests, or a workflow that lets it output a branch you review.

The steps.

01
Feed the raw bug report to an agent and ask for reproduction questions
Paste the user's message into a coding agent with context about your application. The agent generates a list of clarifying questions needed to reproduce the issue: browser, viewport size, account state, specific URL, steps taken, error messages seen. Review the list and send it to the user in one message instead of trickling questions over days.
Paste this
```
I received this bug report: [paste full report]. Our application is [brief description: e.g. a SaaS invoicing tool with Stripe integration]. List every piece of information you need to reproduce this issue locally. Format as a numbered list I can send to the user.
```
02
Once the user replies, have the agent write a reproduction script
Give the agent the user's answers and ask it to write a script that sets up the exact conditions they described: seed data for their account state, navigation steps, interactions. Run this script in your sandbox. If it does not trigger the bug, the agent may have misunderstood something; refine the script with the user's help before moving on.
Paste this
```
Here are the user's answers: [paste responses]. Write a reproduction script for [your test framework, e.g. Playwright, Cypress] that sets up an account in this state and performs these exact steps. Include assertions that would fail if the bug occurs.
```
Confirm the reproduction script fails in the way the user described
Execute the script in your sandbox and watch it fail. The failure message should match what the user reported: a missing button, a thrown error, incorrect data. If it passes or fails differently, you do not yet have the real bug. Go back to the user or adjust the script until the failure is consistent and matches their experience.
04
Ask the agent to identify the likely cause in the codebase
Point the agent at the failing test output and the relevant source files. It should trace the failure back to the code path that handles the user's scenario. The agent will suggest which file and function are responsible. Review its reasoning; if it points to the wrong layer, give it more context about your architecture.
Paste this
```
The test fails with this output: [paste error]. Our codebase structure is [brief overview: e.g. Rails MVC, React frontend]. Identify which file and method are likely causing this failure and explain why.
```
05
Have the agent propose a fix and explain the trade-offs
Ask the agent to write the code change that would make the test pass. It should also flag any side effects: does this change affect other features, does it require a migration, does it assume something about data shape that may not hold elsewhere. Read the explanation before looking at the diff.
Paste this
```
Write a fix for the issue you identified. Explain what the fix does, what assumptions it makes, and any other parts of the application that might be affected. Then provide the exact code change as a diff.
```
Apply the fix in a branch and run the new test plus your existing suite
Create a branch with the agent's fix and the new reproduction test. Run the full test suite in your sandbox. The new test should now pass, and no existing tests should break. If something else fails, the fix is too narrow or introduces a regression; ask the agent to revise it.
Review the diff and the test for clarity and maintainability
Read the code change as if a teammate wrote it. Does the test name describe the user's scenario? Does the fix handle edge cases or just the happy path? Does the test rely on hard-coded data that will break when your schema changes? Refine anything that will confuse someone in six months.
Merge the branch and close the loop with the user
Once the fix is deployed, reply to the user with a link to the test that now covers their case and a one-sentence explanation of what was wrong. This confirms you reproduced the exact issue they reported and that it will not reappear silently.

What you keep.

Automating the typing does not move the accountability. These stay with a person.

Deciding whether the agent's reproduction script actually matches the user's report before you call it done.
Reviewing the proposed fix for side effects the agent may not see: performance implications, data privacy, or changes to user-facing behavior.
Choosing when to merge, especially if the fix touches code paths that affect billing, authentication, or data integrity.
Closing the loop with the user so they know their report led to a concrete change and not a silent deploy.

Once it works.

The first run is the demo. These are where the time actually comes back.

Fire it from an event

Run the reproduction-question step automatically when a new ticket is tagged 'bug' in your tracker, so the user gets clarifying questions within minutes instead of the next business day.

Run it on a loop

After each deploy, run all bug-reproduction tests added in the past month against production to catch regressions before users report them a second time.

Scale it wider

When multiple users report similar symptoms in a short window, feed all reports to the agent at once and ask it to identify whether they share a root cause before writing separate tests.

Hand off to another agent

If the agent identifies a fix that requires a database migration or a third-party API change, have it create a draft pull request with a checklist of manual steps and tag a senior engineer instead of attempting the change itself.