[Paper] Studying and Automating Issue Resolution for Software Quality

Source: arXiv - 2512.10238v1

Overview

This paper tackles one of the most painful parts of a developer’s day‑to‑day: turning noisy, incomplete bug reports into working fixes. By combining large language models (LLMs) with domain‑specific cues, the author not only surfaces why current issue‑tracking pipelines break down, but also delivers concrete tools that can automatically improve report quality, map real‑world developer workflows, and even suggest fixes for UI‑related bugs. The result is a roadmap for turning issue resolution into a more data‑driven, AI‑assisted process.

Key Contributions

• LLM‑enhanced issue report polishing: A technique that uses LLM reasoning together with project‑specific metadata (e.g., stack traces, component maps) to automatically rewrite low‑quality bug reports into clearer, more actionable tickets.
• Empirical workflow characterization: A large‑scale study of how developers handle issues in both classic (manual) and AI‑augmented environments, revealing bottlenecks, decision points, and the impact of AI suggestions on turnaround time.
• Automated UI‑bug localization: A machine‑learning pipeline that pinpoints the exact UI component responsible for a visual defect, reducing the “search‑and‑replace” effort developers usually spend.
• Solution identification via LLMs: A method that queries LLMs (with fine‑tuned prompts and retrieval of relevant code snippets) to propose concrete patches or configuration changes for reported bugs.
• Open‑source tooling suite: The author releases a set of scripts, models, and integration hooks for popular issue‑trackers (GitHub, Jira) that developers can plug into their CI/CD pipelines today.

Methodology

1. Data Collection: The study mined millions of issue reports from open‑source repositories, extracting both high‑quality (well‑described) and low‑quality (sparse) tickets.
2. LLM Prompt Engineering: Custom prompts were crafted to ask the model to “clarify,” “expand,” or “summarize” a report, while also feeding in auxiliary data such as file paths, recent commits, and component hierarchies.
3. Workflow Observation: Researchers instrumented development environments (IDE plugins, Git hooks) to log how developers interact with tickets, both with and without AI assistance.
4. UI Localization Model: A combination of static UI metadata (layout trees) and dynamic screenshots fed into a CNN‑based classifier that predicts the faulty widget.
5. Solution Generation: A retrieval‑augmented generation (RAG) pipeline fetched similar past bugs, fed them to an LLM, and post‑processed the output into a diff that could be reviewed automatically.
6. Evaluation: The team measured (a) improvement in report completeness (BLEU/ROUGE scores against human‑rewritten tickets), (b) reduction in mean time‑to‑resolution (MTTR), and (c) precision/recall of UI localization and suggested patches.

Results & Findings

Key takeaways: LLM‑assisted rewriting makes tickets far more actionable, AI‑augmented workflows cut resolution time by roughly a third, and the UI‑localization model correctly identifies the offending widget in most cases, enabling faster debugging. The patch suggestion engine, while not perfect, doubles the likelihood that a developer will accept an AI‑generated fix.

Practical Implications

• Faster triage: Teams can plug the report‑polishing service into their issue‑tracker webhook to automatically upgrade vague tickets before they hit the backlog.
• Reduced debugging overhead: UI teams can integrate the localization model into their testing pipelines; a failing visual test can instantly surface the suspect component.
• AI‑first code review: The solution‑identification pipeline can be added as a “suggested fix” comment on pull requests, giving reviewers a starting point and cutting review cycles.
• Metrics‑driven process improvement: By logging the AI‑augmented workflow data, managers can pinpoint where human hand‑offs still cause delays and invest in targeted training or tooling.
• Open‑source adoption: Since the author ships the tools under an MIT license, small teams can experiment without heavy vendor lock‑in, and larger enterprises can customize the models on proprietary data for higher accuracy.

Limitations & Future Work

• Domain specificity: The LLM prompting strategy relies on project‑specific metadata; applying it to completely new domains may need additional fine‑tuning.
• UI diversity: The localization model was trained primarily on web‑based frameworks (React, Angular); native mobile or desktop UI stacks showed lower precision.
• Human oversight still required: Suggested patches are not production‑ready; developers must review and test them, which limits the automation ceiling.
• Scalability of data collection: Instrumenting developer workflows at scale raises privacy and performance concerns that need careful handling.

Future directions include extending the UI‑localization pipeline to cross‑platform frameworks, exploring few‑shot prompting to reduce the need for extensive project metadata, and building a feedback loop where accepted AI fixes continuously fine‑tune the underlying models.

Authors

• Antu Saha

Paper Information

• arXiv ID: 2512.10238v1
• Categories: cs.SE
• Published: December 11, 2025
• PDF: Download PDF