Explainable AI Points to Reused Code as a Hidden Signal of Software Faults

Finding defects before they reach production has long been one of the most stubborn challenges in software engineering. A fault discovered after release can cost orders of magnitude more to fix than one caught during development, and as systems grow into millions of lines spread across hundreds of packages, manual inspection becomes hopeless. Machine-learning-based fault prediction has promised a way out: models trained on historical bug data learn which code characteristics foreshadow trouble, so that quality-assurance teams can focus their scarce testing effort where it matters most. Yet in practice these models have struggled to earn the trust of developers, largely because they behave as black boxes that flag a package as risky without explaining why. A new study published in Cluster Computing by Mohsin Shaikh of the University of Larkano, Sabina Akram of the University of Bari, Irfan Tunio, and Jawad Khan and Younhyun Jung of Gachon University tackles both problems at once, combining a package-level, reuse-aware view of software architecture with explainable artificial intelligence techniques that make the model’s reasoning transparent.

The researchers argue that the level of abstraction at which fault prediction operates matters enormously. Much of the classic literature works at the granularity of individual classes, scoring each class for its likelihood of harboring a defect using metrics such as lines of code, cyclomatic complexity, or the well-known CK metric suite. But modern Java applications are organized into packages, and it is at this architectural level that developers actually plan, review, and refactor their code. Predicting faults at the class level produces thousands of scattered warnings that no team can act on coherently, while predicting at the package level yields a shortlist of architectural units that managers and engineers can directly schedule for inspection, testing, or restructuring. The new model therefore treats the package, not the class, as its unit of analysis, and the authors demonstrate through empirical evaluation on standard benchmark datasets that this package-level abstraction is an effective and practical lens for fault prediction.

What distinguishes this work from earlier package-level studies is its explicit attention to code reuse. Software is rarely written entirely from scratch; developers routinely reuse classes, share functionality across packages, and lean on familiar patterns to accelerate development. Reuse is usually celebrated as a virtue, because well-tested, repeatedly exercised code tends to be stable. But reuse also creates hidden coupling: when several packages depend on the same reused components, a fault in that shared core can propagate widely, and a package whose cohesion depends on reused elements may behave very differently from one built from bespoke code. The authors’ model therefore incorporates architectural metrics designed to capture cohesion, dependency structures, and reuse patterns simultaneously. In doing so it extends a line of research in which Shaikh and colleagues had previously shown that reusability-based package organization carries real signal about where bugs concentrate in object-oriented systems.

The metric suite at the heart of the model draws on decades of work in software modularization research. Cohesion metrics measure how tightly the elements inside a package belong together, on the premise that a package should implement a single, well-defined responsibility. Coupling and dependency metrics count and characterize the relationships between packages, since tangled dependency webs and cyclic references are notorious incubators of defects. Reuse metrics quantify how much of a package’s content is shared with or derived from other parts of the system. The study’s appendices provide precise mathematical definitions of these package-level measures, computed with tooling that includes the Understand static analysis environment, and the authors curated their datasets from widely used open-source Java systems, including Eclipse, Apache POI, Lucene, Camel, and the Eclipse JDT Core, with bug information drawn from established defect repositories used across the fault-prediction community.

On the learning side, the researchers assembled a multi-layered evaluation design rather than relying on a single train-and-test split. Cross-validation is used to check that predictive performance holds up across different partitions of the data rather than reflecting one lucky split. More distinctively, the authors adopt an effort-oriented perspective, following recent trends in just-in-time and effort-aware defect prediction. The insight behind this orientation is that raw accuracy is not the metric that matters to a development team; what matters is how many defects a reviewer can uncover per unit of inspection effort. A model that ranks the most defect-dense packages first delivers more practical value than one with a nominally higher classification score that wastes reviewers’ time on sparsely buggy code. By evaluating their model through this effort-aware lens, the authors align the experimental protocol with the way fault prediction is actually consumed in industrial settings.

The third layer of the approach, and the one with the broadest implications, is explainable AI. The researchers integrate two of the most widely adopted interpretability techniques: SHAP, or SHapley Additive exPlanations, which borrows ideas from cooperative game theory to assign each input feature a fair share of credit or blame for an individual prediction, and LIME, or Local Interpretable Model-agnostic Explanations, which approximates a complex model locally around a given prediction with a simple, human-readable surrogate. Applied to fault prediction, these methods can tell a developer not merely that package X is flagged as fault-prone, but that the flag is driven, for example, by unusually low cohesion combined with heavy dependence on reused components and a dense web of outgoing dependencies. Such explanations transform the model’s output from an opaque verdict into an actionable diagnostic that points toward a specific remedy, whether that is remodularization, targeted testing, or dependency cleanup.

The empirical results, reported across multiple figures and algorithmic descriptions in the paper, support the central conjecture of the study: that package-level abstraction, enriched with reuse awareness and paired with interpretability, improves both the accuracy and the usefulness of fault prediction compared with traditional approaches. The authors note that traditional fault-prediction methods have often lacked scalability, interoperability, and smooth integration into software-quality workflows, and their architecture is designed to address precisely these shortcomings. Just as important, the explanation layer reveals which architectural properties the model has learned to associate with defects, giving the research community a window into the causal texture of software quality rather than a bare leaderboard of predictive scores.

Perhaps the most practically significant finding is the authors’ conjecture that modular design of packages can significantly improve software maintainability and reliability. Because the explainable model surfaces cohesion, dependency, and reuse as the dominant predictors of fault-proneness, it indirectly validates a long-standing principle of software architecture: packages that are cohesive, loosely coupled, and organized around reusable responsibilities tend to be healthier and less buggy. This gives architects empirical, data-driven ammunition when they argue for refactoring a tangled package structure, and it suggests that quality-assurance budgets should be steered toward packages whose architectural metrics deviate from these healthy norms. The work also connects to a growing body of literature on explainable machine learning in software engineering, including studies applying SHAP-style interpretation to just-in-time defect prediction, which together signal a field-wide shift from pure prediction toward prediction that engineers can understand and act upon.

The study was supported by the Sindh Higher Education Commission of Pakistan through its Sindh Research Support Program, by a National Research Foundation of Korea grant funded by the Korean Ministry of Science and ICT, and by an Institute of Information and Communications Technology Planning and Evaluation grant under Korea’s Leading Generative AI Human Resources Development program, reflecting an international collaboration spanning Pakistan, Italy, and South Korea. The datasets and metric definitions described in the manuscript have been made available to the community, including a public repository of the package-level datasets used in the experiments, which lowers the barrier for other groups to replicate and extend the results. For an industry drowning in technical debt, the message of this research is refreshingly concrete: look at how your packages are organized, pay attention to reuse and coupling, let an interpretable model show you where the risk lives, and fix the architecture before the bugs fix your schedule for you.

Subject of Research: Explainable AI-based fault prediction at the package level in object-oriented software

Article Title: Reuse-aware package-level fault prediction with Explainable AI

Article References: Shaikh, M., Akram, S., Tunio, I., Khan, J., & Jung, Y. (2026). Reuse-aware package-level fault prediction with Explainable AI. Cluster Computing, 29(12), Article 705. https://doi.org/10.1007/s10586-026-06509-8

Image Credits: AI Generated

DOI: 10.1007/s10586-026-06509-8

Keywords: software fault prediction, explainable AI, SHAP, LIME, package cohesion, code reuse, software metrics, machine learning, software engineering, Java, maintainability, defect prediction