To turn bug reports into reproduction steps with AI, give the model a sanitized evidence bundle, make it separate reported facts from assumptions, and ask for a numbered procedure with environment, prerequisites, minimal data, expected results, actual results, observation points, and explicit unknowns. Then have a person run the steps in a controlled environment. The AI can organize a reproducibility candidate; it cannot truthfully say the bug was reproduced.

This is a narrow documentation workflow. The broader guide to using AI explains input boundaries and human approval. Once a person can reproduce the failure, the separate AI debugging workflow can investigate causes and fixes. Do not collapse those stages: a plausible cause is not a reproduction step, and a polished procedure is not evidence that anyone ran it.

Key Takeaways

Preserve the reporter's evidence before rewriting it.

Label every statement as reported, observed, inferred, or unknown.

Make environment, state, data, and timing explicit.

Prefer a minimal test case over a long narrative.

Record expected and actual results at the same observation point.

Let a human execute, revise, and approve the final reproduction package.

What belongs in a safe bug report evidence bundle?

A useful bug report may contain a title, prose description, form fields, comments, logs, screenshots, a video, or a test failure. Collect those artifacts without silently rewriting them. GitHub treats an issue as a place to capture work and supports structured issue forms; form fields can require details such as reproduction steps, expected behavior, and logs.［1］［2］ Structure improves intake, but it does not prove that every field is accurate.

Before using an AI tool, remove or replace secrets, access tokens, session cookies, private keys, personal details, customer identifiers, private source code, internal hostnames, and confidential logs. Follow the approved data-handling policy for your organization. If an artifact cannot be shared with the selected tool, summarize only the necessary facts locally or use an approved private environment. Keep a reference to the original artifact so a reviewer can compare the transformation.

Create a small intake ledger:

Field	What to record
Report ID	Stable issue or ticket identifier
Reporter statement	Exact claim or short quoted fragment
Artifact	Approved log, image, video timestamp, or test output
Source time	When the event and artifact were produced
Environment	Product, version, platform, browser or runtime
Confidence	Reported, directly observed, inferred, or unknown
Sensitive data	Removed, replaced, restricted, or not present

Do not paste a whole repository or production log merely because it is available. Reproduction normally needs a small set of discriminating facts, not the largest possible context window.

How do you extract facts without filling gaps?

Ask AI to extract statements into four columns: reported fact, direct evidence, candidate inference, and unknown. This prevents grammar improvements from turning uncertainty into certainty. For example, “the page froze after I clicked Save” is a reporter statement. A video showing the click and frozen state is direct evidence. “A database lock caused it” is a hypothesis unless separate evidence establishes it.

Use a prompt such as:

You are organizing a bug report, not diagnosing it.

For each statement, classify it as:
1. reported by the user;
2. directly supported by an attached artifact;
3. an inference that must not be stated as fact; or
4. unknown or contradictory.

Do not invent actions, values, versions, timings, account state, network
conditions, causes, or successful reproduction. Quote the evidence ID for
every fact. Return questions for every required field that is missing.

Review the extraction against the original. Remove facts that cannot be traced to an artifact or statement. A contradiction—such as two different app versions—belongs in the unknowns list, not in a synthesized average.

Define the environment and starting state

Reproduction fails when hidden state differs. Record the smallest environment description that can change the outcome:

build, release, commit, or API version;
operating system, browser, runtime, or device class when relevant;
account role, feature flag, locale, time zone, and permissions;
network mode or external dependency state only when evidenced;
data fixture, cache state, prior workflow state, and installation history;
whether the test begins from a fresh session, known snapshot, or existing state.

Do not turn “latest version” into a version number. Ask the reporter to retrieve the actual value. Do not infer a browser from a screenshot frame, an account role from a username, or a network problem from a timeout. If a field is unavailable, say unknown and explain how a tester can obtain it.

Write prerequisites as assertions that can be checked before step 1. “A project named Sample exists and the tester has Editor access” is better than “open your project.” When state is expensive to recreate, reference a sanitized fixture or setup procedure rather than embedding confidential data.

How do you turn bug reports into reproduction steps with AI as atomic actions?

Each reproduction step should describe one user or system action and, where useful, one observation. Avoid vague verbs such as “configure normally,” “try again,” or “use the feature.” Name the control, command, field, value, or event from the evidence. Keep the order reported; changing the order can remove the bug.

A good sequence looks like this:

verify the stated starting state;
perform one precise action;
record an intermediate observation when it distinguishes branches;
perform the next action;
compare expected and actual results at one named observation point;
capture the approved evidence needed for another run.

Timing and repetition belong in a step only when supported. If the reporter says the problem occurs “sometimes,” do not translate that to “every third attempt.” Instead, define a bounded run plan, such as ten attempts, and leave the observed frequency empty until a tester runs it.

Where should expected and actual results come from?

Expected behavior should come from an approved requirement, specification, test, help page, or product owner—not from what seems intuitive to the model. Actual behavior should describe what the evidence shows without assigning a cause.

Use the same observation point for both:

Observation point	Expected	Actual	Evidence
After selecting Save	Confirmation appears and status becomes Saved	Spinner remains visible for at least the recorded video segment	Video E2, 00:18–00:31

If the expected behavior has no authoritative source, label it reporter expectation and request confirmation. If the actual result varies, record each observed variant rather than selecting the most dramatic one.

What makes a test case minimal?

MDN recommends a minimal standalone test case when reporting browser problems because removing unrelated code makes the defect easier to isolate and share.［3］ Minimal does not mean artificial; it means every remaining input is necessary to trigger the observed result.

Use AI to propose a reduction queue, not to declare reductions successful:

replace production records with synthetic fixtures;
remove unrelated fields, plugins, extensions, or requests one at a time;
reduce the action sequence while preserving order;
isolate one account role, locale, or configuration;
convert a long script into the smallest approved snippet;
retain a control case where the failure is not expected.

A person must run each reduction. Mark it retained, removed, or not tested, and save the observed result. Never publish a minimal case containing a live credential, private endpoint, real customer record, or exploit detail that should remain restricted.

Add observation points and a run matrix

A procedure becomes easier to debug later when it identifies what to observe without prescribing a cause. Useful observation points include a visible state transition, status code, safe log event, queue count, database fixture state, or test assertion. Only include signals the tester is authorized to access.

Create a small matrix when evidence suggests an environmental boundary:

Variable	Control	Candidate variant	Result
Release	Previous approved build	Reported build	Not run
Role	Viewer	Editor	Not run
Fixture	Empty synthetic record	Minimal populated record	Not run

The AI may suggest discriminating comparisons, but the initial result must remain Not run. Avoid an uncontrolled matrix containing every browser, region, account, and device. Start with the variables supported by evidence, then expand only when results justify it.

How should unknowns and reproduction confidence be recorded?

Mozilla's bug-writing guidance emphasizes clear steps, actual results, and expected results.［4］ Add two fields that are especially useful when AI helps: an unknowns register and a confidence label.

Use confidence definitions that describe evidence, not model certainty:

Draft: organized from one report; no independent run.
Candidate: fields are complete enough for a controlled run.
Observed once: one authorized tester reproduced the stated result once.
Repeatable: the result met a predefined run threshold in a recorded environment.
Not reproduced: the planned run completed without the reported result.
Blocked: required environment, data, permission, or artifact is unavailable.

Do not let AI assign Observed once or Repeatable. Those states require recorded human or automated execution evidence. A high language-model confidence score is irrelevant.

Use a copyable bug reproduction package

# Reproduction package

- Report ID:
- Scope:
- Environment and exact versions:
- Starting state:
- Approved synthetic fixture:
- Prerequisites:
- Known unknowns or contradictions:

## Steps
1. [Action]
   - Observe:
2. [Action]
   - Observe:

## Results
- Observation point:
- Expected result and authority:
- Actual reported result and evidence:
- Reproduction status: Draft
- Run count / threshold:

## Evidence
- Artifact ID, timestamp, and sanitized location:

## Handoff
- Tester:
- Environment owner:
- Next decision:
- Human approval:

Ask the model to populate only fields supported by the evidence ledger. Require the output to preserve empty fields and list citations by evidence ID. Then compare every populated field with the source.

Run and approve the package

Execute the candidate in a safe, authorized environment. Capture exact versions, timestamps, fixture identity, step deviations, and approved observations. If the tester must improvise, update the procedure and run it again from the defined starting state. Do not quietly edit steps after a successful run; that destroys the audit trail.

The reproduction package exits this workflow when a named reviewer confirms that it is either repeatable under a defined threshold, not reproduced under a defined test, or blocked for a specific reason. Root-cause hypotheses, patches, and regression tests belong to the next workflow. For help checking generated claims, use the AI fact-checking method; for test design after scope is stable, use the AI test-generation guide.

FAQ

Can AI reproduce a bug for me?

It can organize evidence and draft a procedure. It can only execute a test when connected to an authorized environment and toolchain, and even then the recorded run—not the prose—establishes the result.

What if the original report is incomplete?

Keep missing fields as unknowns and generate targeted questions. Do not invent a version, action, account state, or expected result to make the template look complete.

Should I include screenshots or a video?

Use them when approved and useful, but add timestamps and a text description. Remove personal or confidential information, and do not treat visual context as proof of hidden state.

How many reproduction attempts are enough?

Define a threshold based on impact, cost, and expected intermittency before testing. Record all attempts and the environment; there is no universal number.

What is the difference between reproduction and diagnosis?

Reproduction establishes a repeatable observed result under known conditions. Diagnosis evaluates hypotheses about why it occurs. Keep those claims and approvals separate.

Can AI create a minimal test case?

It can suggest reductions and synthetic fixtures. A person or authorized test system must run each reduction and confirm that the failure remains.

How should I handle sensitive logs?

Use approved storage and tooling, minimize the excerpt, redact secrets and personal data, and preserve a restricted reference to the original when policy allows.

When should the report move to debugging?

Move it when the reproduction outcome, environment, evidence, and unknowns are explicit enough for an investigator to evaluate hypotheses without rewriting history.

Sources

Sources checked 29 August 2026.

GitHub Docs, “Quickstart for GitHub Issues” — https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/quickstart
GitHub Docs, “Syntax for GitHub's form schema” — https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema
MDN Web Docs, “How to file a bug” — https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/File_browser_bugs
Mozilla Bugzilla, “Bug Writing Guidelines” — https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html

How to Turn Bug Reports into Reproduction Steps with AI