AI coding agents contribute thousands of pull requests daily to open-source repositories, yet practitioners lack empirical guidance on optimal contribution sizing. We adapt the therapeutic index framework from pharmacology to characterise the relationship between pull request size and integration outcomes. Analysing 33,078 agent-authored pull requests from the AIDev dataset across five AI coding agents, we model dose-response relationships for efficacy (merge probability) and toxicity (review friction). All agents exhibit statistically significant negative relationships between size and merge probability (p < 0.001), differing substantially in baseline performance (47.5% to 82.6%) and dose sensitivity. Task type substantially moderates these relationships: bug fixes exhibit ED50 of 1,467 lines [95% CI: 1,025–2,216] with therapeutic index of 35.2, whilst features show ED50 of 18,234 lines [95% CI: 12,337–28,390] with therapeutic index of 2.3. This 15-fold difference, confirmed by non-overlapping confidence intervals, indicates that bug fixes exhibit wider therapeutic windows whilst feature implementations exhibit narrower windows.

Vulnerability identifiers such as CVE, CWE, and GHSA are standardised references to known software security issues, yet their use in practice is not well understood. This paper compares vulnerability ID use in GitHub pull requests authored by autonomous agents, bots, and human developers. Using the AIDev pop dataset and an augmented set of pull requests from the same repositories, we analyse who mentions vulnerability identifiers and where they appear. Bots account for around 69.1% of all mentions, usually adding few identifiers in pull request descriptions, while human and agent mentions are rarer but span more locations. Qualitative analysis shows that bots mainly reference identifiers in automated dependency updates and audits, whereas humans and agents use them to support fixes, maintenance, and discussion.

Bots have become popular in software projects as they play critical roles, from running tests to fixing bugs/vulnerabilities. However, the large number of software bots adds extra effort to practitioners and researchers to distinguish human accounts from bot accounts to avoid bias in data-driven studies. Researchers developed several approaches to identify bots at specific activity levels (issue/pull request or commit), considering a single repository and disregarding features that showed to be effective in other domains. To address this gap, we propose using a machine learning-based approach to identify the bot accounts regardless of their activity level. We selected and extracted 19 features related to the account's profile information, activities, and comment similarity. Then, we evaluated the performance of five machine learning classifiers using a dataset that has more than 5,000 GitHub accounts. Our results show that the Random Forest classifier performs the best, with an F1-score of 92.4% and AUC of 98.7%. Furthermore, the account profile information (e.g., account login) contains the most relevant features to identify the account type. Finally, we compare the performance of our Random Forest classifier to the state-of-the-art approaches, and our results show that our model outperforms the state-of-the-art techniques in identifying the account type regardless of their activity level.

Software bots are becoming increasingly popular in software engineering (SE). In this tutorial, we define what a bot is and present several examples. We also discuss the many benefits bots provide to the SE community, including helping in development tasks (such as pull request review and integration) and onboarding newcomers to a project. Finally, we discuss the challenges related to interacting with and developing software bots.

Automated tools are frequently used in social coding repositories to perform repetitive activities that are part of the distributed software development process. Recently, GitHub introduced GitHub Actions, a feature providing automated workflows for repository maintainers. Although several Actions have been built and used by practitioners, relatively little has been done to evaluate them. Understanding and anticipating the effects of adopting such kind of technology is important for planning and management. Our research is the first to investigate how developers use Actions and how several activity indicators change after their adoption. Our results indicate that, although only a small subset of repositories adopted GitHub Actions to date, there is a positive perception of the technology. Our findings also indicate that the adoption of GitHub Actions increases the number of monthly rejected pull requests and decreases the monthly number of commits on merged pull requests. These results are especially relevant for practitioners to understand and prevent undesirable effects on their projects.