AI coding agents have been increasingly integrated into software development workflows to help developers with various coding tasks. However, their effectiveness in real bug-fixing tasks remains uncertain. In this paper, we report on an analysis of 9,052 pull requests (PRs) from five agents—Codex, Copilot, Cursor, Claude, and Devin—alongside human-authored PRs from the same projects. We found that agentic PRs have lower acceptance rates than human-authored PRs (71.37% vs. 87.62%), although substantial variation exists between agents. To understand the reasons behind the rejection of agentic PRs, we manually examined 201 rejected agentic PRs and derived five categories of rejection factors. The most frequent issues are related to code quality, solution suitability, and failure to address reviewer feedback, often leading maintainers to abandon the review process. In many cases, agentic PRs are also superseded by other PRs. These findings shed light on current limitations of AI agents and highlight key challenges in developing more reliable and context-aware automated contributors.

The use of generative AI-based coding assistants like ChatGPT and Github Copilot is a reality in contemporary software development. Many of these tools are provided as remote APIs. Using third-party APIs raises data privacy and security concerns for client companies, which motivates the use of locallydeployed language models. In this study, we explore the tradeoff between model accuracy and energy consumption, aiming to provide valuable insights to help developers make informed decisions when selecting a language model. We investigate the performance of 18 families of LLMs in typical software development tasks on two real-world infrastructures, a commodity GPU and a powerful AI-specific GPU. Given that deploying LLMs locally requires powerful infrastructure which might not be affordable for everyone, we consider both full-precision and quantized models. Our findings reveal that employing a big LLM with a higher energy budget does not always translate to significantly improved accuracy. Additionally, quantized versions of large models generally offer better efficiency and accuracy compared to full-precision versions of medium-sized ones. Apart from that, not a single model is suitable for all types of software development tasks.

Conventionally, callbacks and inversion of control have been the main tools to structure event-driven applications. Sadly, those patterns constitute a well-known source of design problems. The Reactive Programming (RP) paradigm has arisen as an approach to mitigate these problems. Yet, little evidence has been provided regarding the advantages of RP, and concerns have also arisen about the API usability of RP libraries given their disparate number of operators. In this work, we conduct a study on GitHub (GH) and Stack Overflow (SO) and explore three Reactive Extensions (Rx) libraries (RxJava, RxJS, and RxSwift) with the most GH projects to understand how much the vast Rx operators are being used. Also, we examine Rx SO posts to complement the results from the GH exploration by understanding the problems faced by RP developers and how they relate with the operators' frequencies found in open source projects. Results reveal that, in spite of its API size, the great majority of the Rx operators are actually being used (95.2%), with only a few, mostly related to RxJava, not being utilized. Also, we unveil 23 topics from SO with more posts concerning the Stream Abstraction (36.4%). Posts related to Dependency Management, Introductory Questions, and iOS Development figure as relevant topics to the community. The findings herein present can not only stimulate advancements in the field by understanding the usage of RP API and the main problems faced by developers, but also help newcomers in identifying the most important operators and the areas that are the most likely to be relevant for a RP application.

As mobile devices are supporting more and more of our daily activities, it is vital to widen their battery up-time as much as possible. In fact, according to the Wall Street Journal, 9/10 users suffer from low battery anxiety. The goal of our work is to understand how Android usage, apps, operating systems, hardware and user habits influence battery lifespan. Our strategy is to collect anonymous raw data from devices all over the world, through a mobile app, build and analyze a large-scale dataset containing real-world, day-to-day data, representative of user practices. So far, the dataset we collected includes 12 million+ (anonymous) data samples, across 900+ device brands and 5.000+ models. And, it keeps growing. The data we collect, which is publicly available and by different channels, is sufficiently heterogeneous for supporting studies with a wide range of focuses and research goals, thus opening the opportunity to inform and reshape user habits, and even influence the development of both hardware and software for mobile devices.

Over the last years, increasing attention has been given to creating energy-efficient software systems. However, developers still lack the knowledge and the tools to support them in that task. In this work, we explore our vision that energy consumption non-specialists can build software that consumes less energy by alternating, at development time, between third-party, readily available, diversely-designed pieces of software, without increasing the development complexity. To support our vision, we propose an approach for energy-aware development that combines the construction of application-independent energy profiles of Java collections and static analysis to produce an estimate of in which ways and how intensively a system employs these collections. By combining these two pieces of information, it is possible to produce energy-saving recommendations for alternative collection implementations to be used in different parts of the system. We implement this approach in a tool named CT+ that works with both desktop and mobile Java systems, and is capable of analyzing 40 different collection implementations of lists, maps, and sets. We applied CT+ to twelve software systems: two mobile-based, seven desktop-based, and three that can run in both environments. Our evaluation infrastructure involved a high-end server, a notebook, and three mobile devices. When applying the (mostly trivial) recommendations, we achieved up to 17.34% reduction in energy consumption just by replacing collection implementations. Even for a real world, mature, highly-optimized system such as Xalan, CT+ could achieve a 5.81% reduction in energy consumption. Our results indicate that some widely used collections, e.g., ArrayList, HashMap, and HashTable, are not energy-efficient and sometimes should be avoided when energy consumption is a major concern.

Swift is a new programming language developed by Apple as a replacement to Objective-C. It features a sophisticated error handling (EH) mechanism that provides the kind of separation of concerns afforded by exception handling mechanisms in other languages, while also including constructs to improve safety and maintainability. However, Swift also inherits a software development culture stemming from Objective-C being the de-facto standard programming language for Apple platforms for the last 15 years. It is, therefore, a priori unclear whether Swift developers embrace the novel EH mechanisms of the programming language or still rely on the old EH culture of Objective-C even working in Swift.

Mobile devices have become ubiquitous in the recent years, but the complaints about energy consumption are almost universal. On Android, the developer can choose among several different approaches to develop an app. In this paper, we investigate the impact of some of the most popular development approaches on the energy consumption of Android apps. Our study uses a testbed of 33 different benchmarks and 3 applications on 5 different devices to compare the energy efficiency and performance of the most commonly used approaches to develop apps on Android: Java, JavaScript, and C/C++ (through the NDK tools). In our experiments, Javascript was more energy-efficient in 75% of all benchmarks, while their Java counterparts consume up to 36.27x more energy (median of 1.97x). On the other hand, both Java and C++ outperformed JavaScript in most of the benchmarks. Based on these results, four Java applications were re-engineered to use a combination of Java and either JavaScript or C/C++ functions. For one of the apps, the hybrid solution using Java and C++ spent 10x less time and almost 100x less energy than a pure Java solution. The results were not uniform, however. For another app, when we restructured its implementation so as to minimize cross-language method invocations, the hybrid solution using Java and C++ took 8% longer to execute and consumed 11% more energy than a hybrid solution using Java and JavaScript. Since most Android apps are written solely in Java, the results of this study indicate that leveraging a combination of approaches may lead to non-negligible improvements in energy-efficiency and performance.

The recent introduction of the pull-based development model promoted agile development practices such as Code Reviews and Continuous Integration (CI). CI, in particular, is currently a standard development practice in open-source software (OSS) projects. Although it is well-known that OSS contributors have different involvements (e.g., while some developers drive the project, there is a long tail of peripheral developers), little is known about how the contributor's degree of participation can influence the build status of an OSS project. Through TravisTorrent's dataset, we compare the success rates of builds made by casual and non-casual contributors and what factors on their contributions may influence the build result. Our results suggest that there is no representative difference between their build success (they are similar in 85% of the analyzed projects), meaning that being a casual contributor is not a strong indicator for creating failing builds. Also, factors like the size of their contributions and the number of project configurations (jobs) have the potential of impacting the build success.

Over the last years, energy consumption has become a first-class citizen in software development practice. While energy-efficient solutions on lower-level layers of the software stack are well-established, there is convincing evidence that even better results can be achieved by encouraging practitioners to participate in the process. For instance, previous work has shown that using a newer version of a concurrent data structure can yield a 2.19x energy savings when compared to the old associative implementation [75]. Nonetheless, little is known about how much software engineers are employing energy-efficient solutions in their applications and what solutions they employ for improving energy-efficiency. In this paper we present a qualitative study of "energy-aware commits". Using Github as our primary data source, we perform a thorough analysis on an initial sample of 2,189 commits and carefully curate a set of 371 energy-aware commits spread over 317 real-world non-trivial applications. Our study reveals that software developers heavily rely on low-level energy management approaches, such as frequency scaling and multiple levels of idleness. Also, our findings suggest that ill-chosen energy saving techniques can impact the correctness of an application. Yet, we found what we call "energy-aware interfaces", which are means for clients (e.g., Developers or end-users) to save energy in their applications just by using a function, abstracting away the low-level implementation details.

A growing number of software solutions have been proposed to address application-level energy consumption problems in the last few years. However, little is known about how much software developers are concerned about energy consumption, what aspects of energy consumption they consider important, and what solutions they have in mind for improving energy efficiency. In this paper we present the first empirical study on understanding the views of application programmers on software energy consumption problems. Using StackOverflow as our primary data source, we analyze a carefully curated sample of more than 300 questions and 550 answers from more than 800 users. With this data, we observed a number of interesting findings. Our study shows that practitioners are aware of the energy consumption problems: the questions they ask are not only diverse -- we found 5 main themes of questions -- but also often more interesting and challenging when compared to the control question set. Even though energy consumption-related questions are popular when considering a number of different popularity measures, the same cannot be said about the quality of their answers. In addition, we observed that some of these answers are often flawed or vague. We contrast the advice provided by these answers with the state-of-the-art research on energy consumption. Our summary of software energy consumption problems may help researchers focus on what matters the most to software developers and end users.