Large Language Models (LLMs) are increasingly used through autonomous agents (e.g., Copilot, Cursor, Devin, Claude) to perform complex software development tasks. However, little is known about how these agents introduce and document technical debt through Self-Admitted Technical Debt (SATD) comments. Understanding SATD in AI-generated code is critical, as such comments explicitly reveal acknowledged limitations and deferred fixes that affect long-term maintenance. In this study, we quantitatively and qualitatively analyze 525 SATD comments authored by AI agents using the AIDev dataset. Our results show that AI-generated SATD is slightly more technically detailed than human-authored SATD, yet both often describe problems without clear guidance on resolution. Through thematic analysis, we identify 34 SATD topics grouped into 10 categories, with AI agents predominantly documenting requirement- and design-related debt. While many SATD topics overlap between AI and humans, our taxonomy reveals new debt categories and emphases specific to AI-authored SATD, particularly related to infrastructure, pipelines, dependency management, and requirement interpretation driven by developer prompts. Overall, our findings suggest that AI- and human-authored SATD share common characteristics but differ in expression and focus, highlighting the need for deeper investigation into how agentic systems communicate and manage technical debt.

Agentic AI systems powered by Large Language Models (LLMs) are increasingly used to autonomously contribute code in modern software development. While prior work has shown that such systems can accelerate development tasks, their reliability and maintenance behavior in real-world Continuous Integration (CI) workflows remain poorly understood. In this study, we analyze 11,771 pull requests (PRs) from GitHub, including 7,619 agentic and 4,152 human-authored PRs, to investigate how agentic code behaves during CI workflows. We examine (1) CI failure rates at the pull-request level, (2) responsibility for introducing and fixing CI failures, and (3) time-to-fix at the commit level using fail–fix mappings. Our results show that human-authored CI fixes exhibit a median time to fix of 71.70 minutes, whereas AI agentic-authored CI fixes resolve failures nearly four times faster, with a median of 17.23 minutes. Our results show that agent-authored fixes resolve CI failures nearly four times faster than human fixes (median 17.23 vs. 71.70 minutes). However, agents introduce most CI failures (79.15%) while performing a smaller share of fixes (60.63%), indicating that human developers remain heavily involved in failure resolution despite faster agent responses.

In the rapidly evolving landscape of cloud-native computing, Organizations are increasingly adopting infrastructure models that emphasize scalability, flexibility, and efficiency. Kubernetes has become the de facto standard for orchestrating containerized applications in these environments. However, the inherent complexity of cloud-native ecosystems introduces significant challenges, particularly in the form of misconfigurations that can compromise both security and performance. This study explores the potential of Large Language Models (LLMs) in identifying Kubernetes misconfigurations. We introduce a comprehensive taxonomy of common misconfiguration types, offering a structured framework to better understand and categorize these issues. Additionally, we conduct an empirical evaluation of state-of-the-art detection tools to benchmark their effectiveness. Furthermore, we analyze the Kubernetes objects most prone to misconfiguration and evaluate the severity of the identified issues. By leveraging advanced machine learning techniques, including LLMs, we provide novel insights into enhancing misconfiguration detection methodologies.

Organizations migrating monolithic applications to microservice architectures often face significant challenges in both decomposition and refactoring phases. While the decomposition step has received considerable automation research, refactoring remains predominantly manual, creating bottlenecks in migration efforts and preventing runtime-based and a more realistic evaluation of decomposition techniques. We propose a fully automated refactoring methodology that complements existing decomposition approaches. Our technique implements an ID-based and DTO-based hybrid design for inter-service communication and leverages Large Language Models (LLMs) for decision making, code analysis and code generation. Taking a monolith's source code and decomposition plan as input, our approach identifies “API classes” that cross service boundaries, selects their appropriate target design among the ID and DTO based methods and then automatically generates the necessary communication components—API contracts, server-side endpoints, and client-side proxies. This approach balances the preservation of the monolith's workflow consistency through the ID-based design and minimizing the overhead and complexity of the cross-service interactions through the DTO-based design. A qualitative evaluation using three benchmark applications demonstrates our approach's feasibility and advantages over related work.

Microservices architecture is increasingly adopted in modern software projects. Microservices deployment is often managed by tools like Spring Cloud, Consul, and Docker. Although there is existing research on microservices, practical deployment challenges are still under-explored, impacting the efficiency and success of applications. In this paper, we aim to identify and understand the challenges developers encounter with microservices deployment. We analyze trends in help requests on Stack Overflow, one of the most popular Q&A platforms for developers, to identify and categorize these challenges and highlight the most popular and difficult ones. First, we examined 1,214 Stack Overflow posts related to microservices deployment using topic modelling based on the BERTopic method to extract and analyze challenge topics. To obtain a more comprehensive understanding, we also analyzed the identified topics according to their popularity and difficulty. Our results reveal that discussions related to microservices deployment vary over time from 2013 to 2023. We identified nine distinct topics related to microservices deployment challenges, including deployment strategies, data management, composition and discovery, containerization, configuration, and orchestration in Kubernetes, security management, CI/CD pipeline automation, exposure to external clients, and post-deployment monitoring. Results reveal that microservices containerization is the most popular topic that poses numerous challenges to many users, with 2,148 average views and a 3.19 average score. While composition and discovery and post deployment monitoring are the most challenging topics, with 78 % of questions on post deployment monitoring lacking accepted answers, and 28 % of questions about composition and discovery remaining unanswered. This study identifies critical areas in microservices deployment that need further investigation, particularly, difficult and popular ones.

The Internet of Things (IoT) has greatly benefited the technological advances of a variety of fields, such as manufacturing and medicine, to name a few. The context surrounding these use cases is, however, often widely different from conventional Cloud Computing and web applications. Cyberphysical environments present us with major concerns and constraints surrounding the resilience of systems, which often rely on critical infrastructure and important workloads to prevent major losses for businesses or even the endangerment of individuals. The supervision of these infrastructures, outside the controlled and relatively safe environment of a datacenter, is therefore one of the major considerations for modern IoT systems. In this paper, we evaluate the core concepts around this thesis and propose an architectural and conceptual approach to improve the monitoring, scalability, and orchestration of IoT systems. We leverage and integrate different solutions inspired by modern IoT practices and the cloud ecosystem to optimize both software and hardware aspects. The solution revolves around an Edge Computing approach, Event-driven communication (MQTT) in the Edge, the orchestration of containerized services using Ku-bernetes and KubeEdge, and Device Twins for the management of physical components. Through development, experiment, and evaluation, we propose an architecture and two complementary fault-tolerance strategies to address synchronization between cloud and edge components and improve the overall resilience of the system.

The rapid growth of mobile applications development and usage raises several new challenges to developers as they need to respond quickly to the users’ needs in a world of continuous changes. Developers often use third-party libraries to add functionality, which significantly improves developers productivity, and reduces time-to-market. In this paper, we present an approach for the visualization and recommendation of libraries for Android apps. Our approach, named LibScanDroid, is based on how libraries are used within existing Android applications. LibScanDroid groups together libraries based on their history of joint and separate usage in existing Android applications available in Google Play Store. The library groups, i.e., usage patterns, are presented in several layers to visualize and navigate through the patterns. These groupings are performed using the ϵ-DBSCAN hierarchical clustering algorithm.We implement our approach in the form of an interactive tool and evaluate it on a database that covers 1,458 libraries that are used by over 1,000 Android applications. Our experiments have shown that our approach can detect library patterns with high co-usage cohesion. The results from the cross-validation, allows us to affirm the generalizability of the detected patterns.

The microservices architectural style offers many advantages such as scalability, reusability and ease of maintainability. As such microservices has become a common architectural choice when developing new applications. Hence, to benefit from these advantages, monolithic applications need to be redesigned in order to migrate to a microservice based architecture. Due to the inherent complexity and high costs related to this process, it is crucial to automate this task. In this paper, we propose a method that can identify potential microservices from a given monolithic application. Our method takes as input the source code of the source application in order to measure the similarities and dependencies between all of the classes in the system using their interactions and the domain terminology employed within the code. These similarity values are then used with a variant of a density-based clustering algorithm to generate a hierarchical structure of the recommended microservices while identifying potential outlier classes. We provide an empirical evaluation of our approach through different experimental settings including a comparison with existing human-designed microservices and a comparison with 5 baselines. The results show that our method succeeds in generating microservices that are overall more cohesive and that have fewer interactions in-between them with up to 0.9 of precision score when compared to human-designed microservices.

Configurations play an important role in the behavior and operation of configurable systems. Prior to deployment a configured system is tested in the development environment. However, because of the differences between the development environment and the production environment, the configuration of the system needs to be adapted for the production environment. It is therefore important to re-test the configured system in the production environment. Since the system has already been tested in the development environment one should avoid reapplying all the test cases, it is desirable to reduce the test suite to be used in the production environment as much as possible. This is the goal of the method we propose in this paper. For this, we explore the similarities between the configuration used in the development environment and the configuration for the production environment to eliminate test cases. Indeed, the difference between the two configurations is only at the environment level, i.e. only the configuration parameters that influence the interactions between the system and its environment are changed for the deployment in the production environment. We propose a method that is based on a classification of the configuration parameters (based on their dependency to the environment) and use it to reduce the development time test suite before reapplying it in the production environment.

Kubernetes is an open source platform that hides the complexity of orchestrating containerized microservices while managing their availability. Stateless microservices can be executed in a resilient manner with Kubernetes. However, the same is not true for stateful microservices. Containers are characterized by having an ephemeral state and the state aspect of stateful microservices makes orchestration more complex than what the initial Kubernetes controllers were built for. In this paper, we investigate the current Kubernetes support for stateful microservices and identify the problems. We propose a solution to enrich Kubernetes with a State Controller that allows for state replication and automatic service redirection to the healthy entities through the management of secondary labels. We have conducted experiments under the default configuration of Kubernetes as well as under its most responsive one to evaluate our solution and compare the different architectures from an availability perspective. We also perform a comparative evaluation with OpenSAF, which is a proven solution for enabling high-availability. The results of our investigations show that our solution improves the recovery time of stateful microservices by 55% and even up to 99% in certain cases.

Microservices represent a new architectural style where small and loosely coupled modules can be developed and deployed independently to compose an application. This architectural style brings various benefits such as maintainability and flexibility in scaling and aims at decreasing downtime in case of failure or upgrade. One of the enablers is Kubernetes, an open source platform that provides mechanisms for deploying, maintaining, and scaling containerized applications across a cluster of hosts. Moreover, Kubernetes enables healing through failure recovery actions to improve the availability of applications. As our ultimate goal is to devise architectures to enable high availability (HA) with Kubernetes for microservice based applications, in this paper we examine the availability achievable through Kubernetes under its default configuration. We have conducted a set of experiments which show that the service outage can be significantly higher than expected.

Despite the many advantages, the use of external libraries through their APIs remains difficult because of the usage patterns and constraints that are hidden or not properly documented. Existing work provides different techniques to recover API usage patterns from client programs in order to help developers understand and use those libraries. However, most of these techniques produce basic patterns that generally do not involve temporal properties. In this paper, we discuss the problem of temporal usage patterns recovery and propose a genetic-programming algorithm to solve it. Our evaluation on different APIs shows that the proposed algorithm allows to derive non-trivial temporal usage patterns that are useful and generalizable to new API clients.

The reuse at the component level is generally more effective than the one at the object-oriented class level. This is due to the granularity level where components expose their functionalities at an abstract level compared to the fine-grained object-oriented classes. Moreover, components clearly define their dependencies through their provided and required interfaces in an explicit way that facilitates the understanding of how to reuse these components. Therefore, several component identification approaches have been proposed to identify components based on the analysis object-oriented software applications. Nevertheless, most of the existing component identification approaches did not consider co-usage dependencies between API classes to identify classes/methods that can be reused to implement a specific scenario. In this paper, we propose an approach to identify reusable software components in object-oriented APIs, based on the interactions between client applications and the targeted API. As we are dealing with actual clients using the API, dynamic analysis allows to better capture the instances of API usage. Approaches using static analysis are usually limited by the difficulty of handling dynamic features such as polymorphism and class loading. We evaluate our approach by applying it to three Java APIs with eight client applications from the DaCapo benchmark. DaCapo provides a set of pre-defined usage scenarios. The results show that our component identification approach has a very high precision.

Software developers need to cope with the complexity of Application Programming Interfaces (APIs) of external libraries or frameworks. Typical APIs provide thousands of methods to their client programs, and these methods are not used independently of each other. Much existing work has provided different techniques to mine API usage patterns based on client programs in order to help developers understanding and using existing libraries. Other techniques propose to overcome the strong constraint of clients' dependency and infer API usage patterns only using the library source code. In this paper, we propose a cooperative usage pattern mining technique (COUPminer) that combines client-based and library-based usage pattern mining. We evaluated our technique through four APIs and the obtained results show that the cooperative approach allows taking advantage at the same time from the precision of client-based technique and from the generalizability of library-based techniques.

Software evolution history is usually represented at fine granularity by commits in software repositories, and at coarse granularity by software releases. In order to gain insights on development activities and on software evolution, the information on releases is too general, whereas the information on commits is prohibitively large to be efficiently processed by a developer. This paper proposes an automatic technique for the identification of distinct phases of evolution. Such software evolution phases are characterized by similar development activities in terms of changes to entities. Therefore, our technique decomposes software evolution history to assist developers identify periods of different development activities. Our analysis technique is a search-based optimization of the best decomposition of commits from the software repository using heuristics such as classes changed in each commit, and the magnitude/importance of these changes. To validate our technique, we applied it on the evolution history of five case studies covering multiple releases over several years of development. An interesting outcome of the evaluation is that our automatic decomposition of software evolution history recovered the original decomposition in software releases.

Learning to use existing or new software libraries is a difficult task for software developers, which would impede their productivity. Much existing work has provided different techniques to mine API usage patterns from client programs in order to help developers on understanding and using existing libraries. However, considering only client programs to identify API usage patterns is a strong constraint as the client programs source code is not always available or the clients themselves do not exist yet for newly released APIs. In this paper, we propose a technique for mining Non Client-based Usage Patterns (NCBUP miner). We detect unordered API usage patterns as distinct groups of API methods that are structurally and semantically related and thus may contribute together to the implementation of a particular functionality for potential client programs. We evaluated our technique through four APIs. The obtained results are comparable to those of client-based approaches in terms of usage-patterns cohesion.

Learning to use existing or new software libraries is a difficult task for software developers, which would impede their productivity. Most of existing work provided different techniques to mine API usage patterns from client programs, in order to help developers to understand and use existing libraries. However, considering only client programs to identify API usage patterns, is a strong constraint as collecting several similar client programs for an API is not a trivial task. And even if these clients are available, all the usage scenarios of the API of interest may not be covered by those clients. In this paper, we propose a visualization based approach for the refinement of Client-based Usage Patterns. We first visualize the patterns structure. Then we enrich the patterns with API methods that are semantically related to them, and thus may contribute together to the implementation of a particular functionality for potential client programs.

Software developers need to cope with complexity of Application Programming Interfaces (APIs) of external libraries or frameworks. However, typical APIs provide several thousands of methods to their client programs, and such large APIs are difficult to learn and use. An API method is generally used within client programs along with other methods of the API of interest. Despite this, co-usage relationships between API methods are often not documented. We propose a technique for mining Multi-Level API Usage Patterns (MLUP) to exhibit the co-usage relationships between methods of the API of interest across interfering usage scenarios. We detect multi-level usage patterns as distinct groups of API methods, where each group is uniformly used across variable client programs, independently of usage contexts. We evaluated our technique through the usage of four APIs having up to 22 client programs per API. For all the studied APIs, our technique was able to detect usage patterns that are, almost all, highly consistent and highly cohesive across a considerable variability of client programs.

Nowadays, APIs represent the most common reuse form when developing software. However, the reuse benefits depend greatly on the ability of client application developers to use correctly the APIs. In this paper, we present an observational study on the API usage constraints and their documentation. To conduct the study on a large number of APIs, we implemented and validated strategies to automatically detect four types of usage constraints in existing APIs. We observed that some of the constraint types are frequent and that for three types, they are not documented in general. Surprisingly, the absence of documentation is, in general, specific to the constraints and not due to the non documenting habits of developers.