How to share a reproducible AI bug
A compact report that lets another person investigate the same failure without needing your private data or your whole project.
When you ask another builder for help, give them a small failure they can inspect. A screenshot of a strange answer is a useful clue, but it rarely contains the input, configuration and expected behavior needed to investigate. This is a proposed working format for AI Krakow readers, not a recap of a community event.
Start with one sentence about the task and one about the failure. For a fictional example: a note-taking prototype turns an unconfirmed meeting proposal into a confirmed appointment. The expected behavior is to preserve the uncertainty. That description gives the reviewer something more precise than “the model hallucinates”.
Keep the smallest authorized input that still demonstrates the problem. Replace private names and details, then run the changed example again. Redaction can accidentally remove the ambiguity that caused the failure. If you cannot create a shareable reproduction, describe that limit and keep the investigation in an approved private setting.
Record the instruction, model identifier, relevant settings, application revision and time of the attempt. Include the actual output and the expected facts or constraints. If a tool or retrieval step supplied context, preserve the shareable portion of that context too. A different source document can change the experiment.
Try the same input more than once and report what happened on each attempt. “Failed in two of three recorded attempts” describes those observations. It does not establish a general failure rate. Keep successful attempts when they help explain the difference instead of selecting only the most dramatic output.
Our proposed report has seven fields: task, minimal input, configuration, steps, expected behavior, observed behavior and remaining uncertainty. Add a safe command or short sequence another person can follow. Explain any required account or paid call before asking them to run it.
GitHub issues can track bugs and link related discussions, as its official documentation explains. Use the project’s existing tracker if appropriate, check for an existing report and follow its contribution instructions. A public issue is not a suitable place for credentials or customer documents.
End the conversation by agreeing on one next experiment and its owner. Keep the original report intact and attach the new observation. If you find a broadly useful, shareable pattern, the site’s contact section is a place to suggest a future note. Source checked September 20, 2026.