The most frustrating software bug is one that disappears when someone else tries to investigate it. In AI software that problem is magnified by dependencies on model weights, data pipelines, libraries and hardware. A program that breaks on one accelerator may run on another; a faulty agent can depend on the exact tool response or memory state it saw. A newly released research collection treats the ability to reproduce these failures as the beginning of evidence, not an administrative detail.[1]
AIFaultBench, released as an arXiv preprint on 30 October by Mehil Shah, Mohammad Masudur Rahman and Foutse Khomh, collects 770 real-world software faults from 105 AI-related repositories maintained by 76 organisations. The team links each record to the original issue report, affected code version, setup instructions, reproduction trigger and investigation evidence. They report reproducing 652 failures—84.7% of their collection—while documenting unsuccessful attempts for the other 118.[1]
What is inside the collection
Deep-learning software supplies 307 faults, or 39.9% of the total. Large-language-model systems account for 151, agentic systems 130, conventional machine-learning software 118, reinforcement-learning systems 40, and tooling and infrastructure 24. These figures are a composition of the curated dataset, not a claim that deep learning is intrinsically more defective than agents or that 16.9% of real-world AI failures arise in agentic products.[1]
The authors trace public issue reports filed between July 2016 and July 2026. A report is more useful for future testing if the researcher can reconstruct the exact buggy revision and the conditions that produced the failure. Merely knowing that a repository later merged a fix is insufficient: configuration changes, missing model artifacts and external services can make the original symptom difficult to observe.[1]
The team reports approximately 1,640 person-hours spent on building the collection. That number is part of the story because a serious reproducibility benchmark is expensive to curate. An evaluation in which an automated repair agent succeeds on hand-selected, easily replayed defects says less about performance on messy deployed applications than an evaluation with recorded failures, failed reproductions and transparent selection criteria.[1]
AIFaultBench at a glance
| Category | Curated fault reports |
|---|---|
| Deep learning | 307Source 1 |
| Large language models | 151Source 1 |
| Agentic AI | 130Source 1 |
| Traditional machine learning | 118Source 1 |
| Reinforcement learning | 40Source 1 |
| Tooling and infrastructure | 24Source 1 |
| Reproduced under recorded conditions | 652 of 770 (84.7%)Source 1 |
Why the 118 failures to reproduce are valuable evidence
An unsuccessful reproduction attempt is not necessarily proof that the original bug report was incorrect. The environment may have become impossible to reconstruct, a network service may no longer be available or hardware differences may change a model’s execution. By retaining these outcomes, the authors make it possible for researchers to distinguish debugging limitations from the accuracy of a proposed fix.[1]
There is another reason to care about the remaining cases: evaluation pipelines are often tempted to quietly drop difficult examples. Removing unreproducible bugs from the denominator without documenting why may make a debugger look far more capable. A benchmark can support honest comparisons only when the selection and exclusion process is visible.[1]
The 118 unreproduced cases have a useful structure of their own. The authors say 46 depended on unavailable operating systems, builds, hardware, data, network services or credentials. Another 72 failed to exhibit the reported behaviour under the reconstructed conditions, potentially because of version drift or nondeterminism. Treating these categories separately prevents a false conclusion that the benchmark curators disproved the original reports. It also points to a reporting opportunity: dependence on an external model endpoint or a vanished package can make an AI application unusually hard to investigate years after a failure.[1]
What practitioners should take from it
An engineering team could use a record like this as a troubleshooting checklist: identify the exact release and commit, pin the dependency graph, save the triggering inputs, distinguish model/data faults from ordinary programming errors, and attempt a deterministic reproduction before judging a repair. It is a general workflow suggested by the artifacts; this publication did not run the benchmark or reproduce any faults independently.[1]
The authors explicitly caution that the collection favours active public Python-based repositories with enough historical issue information. Private production systems, obscure software and non-Python platforms are not represented in the same way. The dataset is a promising instrument for studying AI reliability precisely because its boundaries are visible. It is not a census of all AI software failures.[1]
Sources & further reading
- AIFaultBench: A Reproducible Benchmark of Real-World Faults in AI Software Systems Shah, Rahman and Khomh, arXiv · 30 Oct 2026 · Accessed 2 Nov 2026