Searcharxiv⌕ Search

arXiv subjects

Naoyasu Ubayashi

Publications and source records attributed to Naoyasu Ubayashi.

15 recordsLinked to original sources

A Study on the Impact of Natural Language Differences in Prompts on Automatic Code Generation Using LLMs

Large Language Models (LLMs) have demonstrated remarkable performance in automatic code generation tasks, thereby encouraging new research in this area. Although numerous studies have explored LLM-based code generation, the impact of the natural language in input prompts remains unexplored (language bias). This study aims to (1) quantify how the natural language of input prompts influences LLM-based code generation performance and (2) evaluate a mitigation strategy to reduce language bias in code generation. We assess code generation Accuracy on AtCoder, LeetCode, and BigCodeBench. To quantify the language bias on code generation, each problem is presented in English, Japanese, and Chinese. We use seven LLMs (GPT-4o, o3-mini, DeepSeek-V3.2, Llama-3, Qwen2.5-Coder-14B, Qwen2.5-Coder-0.5B, and GitHub Copilot) and assess their performance in terms of Accuracy (the number of problems for which generated code passes all test cases). We compare Accuracy before and after translation to evaluate the effectiveness of translation as a mitigation strategy. We observed that the natural language of problem statements affects LLM-based code generation performance. Specifically, the languages officially supported by each dataset achieved the highest median Accuracy. Also, translation improved Accuracy, but its effectiveness was not consistent across datasets and model types. We found that AtCoder contained a particularly high proportion of narrative-style problem statements and longer problem statements. Natural language significantly affects LLM code generation accuracy. Translation can mitigate language bias in some settings, but its effectiveness depends on the dataset and model type. Furthermore, the narrative aspects and context length of input prompts are important factors related to language bias and the effectiveness of translation as a mitigation strategy.

cs.SE↗

RepTran: Search-Based Repair of Transformer Models

To ensure the overall quality of AI-enabled software, not only traditional software components but also AI components need to be tested and repaired. Among AI components, Transformer models are increasingly integrated into software systems, which makes their misbehaviors critical. Although prior work in the software engineering community has proposed deep neural network (DNN) repair methods, most overlook Transformer-specific structures. We propose RepTran, a search-based repair method for Transformer models. It targets their feed-forward networks (FFNs), which play a central role in the architecture. RepTran identifies suspicious weights by combining two types of scores: a variance-based neuron score and an existing bidirectional score. It then iteratively optimizes these weights using differential evolution. Our evaluation includes 18 fault benchmarks constructed from CIFAR-100 and Tiny-ImageNet. We compare RepTran against three baselines: random weight selection, Arachne (a state-of-the-art DNN repair method), and ArachneW, which enables Arachne to control the number of selected weights. RepTran achieved an average repair rate of 74.7%, statistically outperforming random selection and Arachne across all benchmarks. Effect size analysis revealed that RepTran achieved higher repair rates than ArachneW regardless of the number of selected weights. These results suggest that RepTran is effective for enhancing the reliability of AI-enabled software.

cs.SE↗

QUARE: Quality-Aware Requirements Analysis through Multi-Agent Dialectical Negotiation

Automating requirements quality analysis remains challenging because multiple, often conflicting quality attributes must be balanced while preserving stakeholder intent. Existing Large-Language-Model (LLM) approaches predominantly rely on task-oriented decomposition or implicit aggregation, limiting their ability to systematically surface and resolve cross-quality conflicts. We present QUARE (QUality-Aware REquirements Analysis), a multi-agent framework that takes a project description as input and formulates requirements quality analysis as structured negotiation among five quality-specialized agents: Safety, Efficiency, Green, Trustworthiness, and Responsibility, coordinated by a dedicated orchestrator. QUARE introduces a dialectical negotiation protocol that explicitly exposes inter-quality conflicts and resolves them through iterative proposal, critique, and synthesis. Negotiated outcomes are transformed into structurally sound KAOS goal models via topology validation and verified against industry standards through retrieval-augmented generation (RAG). We evaluate QUARE on five benchmark systems drawn from established RE benchmarks, MARE and iReDev, and an industrial autonomous-driving specification, spanning safety-critical, financial, and information-system domains. Results show that QUARE achieves 98.2% compliance coverage, a 105% improvement over both baselines; 94.9% semantic preservation, a 2.3 percentage-point improvement over the best baseline; and high verifiability, with a score of 4.96 out of 5.0, while generating 25-43% more requirements than existing multi-agent RE frameworks. These findings suggest that, when using capable instruction-tuned models, architectural choices such as quality-dimension decomposition, explicit negotiation, and automated verification may contribute more to output quality than model scale alone.

cs.SE↗

Why Are Agentic Pull Requests Merged or Rejected? An Empirical Study

AI coding agents increasingly submit pull requests (Agentic-PRs) to open-source repositories, yet their performance is commonly assessed using merge and rejection outcomes alone. We hypothesized that these outcome labels do not reliably reflect agent capability without considering review interactions. To test this, we conducted a decision-oriented analysis of 11,048 closed Agentic Pull Requests, refined to 9,799 human-reviewed PRs, and manually inspected 717 representative cases to recover decision rationale from interaction artifacts. We found that rejection outcomes substantially overstate agent error: only 35.7% of rejected PRs reflected clear agentic failures, while 31.2% were driven by workflow constraints and 33.1% lacked observable decision rationale. Among merged PRs, 15.4% required explicit reviewer involvement through feedback or direct commits, and 5.5% showed no visible interaction trace. We further observed systematic differences across agents, with Copilot and Devin more often embedded in reviewer-mediated workflows, while Codex and Cursor PRs were typically merged with minimal interaction. These results reject the assumption that PR outcomes alone capture agent performance and demonstrate the need for interaction-aware evaluation grounded in review behavior.

cs.SE↗

ArgRE: Formal Argumentation for Conflict Resolution in Multi-Agent Requirements Negotiation

As software systems grow in complexity, they must satisfy an increasing number of competing quality attributes, making it essential to balance them in a principled manner -- for example, a safety requirement for sensor-fusion verification may conflict with a tight planning-cycle budget. Multi-agent large language model frameworks support this balancing process by assigning specialized agents to different objectives. However, their conflict resolution is typically heuristic. Requirements are aggregated implicitly without explicit acceptance or rejection, limiting auditability in regulated domains. We present ArgRE, a multi-agent requirements negotiation system that embeds Dung-style abstract argumentation into the negotiation stage. Each proposal, critique, and refinement is modeled as an argument, conflicts are represented as directed attack relations, and the accepted set of arguments is computed under grounded and preferred semantics. The pipeline further integrates KAOS goal modeling, multi-layer verification, and standards-oriented artifact generation. Evaluation across five case studies spanning safety-critical, financial, and information-system domains shows that ArgRE provides argument-level traceability absent from existing frameworks. Independent evaluators rated its decision justifications significantly higher than those of heuristic synthesis (4.32 vs. 3.07, p < 0.001), indicating improved auditability, while semantic intent preservation remains comparable (94.9% BERTScore F1) and compliance coverage reaches 84.7% versus 47.6%--47.8% for baselines. Structural analysis further confirms that the default pairwise protocol yields acyclic graphs in which grounded and preferred semantics coincide, whereas cross-pair arbitration introduces controlled cyclicity, leading to predictable divergence between the two semantics.

cs.SE↗

Generative AI for Requirements Engineering: A Systematic Literature Review

Introduction: Requirements engineering faces challenges due to the handling of increasingly complex software systems. These challenges can be addressed using generative AI. Given that GenAI based RE has not been systematically analyzed in detail, this review examines related research, focusing on trends, methodologies, challenges, and future directions. Methods: A systematic methodology for paper selection, data extraction, and feature analysis is used to comprehensively review 238 articles published from 2019 to 2025 and available from major academic databases. Results: Generative pretrained transformer models dominate current applications (67.3%), but research remains unevenly distributed across RE phases, with analysis (30.0%) and elicitation (22.1%) receiving the most attention, and management (6.8%) underexplored. Three core challenges: reproducibility (66.8%), hallucinations (63.4%), and interpretability (57.1%) form a tightly interlinked triad affecting trust and consistency. Strong correlations (35% cooccurrence) indicate these challenges must be addressed holistically. Industrial adoption remains nascent, with over 90% of studies corresponding to early stage development and only 1.3% reaching production level integration. Conclusions: Evaluation practices show maturity gaps, limited tool and dataset availability, and fragmented benchmarking approaches. Despite the transformative potential of GenAI based RE, several barriers hinder practical adoption. The strong correlations among core challenges demand specialized architectures targeting interdependencies rather than isolated solutions. The limited deployment reflects systemic bottlenecks in generalizability, data quality, and scalable evaluation methods. Successful adoption requires coordinated development across technical robustness, methodological maturity, and governance integration.

cs.SE↗

An empirical study on declined proposals: why are these proposals declined?

Design-level decisions in open-source software (OSS) projects are often made through structured mechanisms such as proposals, which require substantial community discussion and review. Despite their importance, the proposal process is resource-intensive and often leads to contributor frustration, especially when proposals are declined without clear feedback. Yet, the reasons behind proposal rejection remain poorly understood, limiting opportunities to streamline the process or guide contributors effectively. This study investigates the characteristics and outcomes of proposals in the Go programming language to understand why proposals are declined and how such outcomes might be anticipated. We conduct a mixed-method empirical study on 1,091 proposals submitted to the Go project. We quantify proposal outcomes, build a taxonomy of decline reasons, and evaluate large language models (LLMs) for predicting these outcomes. We find that proposals are more often declined than accepted, and resolution typically takes over a month. Only 14.7% of declined proposals are ever resubmitted. Through qualitative coding, we identify nine key reasons for proposal decline, such as duplication, limited use cases, or violations of project principles. This taxonomy can help contributors address issues in advance, e.g., checking for existing alternatives can reduce redundancy. We also demonstrate that GPT-based models can predict decline decisions early in the discussion (F1 score = 0.71 with partial comments), offering a practical tool for prioritizing review effort. Our findings reveal inefficiencies in the proposal process and highlight actionable opportunities for improving both contributor experience and reviewer workload by enabling early triage and guiding contributors to strengthen their proposals using a structured understanding of past decline reasons.

cs.SE↗

Mind the Gap: A Decade-Scale Empirical Study of Multi-Stakeholder Dynamics in VR Ecosystem

In the development and evolution of VR ecosystem, platform stakeholders continuously adapt their products in response to user and technical feedback, often reflected in subtle shifts in discussion topics or system updates. A comprehensive understanding of these changes is essential for identifying gaps between user expectations and developer actions, which can guide more effective quality assurance and user-centered innovation. While previous studies have analyzed either user reviews or developer discussions in isolation, such approaches typically fail to reveal how specific user concerns are (or are not) addressed by corresponding technical activities. To address this limitation, our study introduces a multi-view empirical framework that systematically compares and aligns stakeholder perspectives. By applying topic modeling and quantitative impact analysis to 944,320 user reviews and 389,477 developer posts, we identify not only the overlap in concerns (e.g., performance, input methods), but also clear gaps in areas like inclusivity and community safety (e.g., LGBTQ+ representation, child-friendly content). Our findings show that while users repeatedly raise such issues, they are rarely discussed in developer forums. These insights enable data-driven recommendations for closing the user-developer gap in VR ecosystems, offering practical implications for platform governance and the design of next-generation VR systems.

cs.SE↗

Evaluating Mutation-based Fault Localization for Quantum Programs

Quantum computers leverage the principles of quantum mechanics to execute operations. They require quantum programs that define operations on quantum bits (qubits), the fundamental units of computation. Unlike traditional software development, the process of creating and debugging quantum programs requires specialized knowledge of quantum computation, making the development process more challenging. In this paper, we apply and evaluate mutation-based fault localization (MBFL) for quantum programs with the aim of enhancing debugging efficiency. We use quantum mutation operations, which are specifically designed for quantum programs, to identify faults. Our evaluation involves 23 real-world faults and 305 artificially induced faults in quantum programs developed with Qiskit(R). The results show that real-world faults are more challenging for MBFL than artificial faults. In fact, the median EXAM score, which represents the percentage of the code examined before locating the faulty statement (lower is better), is 1.2% for artificial benchmark and 19.4% for the real-world benchmark in the worst-case scenario. Our study highlights the potential and limitations of MBFL for quantum programs, considering different fault types and mutation operation types. Finally, we discuss future directions for improving MBFL in the context of quantum programming.

cs.SE↗

Myth: The loss of core developers is a critical issue for OSS communities

Throughout their lifetime, open-source software systems will naturally attract new contributors and lose existing contributors. Not all OSS contributors are equal, however, as some contributors within a project possess significant knowledge and expertise of the codebase (i.e., core developers). When investigating the ability of projects to attract new contributors and how often a project loses contributors, it is therefore important to take into account the expertise of the contributors. Since core developers are vital to the longevity of projects, we therefore aim to find out: can OSS projects attract new core developers and how often do OSS projects lose core developers? To investigate core developer contribution patterns, we calculate the truck factor (or bus factor) of over 36,000 OSS projects to investigate how often TF developers join or abandon OSS projects. We find that 89% of our studied projects have experienced losing their core development team at least once. Our results also show that in 70% of cases, this project abandonment happens within the first three years of the project life. We also find that most OSS projects rely on a single core developer to maintain development activities. Finally, we find that only 27% of projects that were abandoned were able to attract at least one new TF developer. Our analysis shows that it is not uncommon for OSS projects to lose their initial core development team. This is likely due to most OSS project relying on a single core developer to maintain development activities. The first year of development is critical for OSS projects since this is where they are most at risk of losing their core developer(s). Additionally, projects that lose their core developer(s) early seem less likely to survive this event than projects that lost their core developers later on during their life.

cs.SE↗

An Empirical Study of Token-based Micro Commits

In software development, developers frequently apply maintenance activities to the source code that change a few lines by a single commit. A good understanding of the characteristics of such small changes can support quality assurance approaches (e.g., automated program repair), as it is likely that small changes are addressing deficiencies in other changes; thus, understanding the reasons for creating small changes can help understand the types of errors introduced. Eventually, these reasons and the types of errors can be used to enhance quality assurance approaches for improving code quality. While prior studies used code churns to characterize and investigate the small changes, such a definition has a critical limitation. Specifically, it loses the information of changed tokens in a line. For example, this definition fails to distinguish the following two one-line changes: (1) changing a string literal to fix a displayed message and (2) changing a function call and adding a new parameter. These are definitely maintenance activities, but we deduce that researchers and practitioners are interested in supporting the latter change. To address this limitation, in this paper, we define micro commits, a type of small change based on changed tokens. Our goal is to quantify small changes using changed tokens. Changed tokens allow us to identify small changes more precisely. In fact, this token-level definition can distinguish the above example. We investigate defined micro commits in four OSS projects and understand their characteristics as the first empirical study on token-based micro commits. We find that micro commits mainly replace a single name or literal token, and micro commits are more likely used to fix bugs. Additionally, we propose the use of token-based information to support software engineering approaches in which very small changes significantly affect their effectiveness.

cs.SE↗

OSS Myths and Facts

We have selected six myths about the OSS community and have tested whether they are true or not. The purpose of this report is to identify the lessons that can be learned from the development style of the OSS community and the issues that need to be addressed in order to achieve better Employee Experience (EX) in software development within companies and organizations. The OSS community has been led by a group of skilled developers known as hackers. We have great respect for the engineers and activities of the OSS community and aim to learn from them. On the other hand, it is important to recognize that having high expectations can sometimes result in misunderstandings. When there are excessive expectations and concerns, misunderstandings (referred to as myths) can arise, particularly when individuals who are not practitioners rely on hearsay to understand the practices of practitioners. We selected the myths to be tested based on a literature review and interviews. These myths are held by software development managers and customers who are not direct participants in the OSS community. We answered questions about each myth through: 1) Our own analysis of repository data, 2) A literature survey of data analysis conducted by previous studies, or 3) A combination of the two approaches.

cs.SE↗

Exploring the Effect of Multiple Natural Languages on Code Suggestion Using GitHub Copilot

GitHub Copilot is an AI-enabled tool that automates program synthesis. It has gained significant attention since its launch in 2021. Recent studies have extensively examined Copilot's capabilities in various programming tasks, as well as its security issues. However, little is known about the effect of different natural languages on code suggestion. Natural language is considered a social bias in the field of NLP, and this bias could impact the diversity of software engineering. To address this gap, we conducted an empirical study to investigate the effect of three popular natural languages (English, Japanese, and Chinese) on Copilot. We used 756 questions of varying difficulty levels from AtCoder contests for evaluation purposes. The results highlight that the capability varies across natural languages, with Chinese achieving the worst performance. Furthermore, regardless of the type of natural language, the performance decreases significantly as the difficulty of questions increases. Our work represents the initial step in comprehending the significance of natural languages in Copilot's capability and introduces promising opportunities for future endeavors.

cs.SE↗

When Conversations Turn Into Work: A Taxonomy of Converted Discussions and Issues in GitHub

Popular and large contemporary open-source projects now embrace a diverse set of documentation for communication channels. Examples include contribution guidelines (i.e., commit message guidelines, coding rules, submission guidelines), code of conduct (i.e., rules and behavior expectations), governance policies, and Q&A forum. In 2020, GitHub released Discussion to distinguish between communication and collaboration. However, it remains unclear how developers maintain these channels, how trivial it is, and whether deciding on conversion takes time. We conducted an empirical study on 259 NPM and 148 PyPI repositories, devising two taxonomies of reasons for converting discussions into issues and vice-versa. The most frequent conversion from a discussion to an issue is when developers request a contributor to clarify their idea into an issue (Reporting a Clarification Request -35.1% and 34.7%, respectively), while agreeing that having non actionable topic (QA, ideas, feature requests -55.0% and 42.0%, respectively}) is the most frequent reason of converting an issue into a discussion. Furthermore, we show that not all reasons for conversion are trivial (e.g., not a bug), and raising a conversion intent potentially takes time (i.e., a median of 15.2 and 35.1 hours, respectively, taken from issues to discussions). Our work contributes to complementing the GitHub guidelines and helping developers effectively utilize the Issue and Discussion communication channels to maintain their collaboration.

cs.SE↗

A Quantitative Study of Security Bug Fixes of GitHub Repositories

Software is prone to bugs and failures. Security bugs are those that expose or share privileged information and access in violation of the software's requirements. Given the seriousness of security bugs, there are centralized mechanisms for supporting and tracking these bugs across multiple products, one such mechanism is the Common Vulnerabilities and Exposures (CVE) ID description. When a bug gets a CVE, it is referenced by its CVE ID. Thus we explore thousands of Free/Libre Open Source Software (FLOSS) projects, on Github, to determine if developers reference or discuss CVEs in their code, commits, and issues. CVEs will often refer to 3rd party software dependencies of a project and thus the bug will not be in the actual product itself. We study how many of these references are intentional CVE references, and how many are relevant bugs within the projects themselves. We investigate how the bugs that reference CVEs are fixed and how long it takes to fix these bugs. The results of our manual classification for 250 bug reports show that 88 (35%), 32 (13%), and 130 (52%) are classified into "Version Update", "Fixing Code", and "Discussion". To understand how long it takes to fix those bugs, we compare two periods, Reporting Period, a period between the disclosure date of vulnerability information in CVE repositories and the creation date of the bug report in a project, and Fixing Period, a period between the creation date of the bug report and the fixing date of the bug report. We find that 44% of bug reports that are classified into "Version Update" or "Fixing Code" have longer Reporting Period than Fixing Period. This suggests that those who submit CVEs should notify affected projects more directly.

cs.SE↗