Automated program repair has emerged as a powerful technique to mitigate the impact of software bugs on system reliability and user experience. This paper introduces Repair Agent, the first work to address the program repair challenge through an autonomous agent based on a large language model (LLM). Unlike existing deep learning-based approaches, which prompt a model with a fixed prompt or in a fixed feedback loop, our work treats the LLM as an agent capable of autonomously planning and executing actions to fix bugs by invoking suitable tools. Repair Agent freely interleaves gathering information about the bug, gathering repair ingredients, and validating fixes, while deciding which tools to invoke based on the gathered information and feedback from previous fix attempts. Key contributions that enable Repair Agent include a set of tools that are useful for program repair, a dynamically updated prompt format that allows the LLM to interact with these tools, and a finite state machine that guides the agent in invoking the tools. Our evaluation on the popular Defects4J dataset demonstrates Repair Agent's effectiveness in autonomously repairing 164 bugs, including 39 bugs not fixed by prior techniques. Interacting with the LLM imposes an average cost of 270k tokens per bug, which, under the current pricing of OpenAI's GPT-3.5 model, translates to 14 cents per bug. To the best of our knowledge, this work is the first to present an autonomous, LLM-based agent for program repair, paving the way for future agent-based techniques in software engineering.

Large Language Model (LLM)-based agents are increasingly employed to automate complex software engineering tasks, such as program repair and issue resolution. These agents operate by autonomously generating natural language thoughts, invoking external tools, and iteratively refining their solutions. Despite their widespread adoption, the internal decision-making processes of these agents remain largely unexplored, limiting our understanding of their operational dynamics and failure modes. In this paper, we present a large-scale empirical study of the thought-action-result trajectories of three state-of-the-art LLM-based agents: RepairAgent, AutoCodeRover, and OpenHands. We unify their interaction logs into a common format, capturing 120 trajectories and 2,822 LLM interactions focused on program repair and issue resolution. Our study combines quantitative analyses of structural properties, action patterns, and token usage with qualitative assessments of reasoning coherence and feedback integration. We identify key trajectory characteristics, such as iteration counts and token consumption, recurring action sequences, and the semantic coherence of thoughts, actions, and their results. Our findings reveal behavioral motifs and anti-patterns that distinguish successful from failed executions, providing actionable insights for improving agent design, including prompting strategies, failure diagnosis, and anti-pattern detection. We release our dataset and annotation framework to support further research on transparent and robust autonomous software engineering agents.

Continuous integration and continuous delivery (CI/CD) has become a prevalent practice in software development. GitHub Actions is emerging as a popular platform for implementing CI/CD pipelines, called workflows, especially because the platform offers 2,000 minutes of computation for free to public repositories each month. To understand what these resources are used for and whether CI/CD could be more efficient, this paper presents the first comprehensive empirical study of resource usage and optimization opportunities of GitHub Action workflows. Our findings show that CI/CD imposes significant costs, e.g., $504 per year for an average paid-tier repository. The majority of the used resources is consumed by testing and building (91.2%), which is triggered by pull requests (50.7%), pushes (30.9%), and regularly scheduled workflows (15.5%). While existing optimizations, such as caching (adopted by 32.9% of paid-tier repositories), demonstrate a positive impact, they overall remain underutilized. This result underscores the need for enhanced documentation and tools to guide developers toward more resource-efficient workflows. Moreover, we show that relatively simple changes in the platform, such as deactivating scheduled workflows when repositories are inactive, could result in reductions of execution time between 1.1% and 31.6% over the impacted workflows. Overall, we envision our findings to help improve the resource efficiency of CI/CD pipelines.

Programs often emit natural language messages, e.g., in logging statements or exceptions raised on unexpected paths. To be meaningful to users and developers, the message, i.e., what to say, must be consistent with the condition under which it gets triggered, i.e., when to say it. However, checking for inconsistencies between conditions and messages is challenging because the conditions are expressed in the logic of the programming language, while messages are informally expressed in natural language. This paper presents CMI-Finder, an approach for detecting condition-message inconsistencies. CMI-Finder is based on a neural model that takes a condition and a message as its input and then predicts whether the two are consistent. To address the problem of obtaining realistic, diverse, and large-scale training data, we present six techniques to generate large numbers of inconsistent examples to learn from automatically. Moreover, we describe and compare three neural models, which are based on binary classification, triplet loss, and fine-tuning, respectively. Our evaluation applies the approach to 300K condition-message statements extracted from 42 million lines of Python code. The best model achieves a precision of 78% at a recall of 72% on a dataset of past bug fixes. Applying the approach to the newest versions of popular open-source projects reveals 50 previously unknown bugs, 19 of which have been confirmed by the developers so far.

Developers use exceptions guarded by conditions to abort the execution when a program reaches an unexpected state. However, sometimes the condition and the raised exception do not imply the same stopping reason, in which case, we call them inconsistent if-condition-raise statements. The inconsistency can originate from a mistake in the condition or the exception message. This paper presents IICR-Finder, a deep learning-based approach to detect inconsistent if-condition-raise statements. The approach reasons both about the condition’s logic and the natural language of the exception message and raises a warning in case of inconsistency. We present six techniques to automatically generate large numbers of inconsistent statements to train two neural models based on binary classification and triplet loss. We apply the approach to 210K if-condition-raise statements extracted from 42 million lines of Python code. It achieves a precision of 72% at a recall of 60% on a dataset of past bug fixes. Running IICR-Finder on open-source projects reveals 30 previously unknown bugs, ten of which we reported, with eight confirmed by the developers.

Facebook and other advertising platforms exploit users' data for marketing purposes by allowing advertisers to select specific users and target them with well-crafted messages (the practice is being called micro-targeting). However, advertisers such as Cambridge Analytica have maliciously used these targeting features to manipulate users in the context of elections. The European Commission plans to restrict or even ban some targeting functionalities in the new European Democracy Action Plan act to protect users from such harms. The difficulty in finding appropriate restrictions is that we do not know the economic impact of these restrictions on regular advertisers. In this paper, to inform the debate, we take a first step by understanding who is advertising on Facebook and how they use the targeting functionalities of ad platforms. For this, we asked 890 U.S. users to install a monitoring tool on their browsers to collect the ads they receive on Facebook and information about how these ads were targeted. By matching advertisers on Facebook with their LinkedIn profiles, we could see that 71% of advertisers are small and medium-sized businesses with 200 employees or less, and they are responsible for 61% of ads and 57% of ad impressions. Regarding micro-targeting, we found that only 32% of small and medium-sized businesses and 30% of large-sized businesses in our dataset micro-target at least one of their ads. These results should not be interpreted as micro-targeting not being useful as a marketing strategy, but rather that advertisers prefer to outsource the micro-targeting task to ad platforms. Indeed, to deliver ads, Facebook is employing optimization algorithms that exploit user data to decide which users should see what ads; which basically means ad platforms are performing an algorithmic-driven micro-targeting. Hence, when setting restrictions on micro-targeting, legislators should take into account both the traditional advertiser-driven micro-targeting as well as algorithmic-driven micro-targeting performed by ad platforms.