When two or more code snippets are identical or sufficiently similar, they form code clones. Such duplication can harm system maintainability as the software evolves. Code clone genealogy (CCG) extraction involves analyzing successive versions of a software system to identify code clones, their modifications, additions, and removals. Visualizing clone genealogies helps developers manage their clones, improving code comprehensibility and maintainability. Despite their importance, to the best of our knowledge, no fully functional, easily executable clone genealogy extractor exists. Furthermore, all extractors proposed in the literature are specifically designed to work with a particular set of clone detectors, resulting in strong coupling. To address these shortcomings, this paper presents OmniCCG, a code clone genealogy extractor that is agnostic to clone detectors. Given a Git repository and user settings, OmniCCG extracts code clone genealogies from the repository, along with common genealogy metrics, such as clone density, k-volatile, and others. Moreover, one may use OmniCCG in two different ways. The first is via a modern and responsive user interface, in which one can easily track the genealogies in their repository alongside a dashboard of relevant metrics. The second is via a console application that supports local execution. OmniCCG is available as an web application [27] and console application [28].

Code clones consist of two or more identical or similar code snippets. Code clones hurt maintainability by requiring synchronized updates across multiple locations and increasing the risk of inconsistent changes. To understand how clones evolve, the genealogy of code clones captures the evolutionary history of duplicated code snippets by linking them across successive versions of the software system. Since the emergence of Large Language Models (LLMs), software engineering has been reshaped, with code written and evolved differently. This evolution has given rise to coding agents who act as partners to developers. While code clone genealogy is well understood in human-centric development, its evolution in human–agent collaborative projects remains unclear. In this study, we analyze 350 code clone lineages across 6 software projects in which human actively colaborate with coding agents. We observed that humans introduce 85.71% of code clones, whereas agents contribute only 14.29%. Despite similar clone survival rates for both humans (80%) and agents (76%), the maintenance dynamics differ significantly. The analysis of genealogies reveals that humans predominate in maintaining lineages created by agents. These findings highlight that humans remain critical for the evolution of code generated by coding agents.

Code clones are fragments of code that are copied and reused within the same or across different codebases, often with minor modifications. Their presence poses significant challenges, as defects or changes in one cloned fragment may require consistent updates across all related clones, negatively affecting software maintainability. Code Clone Lifecycle analysis provides valuable insights into when code clones are introduced and how they evolve during the code review process. Recent advances in Large Language Models (LLMs) have enabled Coding Agents that autonomously create branches, modify code, and submit Pull Requests (PRs). While these agents improve productivity, they also introduce new challenges for managing code clones within PRs. This paper presents an analysis of the Code Clone Lifecycle in agentic PRs hosted on GitHub. Using the NiCad clone detection tool, we analyzed 7,851 PRs created by AI agents from the AiDev dataset. Our results identify 28,425 clones across 497 PRs. Manual validation of a representative sample shows a predominance of Type I (29%) and Type III (46.26%) clones. Among the affected PRs, 93 contain clones restricted to a single commit, 320 exhibit clones recurring across multiple commits, and 84 present both single and recurring occurrences. Overall, the findings indicate that clones tend to persist once introduced, progressing through the PR lifecycle and ultimately being merged into the codebase.

Code refactorings are of pivotal importance in modern code review. Developers may preserve, revisit, add or undo refactorings through changes' revisions. Their goal is to certify that the driving intent of a code change is properly achieved. Developers' intents behind refactorings may vary from pure structural improvement to facilitating feature additions and bug fixes. However, there is little understanding of the refactoring practices performed by developers during the code review process. It is also unclear whether the developers' intents influence the selection, composition, and evolution of refactorings during the review of a code change. Through mining 1,780 reviewed code changes from 6 systems pertaining to two large open-source communities, we report the first in-depth empirical study on software refactoring during code review. We inspected and classified the developers' intents behind each code change into 7 distinct categories. By analyzing data generated during the complete reviewing process, we observe: (i) how refactorings are selected, composed and evolved throughout each code change, and (ii) how developers' intents are related to these decisions. For instance, our analysis shows developers regularly apply non-trivial sequences of refactorings that crosscut multiple code elements (i.e., widely scattered in the program) to support a single feature addition. Moreover, we observed that new developers' intents commonly emerge during the code review process, influencing how developers select and compose their refactorings to achieve the new and adapted goals. Finally, we provide an enriched dataset that allows researchers to investigate the context and motivations behind refactoring operations during the code review process.

Microservices are a new and rapidly growing architectural model aimed at developing highly scalable software solutions based on independently deployable and evolvable components. Due to its novelty, microservice-related discussions are increasing in Q&A websites, such as StackOverflow (SO). In order to understand what is being discussed by the microservice community, this work has applied mining techniques and topic modelling to a manually-curated dataset of 1,043 microservice-related posts from StackOverflow. As a result, we found that 13.68% of microservice technical posts on SO discuss a single technology: Netflix Eureka. Moreover, buzzwords in the microservice ecosystem, e.g., blue/green deployment, were not identified as relevant subjects of discussion on SO. Finally, we show how a high discussion rate on SO may not reflect the popularity of a certain subject within the microservice community.

Code review has been widely adopted by both industrial and open source software development communities. Research in code review is highly dependant on real-world data, and although existing researchers have attempted to provide code review datasets, there is still no dataset that links code reviews with complete versions of the system's code base mainly because reviewed versions are not kept in the system's version control repository. Thus, we present CROP, the Code Review Open Platform, the first curated code review repository that links review data with isolated complete versions (snapshots) of the source code at the time of review. CROP currently provides data for 8 software systems, 48,975 reviews and 112,617 patches, including versions of the systems that are inaccessible in the systems' original repositories. Moreover, CROP is extensible, and it will be continuously curated and extended.

This paper presents a technique to identify a developer based on their IDE event data. We exploited the KaVE data set which recorded IDE activities from 85 developers with 11M events. We found that using an SVM with a linear kernel on raw event count outperformed k-NN in identifying developers with an accuracy of 0.52. Moreover, after setting the optimal number of events and sessions to train the classifier, we achieved a higher accuracy of 0.69 and 0.71 respectively. The findings shows that we can identify developers based on their IDE event data. The technique can be expanded further to group similar developers for IDE feature recommendations.