AI
New LLM System Automatically Improves Android Bug Reports with Missing Details
Researchers present BugScribe, an AI-powered tool that enhances incomplete mobile app bug reports by connecting user descriptions with app execution data to generate clearer reproduction steps and behavior details.
Mobile app developers often struggle with poorly documented bug reports. Users, testers, and developers typically submit defect descriptions that lack crucial context—vague descriptions of visual problems, missing reproduction steps, or unclear distinctions between expected and actual behavior. This gap between what gets reported and what developers need to diagnose issues is especially acute for UI-related defects, where the precise sequence of events is hard to capture in writing.
The Problem#
Mobile applications concentrate their defects on the visual layer of the screen, yet tools to automatically detect and log these issues remain limited. When people manually create bug reports, they often omit essential information: what the app actually did (Observed Behavior), what it should have done (Expected Behavior), and the exact sequence of actions to trigger the problem (Steps to Reproduce). This incompleteness forces developers to ask follow-up questions, slowing down fixes.
How BugScribe Works#
Researchers at arXiv have developed BugScribe, an LLM-powered system that bridges this gap by tethering user-written bug descriptions to real app execution traces. The approach uses a component-specific grounding strategy—meaning it tailors the context fed to the language model depending on which part of the bug report it's generating. Rather than treating all components equally, the system identifies the most relevant app UI information for each section, allowing the model to produce more accurate and detailed outputs.
Results and Impact#
Testing on 48 bug reports across 26 Android applications, BugScribe outperformed the original submissions and three baseline LLM approaches. The system achieved quality improvements of 44.1–82.3% for Steps to Reproduce and 3.8–35.2% for Observed and Expected Behavior descriptions. These gains suggest the technique could substantially reduce back-and-forth communication between developers and reporters, speeding up the debugging cycle in real-world apps.
