Publications

Agentic AI systems have rapidly expanded across domains through autonomous reasoning, tool use, and task execution capabilities. As organizations increasingly deploy these systems in production, the software engineering (SE) practices behind their development and maintenance become valuable knowledge for industry practitioners, researchers, and educators. However, this knowledge remains scattered across engineering blogs, technical documentation, repositories, and practitioner reports, making it difficult to understand how teams engineer agentic systems in practice. To address this gap, we present the SE AI Agent Index, a structured dataset documenting software engineering practices for 13 industrial AI agents across seven dimensions, including software methodologies, testing, code review, CI/CD, issue resolution, communication, and documentation. The dataset contains 608 information items extracted from publicly available sources and organized into practices, tools, stakeholders, and other relevant information. We constructed the dataset using a semi-automated methodology that combines LLM-assisted information extraction, manual synthesis and refinement, and independent validation to ensure that all indexed information is traceable to verifiable evidence. To demonstrate its utility, we present usage scenarios showing how the dataset can support industry practitioners, researchers, and educators in understanding and studying the engineering of modern AI agents.

AI coding agents are increasingly used to fix bugs from issue reports, making the bug report the agent’s task specification. Recent studies found that agents benefit most from code-level information, such as fix locations, while traditional report components, such as the steps to reproduce, contribute little. However, these studies focus on developer-written issues for libraries and frameworks. UI-centric bugs present a different setting: their failures are experienced through the GUI, while end-user reports typically describe what users see and do rather than where the fault lies in the code. It is therefore unclear which report information helps agents repair UI-centric bugs.

In this paper, we present the first controlled empirical study of how bug report information affects AI coding agents repairing UI-centric Android bugs. We extend 50 real bugs from 23 open-source Android apps with structured reports and GUI information for their causing and manifesting screens, including screen and component descriptions, screenshots, and UI hierarchies. We derive 17 report configurations that remove traditional report components, add GUI information, or provide code localization. We run Codex, Claude, and Qwen three times on every bug and configuration, resulting in 7,650 repair attempts. We analyze repair success with mixed-effects logistic regression and agent trajectories to measure repair behavior and effort.

Our results show that report information matters, but its effects depend on the information and the agent. S2Rs have positive estimated effects for all three agents, while the OB is particularly important for Codex and the expected behavior adds little. Original user reports outperform structured reports, while UI hierarchies have the strongest positive estimated effect among GUI information. Code localization substantially increases the estimated odds of success for Claude, but not consistently across agents. Report information also changes repair effort and behavior, sometimes substantially, even when its effect on final success is limited. These findings show that useful report information for UI bug repair differs from what prior work found for library and framework bugs and that no single report configuration benefits all coding agents.

Mobile app developers rely on end-user bug reports to fix defects. However, these reports are often incomplete or ambiguous, making defects difficult to reproduce and resolve, increasing maintenance costs. We developed BURT++, an AI-powered interactive bug- reporting system that guides users through natural-language conversation. It identifies missing information, asks follow-up questions, and grounds responses in application information. By transforming informal descriptions into structured, developer-ready bug reports, BURT++ helps developers resolve defects more efficiently, improving software reliability. This enables users to benefit from more dependable software in their daily lives.

Most defects in mobile applications are visually observable on the device screen. Since automated mechanisms for detecting and reporting such defects are often unavailable, users, testers, and developers must manually submit bug reports. However, these reports are frequently incomplete, ambiguous, or inaccurate, often lacking the information needed to understand, reproduce, and diagnose defects. This challenge is particularly prominent for UI-centric defects, where the relevant application behavior is difficult for end users to describe precisely. We formulate automatic bug report enhancement as the problem of connecting user-written bug reports with application execution. We present BugScribe, an LLM-powered approach that links bug report information with app-specific UI execution information to infer and generate accurate, complete, and correct Observed Behavior (OB), Expected Behavior (EB), and Steps to Reproduce (S2Rs). BugScribe employs a component-specific grounding strategy that provides the most relevant context to an LLM for generating each bug report component. To support BugScribe's design and evaluation, we develop a bug report quality model and use it to identify the most effective context for each component. We evaluate BugScribe on 48 bug reports from 26 Android applications with manually constructed ground truth. Our results show that BugScribe generates higher-quality bug report components than the original reports and three LLM-based baselines, improving S2R quality by 44.1%–82.3% and OB/EB quality by 3.8%–35.2%.

Understanding the reasons behind past code changes is critical for refactoring, code review, and debugging. However, code change rationale is often fragmented, inconsistently documented, and scattered across heterogeneous artifacts. We address this challenge with two contributions. First, we conduct an empirical study of nine rationale components from an established taxonomy and trace where they are documented across artifacts associated with 63 commits from five widely used open-source Java projects. Seven components appear in practice, and rationale is highly fragmented: commit messages and pull requests primarily capture GOAL, while NEED and ALTERNATIVE are more often found in issues and pull requests. No single artifact type consistently captures all components, which presents the need for cross-document reasoning. Second, we introduce ARGUS, an LLM-based approach that identifies sentences expressing GOAL, NEED, and ALTERNATIVE across a commit's artifacts and synthesizes them into concise rationale summaries. ARGUS achieved 51.4% overall precision and 93.2% recall for rationale identification and generated summaries rated as accurate relative to reference summaries. Experiments across different LLMs showed varying identification performance but consistently accurate summaries. A user study with 12 Java programmers found these summaries useful for understanding unfamiliar code changes and supporting code review, documentation, debugging, and maintenance.

During issue resolution, software developers rely on issue reports to discuss solutions for defects, feature requests, and other changes. These discussions contain proposed solutions—from design changes to code implementations—as well as their evaluations. Locating solution-related content is essential for investigating reopened issues, addressing regressions, reusing solutions, and understanding code change rationale. Manually understanding long discussions to identify such content can be difficult and time-consuming. This paper automates solution identification using language models as supervised classifiers. We investigate three applications—embeddings, prompting, and fine-tuning—across three classifier types: traditional ML models (MLMs), pre-trained language models (PLMs), and large language models (LLMs). Using 356 Mozilla Firefox issues, we created a dataset to train and evaluate six MLMs, four PLMs, and two LLMs across 68 configurations. Results show that MLMs with LLM embeddings outperform TF-IDF features, prompting underperforms, and fine-tuned LLMs achieve the highest performance, with LLAMAft reaching 0.716 F1 score. Ensembles of the best models further improve results (0.737 F1). Misclassifications often arise from misleading clues or missing context, highlighting the need for context-aware classifiers. Models trained on Mozilla transfer to other projects, with a small amount of project-specific data, further enhancing results. This work supports software maintenance, issue understanding, and solution reuse.

We advocate for AI/ML issue resolution frameworks tailored to maintenance workflows and the nature of modern AI/ML systems. Existing issue resolution frameworks largely emerged for traditional software maintenance practices and do not explicitly account for characteristics common in AI/ML systems, such as stochastic behavior, experimentation-driven workflows, and heterogeneous artifacts beyond source code. To identify the unique characteristics of issue resolution in AI/ML systems and motivate the need for tailored frameworks, we conducted a qualitative study of issue resolution workflows documented in 100 issue reports and pull requests across four widely used AI/ML systems: TensorFlow, scikit-learn, MLflow, and AutoGPT. Our findings suggest that issue resolution in AI/ML systems involves: recurring AI/ML-related activities that span multiple resolution stages; iterative experimentation and adaptive verification; and coordinated changes across artifacts such as datasets, prompts, and model configurations. We also observed challenges related to reproducibility, nondeterministic behavior, and artifact coordination. Building on these findings, we present a vision for AI/ML issue resolution frameworks and discuss research directions and tooling support needed to realize this vision.

Effective issue resolution is crucial for maintaining software quality. Yet developers frequently encounter challenges such as low-quality issue reports, limited understanding of real-world workflows, and a lack of automated support. This research aims to address these challenges through three complementary directions. First, we enhance issue report quality by proposing techniques that leverage LLM reasoning and application-specific information. Second, we empirically characterize developer workflows in both traditional and AI-augmented systems. Third, we automate cognitively demanding resolution tasks, including buggy UI localization and solution identification, through ML, DL, and LLM-based approaches. Together, our work delivers empirical insights, practical tools, and automated methods to advance AI-driven issue resolution, supporting more maintainable and high-quality software systems.

Effectively managing and resolving software issues is critical for maintaining and evolving software systems. Development teams often rely on issue trackers and issue reports to track and manage the work needed during issue resolution, ranging from issue reproduction and analysis to solution design, implementation, verification, and deployment. Despite the issue resolution process being generally known in the software engineering community as a sequential list of activities, it is unknown how developers implement this process in practice and how they discuss it in issue reports. This paper aims to enhance our understanding of the issue resolution process implemented in practice by analyzing the issue reports of Mozilla Firefox. We qualitatively and quantitatively analyzed the discussions found in 356 Firefox issue reports, to identify the sequences of stages that developers go through to address various software problems. We analyzed the sequences to identify the overall resolution process at Firefox and derived a catalog of 47 patterns that represent instances of the process. We analyzed the process and patterns across multiple dimensions, including pattern complexity, issue report types, problem categories, and issue resolution times, resulting in various insights about Mozilla's issue resolution process. We discuss these findings and their implications for different stakeholders on how to better assess and improve the issue resolution process.

Bug reports are essential for developers to confirm software problems, investigate their causes, and validate fixes. Unfortunately, reports often miss important information or are written unclearly, which can cause delays, increased issue resolution effort, or even the inability to solve issues. One of the most common components of reports that are problematic is the steps to reproduce the bug(s) (S2Rs), which are essential to replicate the described program failures and reason about fixes. Given the proclivity for deficiencies in reported S2Rs, prior work has proposed techniques that assist reporters in writing or assessing the quality of S2Rs. However, automated understanding of S2Rs is challenging, and requires linking nuanced natural language phrases with specific, semantically related program information. Prior techniques often struggle to form such language to program connections - due to issues in language variability and limitations of information gleaned from program analyses. To more effectively tackle the problem of S2R quality annotation, we propose a new technique called AstroBR, which leverages the language understanding capabilities of LLMs to identify and extract the S2Rs from bug reports and map them to GUI interactions in a program state model derived via dynamic analysis. We compared AstroBR to a related state-of-the-art approach and we found that AstroBR annotates S2Rs 25.2% better (in terms of F1 score) than the baseline. Additionally, AstroBR suggests more accurate missing S2Rs than the baseline (by 71.4% in terms of F1 score).

Managing issue reports is essential for the evolution and maintenance of software systems. However, manual issue management tasks such as triaging, prioritizing, localizing, and resolving issues are highly resource-intensive for projects with large codebases and users. To address this challenge, we present SPRINT, a GitHub application that utilizes state-of-the-art deep learning techniques to streamline issue management tasks. SPRINT assists developers by: (i) identifying existing issues similar to newly reported ones, (ii) predicting issue severity, and (iii) suggesting code files that likely require modification to solve the issues. We evaluated SPRINT using existing datasets and methodologies, measuring its predictive performance, and conducted a user study with five professional developers to assess its usability and usefulness. The results show that SPRINT is accurate, usable, and useful, providing evidence of its effectiveness in assisting developers in managing issue reports. SPRINT is an open-source tool available at this https URL.

Bug report management is a costly software maintenance process comprised of several challenging tasks. Given the UI-driven nature of mobile apps, bugs typically manifest through the UI, hence the identification of buggy UI screens and UI components (Buggy UI Localization) is important to localizing the buggy behavior and eventually fixing it. However, this task is challenging as developers must reason about bug descriptions (which are often low-quality), and the visual or code representations of UI screens.

This paper is the first to investigate the feasibility of automating the task of Buggy UI Localization through a comprehensive study that evaluates the capabilities of one textual and two multi-modal deep learning (DL) techniques and one textual unsupervised technique. We evaluate such techniques at two levels of granularity, Buggy UI Screen and UI Component localization. Our results illustrate the individual strengths of models that make use of different representations, wherein models that incorporate visual information perform better for UI screen localization, and models that operate on textual screen information perform better for UI component localization – highlighting the need for a localization approach that blends the benefits of both types of techniques. Furthermore, we study whether Buggy UI Localization can improve traditional buggy code localization and find that incorporating localized buggy UIs leads to improvements of 9%-12% in Hits@10.

Manipulating high-dimensional data is a major research challenge in the field of computer science in recent years. To classify this data, a lot of clustering algorithms have already been proposed. Kohonen self-organizing map (KSOM) is one of them. However, this algorithm has some drawbacks like overlapping clusters and non-linear separability problems. Therefore, in this paper, we propose an improved KSOM (I-KSOM) to reduce the problems that measures distances among objects using EISEN Cosine correlation formula. So far as we know, no previous work has used EISEN Cosine correlation distance measurements to classify high-dimensional data sets. To the robustness of the proposed KSOM, we carry out the experiments on several popular datasets like Iris, Seeds, Glass, Vertebral column, and Wisconsin breast cancer data sets. Our proposed algorithm shows better result compared to the existing original KSOM and another modified KSOM in terms of predictive performance with topographic and quantization error.

This research proposed a multi-modal person authentication system developed by feature level fusion of iris recognition and retina recognition. The reasons for choosing iris and retina as biometric characteristics are they provide the highest level of uniqueness, performance, universality, and circumvention. The 'curse-of-dimensionality' problem introduced in feature level fusion which was the main limitation of the prior works in this field, was minimized to a great extent by applying Principal Component Analysis (PCA) on the augmented feature template. To validate this approach, iris and retina images obtained from 'IITD' and 'DRIVE' datasets respectively are used. The recognition rate for the proposed multi-modal biometric system was 98.37% whereas it is 96.74% and 94.56% for iris recognition and retina recognition respectively.