To write a bug report with AI, give it an ordered record of what you did and what appeared on screen. Ask it to organize that evidence into a clear report, while leaving unknown details and possible causes separate.
This guide uses an original, fictional task-app example. The notes and report are editorial illustrations, not observations from a live product test. No real application is being accused of the behavior described below.
1. Start with observations, not a diagnosis
Imagine you recorded the following notes after changing a task’s due date:
N1. I used a task web app on Windows 11. I did not record the browser name, browser version, or app build. N2. I opened the existing task named Example task. Its due date displayed October 20, 2026. N3. I changed the due date to October 22, 2026, and selected Save. N4. A Saved message appeared, and the task displayed October 22, 2026. N5. I reloaded the page. The task then displayed October 20, 2026. N6. I performed this sequence once. I did not test another task or browser. N7. I did not capture a screenshot, recording, or log. N8. I expected the saved date to remain October 22, 2026, after reload.
These notes support a report about the displayed date reverting. They do not show whether the cause is a failed write, stale display, another edit, or something else. Avoid putting an untested diagnosis into the title.
Mozilla’s bug-writing guidelines emphasize precise reproduction steps and separate expected and actual results. That structure is useful beyond Mozilla products, although each project may require its own fields.
2. Ask AI to preserve unknowns
Turn the notes below into a concise bug report. Use only facts stated in the notes. Include: - A specific title describing the observed behavior - Known environment details - Preconditions - Numbered steps performed - Expected result - Actual result - Observed frequency - Evidence available - Missing information to collect Keep dates, interface labels, and the order of actions unchanged. Do not invent version numbers, error codes, attachments, or tests. Do not claim a root cause or assign severity without evidence. If a detail is missing, write Not recorded or Not tested as appropriate. List follow-up suggestions separately from completed actions. NOTES: [Paste the observation notes here.]
The wording “steps performed” matters when you have observed the sequence only once. The report can help someone attempt reproduction without promising that the outcome occurs every time.
3. Review the resulting report against the notes
An editorial report based on N1–N8 could read:
Title: Task due date returns to October 20 after saving October 22 and reloading Environment: - Task web app on Windows 11 - Browser name and version: Not recorded - App build: Not recorded Precondition: An existing task named Example task displays a due date of October 20, 2026. Steps performed: 1. Open Example task. 2. Change its due date to October 22, 2026. 3. Select Save. 4. Observe the Saved message and the displayed date of October 22, 2026. 5. Reload the page. Expected result: The due date remains October 22, 2026, after reload. Actual result: The task displays October 20, 2026, after reload. Observed frequency: Observed once in one attempt. Other tasks and browsers were not tested. Evidence available: Written notes only. No screenshot, recording, or log was captured. Missing information: Browser name and version, app build, and whether the same sequence reproduces on a practice task.
Every substantive statement should map back to a note. The title and actual result follow N5; the temporary Saved message follows N4; the frequency follows N6. The expected result is the reporter’s stated expectation in N8, not a claim that product documentation guarantees this behavior.
Notice that the report says the task displays the old date. It does not say the database lost the change. That distinction gives support staff the observed symptom without preselecting a cause.
4. Remove plausible details that were never observed
- “The latest browser version” is unsupported when the browser version was not recorded. Replace it with the missing-information entry.
- “The issue happens every time” is unsupported by one attempt. Keep the actual observation count.
- “Screenshot attached” is incorrect when no screenshot was captured. State which evidence is genuinely available.
- “The server rejected the save” is a diagnosis absent from the notes. Remove it or label it as an untested hypothesis outside the factual report.
- “All tasks are affected” extends a single-task observation to an untested population. Keep the scope to Example task.
AI can make a rough report sound complete by supplying conventional details. Review the polished version for those additions instead of checking grammar alone. Our document-comparison guide offers a related way to inspect what changed between source notes and a rewritten version.
5. Collect the next useful detail
The missing-information list should guide a small follow-up, not become a record of tests that supposedly happened. Record the browser and app version from the actual environment. If you can safely repeat the sequence on disposable sample data, record each attempt and its outcome.
For example, if you later make two more attempts and observe the old date returning in only one, the combined record is two occurrences in three attempts. Preserve the outcome of the unsuccessful reproduction too. Do not replace it with “always” because the initial report was convincing.
Keep conditions visible when comparing attempts: which task, which environment, and which steps changed? If you change the browser and the task at the same time, a different result does not tell you which change mattered. Choose the next check based on the support team’s needs and the effect on your data.
If you capture evidence later, label it with the relevant attempt. Review screenshots and logs for unrelated personal data, credentials, or account details before sharing them. Do not add a placeholder attachment name to the report and leave readers to assume the file exists.
6. Prepare a focused report for the right channel
Check the product’s reporting instructions and existing issue list before submission. Keep the title specific enough to search for similar reports. A matching symptom can be useful context, but it does not prove two reports have the same cause.
Use one report for this observed date behavior, and place unrelated requests in separate entries. If you are working from many comments rather than one reproducible sequence, our customer-feedback classification guide can help group them before deciding which needs a detailed report.
Before sending, confirm that the dates, labels, steps, frequency, and attachment list match the record you actually have. AI’s useful role is to make that record easier to follow. The report should leave the next reader able to investigate the problem without first removing invented facts.
Ready to investigate the code behind a reported issue? Our AI selection guide for developers compares editor and terminal workflows and shows how to review a small boundary-condition fix.