Reasoning Beyond Prediction: From Data-Driven to Causal Software Engineering ROBERTO PIETRANTUONO, LUCA GIAMATTEI, and STEFANO RUSSO, University of Naples
arXiv:2606.27960v1 [cs.SE] 26 Jun 2026
Federico II, Italy Software engineering is an intellectually demanding, creative discipline that juggles a web of interdependent tasks to design, build, and assure the quality of increasingly complex systems. As our expectations from software soar — with demands spanning AI-driven products, pervasively distributed and cloud-native architectures, and deeply embedded cyber-physical environments — its complexity steadily increases. In response, a new wave of co-engineering methods and tools, fueled by deep learning, has emerged to augment the process, enhancing automation and decision support. Yet, these advances remain far from delivering the kind of intelligent support that modern software development demands. We call for a new paradigm of human–machine cooperation: one where machines don’t just automate routine tasks or predict from learned patterns, but actively amplify engineers’ reasoning through the lens of causation. As software becomes smarter, a smarter support is needed. CCS Concepts: • Software and its engineering; • Computing methodologies → Causal reasoning; Additional Key Words and Phrases: Causal Reasoning, Software Engineering, Machine Learning ACM Reference Format: Roberto Pietrantuono, Luca Giamattei, and Stefano Russo. 2026. Reasoning Beyond Prediction: From DataDriven to Causal Software Engineering. ACM Accepted 1, 1 (June 2026), 14 pages. https://doi.org/XXXXXXX.XXXXXXX
1 Introduction Over the past 10–15 years, many software systems have shifted toward cloud-native and distributed architectures, although adoption remains heterogeneous across organizations and domains. Industry surveys report widespread adoption of cloud-native practices (e.g., 89% in 2024) and broad production use of Kubernetes — both strong indicators of large-scale distributed deployment [5, 6]. In parallel, modern systems increasingly incorporate adaptive and data-driven components, including AI/ML in many contexts [33], enabling capabilities such as autonomous vehicles, intelligent robots, LLM-based assistants, and virtual doctors. But these advances also bring increased uncertainty and unpredictability, driven by data-centric computation, intricate interactions with dynamic environments, and the pervasive distribution of today’s architectures. Microservice ecosystems may include hundreds of independently deployable services; cloud-native applications run atop dynamic infrastructures; cyber-physical systems must coordinate with uncertain physical environments; and AI/ML components can introduce probabilistic behavior and novel failure modes. Together, these factors contribute to structural and epistemic complexity beyond that of traditional monolithic or statically deployed systems — as evident, for instance, in microservice architectures [28] and AI/ML-enabled systems [26]. This shift toward highly interconnected, adaptive, and data-driven architectures makes it increasingly difficult to reason about global behavior, safety, and correctness, requiring engineers to navigate vast behavioral spaces to Authors’ Contact Information: Roberto Pietrantuono, [email protected]; Luca Giamattei, luca.giamattei@ unina.it; Stefano Russo, [email protected], University of Naples Federico II, Naples, Italy. Please use nonacm option or ACM Engage class to enable CC licenses This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License. © 2025 Copyright held by the owner/author(s). ACM XXXX-XXXX/2026/6-ART https://doi.org/XXXXXXX.XXXXXXX ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
2
Pietrantuono et al.
uncover critical failures. The question is no longer Can we build it? — but Can we trust it? Failing to answer could seriously erode public confidence in future systems, with unpredictable social and economic impact.1 But how are software engineers managing this challenge? Under the banner of AI4SE (Artificial Intelligence for Software Engineering), deep learning-powered human–machine co-engineering — now most visibly through LLM-assisted development [13] — is constantly advocated as the solution. Undoubtedly, the gains are real and sometimes impressive: today’s tools can autocomplete code, draft tests, generate documentation, and even offer design suggestions. However, the steady stream of reported, sometimes catastrophic, software-related incidents shows that we are still far from trustworthy software systems. In practice, software engineering struggles to keep pace with demands for safety, fairness, security, privacy, and transparency, to name just a few concerns. The reason is structural, as the inherent flaws of deep learning — rooted in the correlation-based nature and lack of transparency — makes AI support fragile, opaque, and hence untrustworthy, especially in critical domains. Unsurprisingly, the reliability and quality of LLMs themselves has emerged as one of the hottest research areas in 2024-25 [2, 34]. In the end, ML- and LLM-powered solutions suffer from the same problems they are supposed to solve. A simple example illustrates the gap. Consider an autonomous driving system, like a city shuttle. During peak hours, the shuttle occasionally brakes too late at pedestrian crossings. Logs appear normal, and an ML-based monitoring tool flags a strong correlation: late braking (Y) tends to occur when the shuttle is using high-resolution camera mode (X). Based on correlation alone, the tool blames the camera pipeline. But this is a classic case of spurious correlation. A causal analysis reveals the true driver: higher vehicle speed (Z) automatically triggers the switch to highresolution camera mode (X) to improve long-distance perception, adding processing delay; the same increase (Z) also reduces the available braking margin, making late braking (Y) more likely. The system incorrectly blames X for Y, when both are caused by Z. A causal model makes this explicit and also allows engineers to pose targeted what-if questions based on these relations (e.g., What if the vehicle enters a downhill segment? What if road friction changes? What if we adjust the speed threshold for sensor-mode switching?) to identify risky configurations before deployment. Such reasoning reveals risks that today’s correlation-based tools simply cannot detect. This small example captures a broader reality: correlation-based tools can tell us what happened, but rarely why, nor what would happen if things were different. And without the why, trust remains elusive. We believe it is time for a qualitative leap in the kind of assistance machines can offer to engineers: AI should not simply do more; it should do it better. 2 Human-Machine Software co-Engineering Machines have long supported humans by automating tedious and error-prone parts of engineering processes, including software engineering (SE). Over time, their assistance has evolved, accelerating both development and quality assurance. In software engineering, this progression can be seen in what machines support (Sidebar 1): from ancillary, problem-independent tasks and scaffolding (e.g., CASE tools, workbenches, IDEs) (row 1), to automating techniques that formalize engineers’ intuitions in analysis, design, implementation, testing, and maintenance (row 2). For example, Coverage-Guided Testing formalizes the intuition that increasing test coverage reveals more failures; Automated Static Analysis formalizes rule-checking to detect code quality issues. The rise of machine learning (ML) — particularly deep learning — has been indeed a game changer for SE (row 3). With ML, the machine is asked not only to automate tasks but also to support decisions by exploiting historical data from the system or process to uncover patterns across the lifecycle. 1 For a deeper discussion of how trust is conceptualized in software engineering and AI assistants, see [1, 20]
ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
Advancing SE through the Lens of Causation
3
Sidebar 1: Machine Support in Software Engineering: Key Milestones Goal
Description
Examples
Scaffolding
Tools provide general, problemindependent support for organizing and structuring engineering activities.
CASE tools, IDEs, workbenches; syntax highlighting; version control systems; build automation; test runners; basic linting tools.
Support automation
Machines implement formalized methods and techniques to automate specific software engineering tasks.
Coverage-Guided Testing (CGT); Automated Static Analysis (ASA); Model Checking; Symbolic Execution; Code Generation from Models.
Support decision
ML-based tools assist decision-making by learning from historical data, recognizing patterns, making predictions.
Effort estimation; code completion; fault prediction; test generation, selection & prioritiz.; RCA; anomaly detection; failure prediction; doc generation.
Support ing
Machines perform step-by-step reasoning to support explanation, hypothesis generation, and action planning.
What-if analysis; interactive simulation and diagnosis; counterfactual reasoning; explainable recommendations; RCA.
reason-
This paradigm – known as Data-driven Software Engineering (DDSE) — has elevated the role of the machine in human-machine co-engineering, as ML augments human capabilities and participates in decision-making. Today, ML is used to support nearly every SE activity [38]. Companies deploy ML models to predict (mis)behaviors by learning correlations from product, process, and operational data across the lifecycle. In IT operations, this is often framed as AIOps, an ML-driven approach that automates operations by detecting patterns in data and triggering remediation. As LLMs came to the scene, a new wave of data-driven solutions is emerging. LLMs utilize vast unstructured datasets (e.g., from the web), acting as surrogates of domain expert knowledge to enhance tasks such as requirements analysis [15], coding [18], testing [36], debugging [25], repair [40], and roughly any software engineering task [13]. Despite the challenges and concerns surrounding LLM-based solutions (e.g., safety and privacy risks), companies are increasingly adopting them,2,3 although the extent of the actual benefits remains a debated topic.4,5 DDSE represents the current state of human–machine co-engineering. Compared to two decades ago, machines now do far more than automating repetitive tasks. Their step-beyond has been qualitative: ML scales and automates a core human ability, pattern recognition. By uncovering patterns in large datasets, ML amplifies inductive reasoning, enabling systems to infer complex input–output relations and make predictions that guide decisions. LLMs extend this with content generation based on learned patterns. How accurate these capabilities are, and how much engineers should rely on them, is a separate debate, but it is undeniable that, when applied properly, ML can boost software engineering productivity by an order of magnitude. 3 The step beyond: Causal Software Engineering Although ML, and especially LLMs, is often perceived as a panacea, it supports only part of the engineering process. While learning patterns in data is essential for prediction, engineers do much more when designing or validating a system. Throughout the development cycle, they formulate and compare alternative hypotheses, mentally simulate actions, and seek explanations — in other words, they reason beyond pattern recognition. For example, engineers hypothesize multiple design options to meet requirements. During quality assurance, they anticipate how the system 2 https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai 3 https://www.statista.com/outlook/tmo/artificial-intelligence/worldwide 4 https://www.heise.de/en/news/Warnings-of-the-AI-bubble-bursting-are-increasing-10767973.html
5 https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-ca
ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
4
Pietrantuono et al.
might behave under specific conditions and “guess” which inputs, configurations, environmental factors, or user behaviors could trigger failures. In maintenance, such as debugging, they generate alternative explanations for why a failure occurred and what might have happened under different scenarios, guiding them toward an effective fix. In each of these tasks, engineers naturally infer causal relationships among variables and, by such relations, mentally simulate alternative scenarios. We envision causal reasoning as a promising direction for enhancing next-generation assistants. ML models — including transformers, the foundation of LLMs — primarily learn associations between variables, corresponding to rung 1 of Pearl’s ladder of causation [29]. They do not uncover causality. With ML, we can only reason about what has been observed, answering questions such as: given an observed context (from which the model learned), what output 𝑋 should we expect if the input 𝑊 happens to be 𝑤? Formally, this is the conditional probability 𝑃 (𝑋 | 𝑊 = 𝑤). Even with LLMs and their massive training corpora, the output fundamentally remains a conditional probability over observed patterns. Causal reasoning acts at a higher level: it targets causation and answers questions such as What output 𝑋 do we expect if we actively set 𝑊 = 𝑤? — that is, if we intervene on 𝑊 and change the data-generating process. Or: What would have happened to 𝑋 if we had set 𝑊 = 𝑤? These intervention and counterfactual queries (rungs 2 and 3 of the ladder of causation) lie beyond ML’s reach, since ML predicts only from what has been seen. Causal reasoning, by contrast, allows us to proactively explore what will happen (or would have happened) under hypothetical interventions, rather than waiting for data to appear. It shifts from a learningby-seeing paradigm toward learning-by-doing or even learning-by-imagining. Thus, machines gain not only the learn-to-predict capability of ML, but also a plan-to-improve capability. The growing importance of reasoning is evident in the evolution of LLMs from advanced yet associative ML algorithms to compositional systems that demonstrate increasingly effective forms of approximate reasoning, driven by techniques such as chain-of-thought prompting, self-refinement, and reasoning-oriented training. The push to integrate LLMs with external tools to support complex reasoning tasks — seen in AI agents and virtual assistants — points in the same direction. The scientific community is actively debating the extent to which LLMs genuinely reason, as opposed to merely exhibiting the appearance of reasoning through sophisticated pattern matching such as memorization effect [30]. At the same time, a growing body of work examines the synergy between LLMs and causal reasoning, where causal models provide the structure for formal reasoning and LLMs support causal learning and inference [21, 24, 35]. In domains such as safety engineering, law, and healthcare — where explanation, justification, and trust are essential — equipping LLMs with causal reasoning is especially important. Without such a shift, the impact of AI in software engineering may plateau as demands for explainability and accountability grow sharper. Causal Software Engineering (CSE) offers a new human–machine co-design perspective in which machines imitate and augment human reasoning to anticipate scenarios and explain events, amplified by computational power. Given the motivations above, we believe CSE may represent the next qualitative step beyond DDSE in the assistance machines can provide. The rationale lies in how information is used: DDSE implicitly assumes that data is all you need, yet — no matter how much data you have — useful answers and genuine reasoning require a model where human knowledge and assumptions are explicit. Statistical causal modeling is one way (though not the
ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
Advancing SE through the Lens of Causation
5
Sidebar 2: Data-Driven Software Engineering vs Causal Software Engineering Present – DDSE based on ML
Future – CSE based on Causal Reasoning
Pattern Recognition
Causal Inference
ML automates and amplifies our pattern recognition ability, allowing us to uncover unknown associations from data.
Causal relations – implying associations - enable richer reasoning tasks such as simulating what-if scenarios, deriving explanations, formulating hypotheses, and imagining alternative pasts. Automating these abilities substantially elevates the quality of machine assistance.
Correlation
Causation
ML learns correlation: decisions based on (possibly spurious) correlations and confounding (e.g., causing LLMs hallucinations) can be wrong and potentially dangerous.
The quality of the causal inference is superior, as it subsumes ML and offers a free-from-confounders decisions by “cleaning” the X-W relation from spurious correlations.
Reactive
Proactive
ML is a passive learning approach (i.e,. learning “by seeing”), as it needs to wait for relevant knowledge to be observed. Strictly speaking, it learns the conditional probability of an event of interest 𝑋 , given the observation of the event W, 𝑃 (𝑋 |𝑊 ).
Causal reasoning enables proactive inference by allowing hypotheses about outcomes under deliberate changes to variables. Through interventions, it supports planning and simulating improvement actions beyond what is seen in training data. Formally, it learns quantities like 𝑃 (𝑋 |𝑑𝑜 (𝑊 ) ), where the do-operator indicates that 𝑊 is actively set rather than conditioned on other variables.
Opaqueness
Transparency
The ML state-of-the-art strategy, that is deep learning, is opaque and lacks explainability, a severe limitations in safety-critical, legal or healthcare domains.
Explainability and accountability is central to decisionmaking. Causal models provides fully explainable and transparent reasoning paths along with the result.
Implicit
Explicit
ML-based solutions are purely data-driven. They do not integrate human knowledge and assumptions about the modelled phenomenon, which are essential to decisionmaking. Thus, context is assumed to be implicitly described by the data. This does not mean there are no assumptions, but that assumptions are not made explicit.
A causal model allows to easily specify the domaindependent assumptions and integrate human knowledge in the loop. This improves the quality of decisions and gives a clearer framework, in terms of assumptions and constraints (i.e., context) under which those decisions are to be considered valid.
only one) to harness data to answer the right questions and filtering out spurious correlations.6 Sidebar 2 highlights the main differences between DDSE and CSE. 4 The CSE conceptual framework We outline a conceptual framework to harness causal reasoning for software engineering tasks ranging from requirements analysis to design-space exploration, test generation, code analysis, and root cause analysis. In the next section, we review recent research efforts, including our own work on testing and analysis, that instantiate elements of this framework. The framework (Figure 1) revolves around causal models: structured, inspectable representations of a system and its environment that encode the cause–effect relations relevant to a given task. Different tasks may call for different models; Table 1 provides illustrative variables. A causal 6While various forms of automated logical reasoning are possible, we focus on statistical (covariance-based) causal reason-
ing [21] as a natural step beyond ML [29]. This approach leverages both domain knowledge (encoded in a model) and the rich data available in SE processes. ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
6
Pietrantuono et al.
Table 1. Examples of cause and effect variables, adapted from existing works [3, 9, 10, 27] System Microservice Architecture
Effect Performance metrics (e.g., mean response time, throughput)
Causes Request rate and type per service, CPU and memory usage per service, latency between services, service topology (invocation matrix), load balancing strategy, instance replication
Example Task Evaluate performance impact of different deployment and scaling configurations Autonomous Safety metrics (e.g., Weather conditions (rain, fog, snow), road type (urban, Generate Driving System minimum distance to rural, highway), ego vehicle speed, braking system safety-critical test pedestrian, response time, pedestrian behavior (speed, trajectory), cases for varying time-to-collision) sensor accuracy/degradation driving scenarios Loan Granting Fairness metrics (e.g., Applicant socio-economic features (e.g., job type, Assess and mitigate System Statistical Parity income, education), financial history, credit score, bias in loan approval Difference, Equal protected attributes (e.g., sex, race, age), decisions Opportunity Difference) decision-making policy thresholds
model is a mathematical representation of causal relationships within a system. There are two main approaches to causal modeling and inference: the potential outcomes framework, which frames causality in terms of what happened with what would have happened under an alternative condition; and graphical models, where relationships are expressed through directed acyclic graphs, with associated conditional probabilities (in causal Bayesian networks) or structural equations (in structural causal models) to specify how variables influence one another [17, 29]. We focus on graphical models in the description, though the core ideas generalize across formalisms. Input
Causal Engine
Output
Learning
Although there are many Causal Models Engineers & ways to instantiate a CSE solu(SCM/CBN/DAG/PO) Model Learning Domain Experts Specication tion for a specific problem, the … Observational / idea is that causal models should Experimental Data be at the core: they must be used Validation to drive and check the reasonEx ante Estimate more knowledge/data needed (Support design, testing, Proactive Inference ing process to solve the task rigperfective /adaptive mainten .) (what -if analysis ) Sw Engineering orously and transparently. RigEx post Estimate Task to solve Retroactive Inference (Support explanation , RCA, orously means capable of quan(Counterfactuals ) corrective maintenance ) tifying the causal effects along Conversational UI the whole reasoning chain and Human or AI Agent harnessing such estimates to give the best output (e.g., genFig. 1. The CSE conceptual framework erate safety tests more likely to cause a mishap). Transparently means giving inspectable evidence of the causal paths followed, along with the underpinning assumptions, constraints, and used sources of information, to justify the output for the required input, so that engineers are always kept in the loop and can challenge, refine, or override the reasoning when needed. In this paradigm, the causal model acts as a collaborative reasoning partner, not a black-box oracle: models help engineers reason more systematically, while engineers can encode those assumptions and constraints, such as required or forbidden causal links, that no automated method can reliably infer. There are two steps to implement a CSE solution (Figure 1): 1) How to construct a causal model (Learning); 2) How to query the built model (Inference). Inference
ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
Advancing SE through the Lens of Causation
7
4.1 Causal Model Learning Causal models can be specified i) manually by domain experts, ii) automatically from data (either observational or from controlled experiments), or iii) combining both approaches. Accordingly, the inputs to the model learning step system are a specification and/or data. In CSE, a specification encodes the explicit domain knowledge relevant to the task. This knowledge can be used to fully define a model or to refine and complement an existing model generated from data. In both scenarios, experts express assumptions through cause–effect relationships, declaring which relations must hold and which are impossible, defining the context within which causal reasoning is valid. This manual step embeds human understanding directly into the model, allowing engineers to shape and constrain the reasoning space according to their expertise. For instance, suppose we are designing or testing an emergency braking subsystem in an autonomous vehicle. A causal model is meant to help explore design alternatives and/or generate meaningful test cases that highlight a causal pathway from inputs to the possibly failing outputs. A domain expert may provide a causal model expressing key cause-effect relationships, such as: • Rain or fog ([Weather]) increases [Sensor Noise]; • Slippery road ([Road Surface]) increases [Braking Distance]; • High [Vehicle Speed] reduces [Object Detection Accuracy] due to motion blur; • Low [Object Detection Accuracy] may affect the [Braking Decision]. These expert-specified causal relations serve as an explicit, inspectable record of assumptions — something ML models do not provide. Modern LLMs can complement human knowledge by suggesting additional cause–effect variables or relationships and build causal models [21, 35]. Further variables or relations could be elicited by an LLM, for instance: • [Lighting Conditions] → [Sensor Noise]; • [Vehicle Load] → [Braking Distance]; • [Software Version] → [Braking Algorithm Latency] These relations, parameterised by data (see below), are then exploited in the inference phase (Sec. 4.2) to run queries and assess the causal effects of hypothetical interventions on variables. Data play a critical role in causal learning, in at least these ways: (1) Causal structure discovery methods can automatically extract cause–effect relationships from data, either entirely from observations or, more effectively, in combination with domain expertise expressed through a specification like above. Engineers can examine, validate, and revise these learned structures, closing the loop between automated discovery and human oversight. A variety of mature approaches exist [37], which are able to infer which variables influence others and in what direction. Importantly, modern solutions can learn causal structures not only from structured data (e.g., tabular monitoring metrics) but also from unstructured sources such as requirements, design documents, and natural-language logs, leveraging again LLMs to extract causal relationships directly from text [23]. Such capabilities make it possible to formalize any type of knowledge about the system or process into an explicit causal model. (2) Fitting. However the causal structure is obtained (from data or expert specification), data remain essential to quantify the relationships — for example, to parameterize structural equations in an SCM or conditional distributions in a CBN. (3) Validation. Data also enable validation of assumptions: if observations contradict a human-specified relation, the modeler can revisit whether the assumption is wrong or whether the data are simply insufficient [29]. ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
8
Pietrantuono et al.
4.2 Causal Inference With a model in hand, engineers can query it in a proactive mode — asking what-if questions — or retroactively through counterfactual what-would-have-happened-if questions, to simulate scenarios that may impact the effect variable(s) of interest. Continuing the self-driving car example, engineers can test What is the effect of a combined change in [Weather] and [Road Surface] on [Braking Distance]; How degraded [Object Detection Accuracy] affects [Braking Decision] under different [Vehicle Speeds]; or they can run counterfactual root cause analysis such as: Would a collision have been avoided if the [Software Version] had been different? As a further illustration, consider a microservice system where engineers aim to improve the [latency] of the Checkout service. A causal model, learned from monitoring data (logs, metrics, traces) and optionally refined by engineers, may relate latency to factors such as request rate, CPU and memory usage, inter-service latency (e.g., calls to Payment or Inventory), service topology (synchronous vs. asynchronous calls), load-balancing strategy, number of replicas. Typical dependencies might include: higher [request rate] → higher [CPU] → higher [latency]; more [replicas] → lower per-instance [CPU]; [load-balancing strategy] → [CPU] → [latency]. With such a model, engineers can pose what-if questions: What if we increase [replicas]? What if we change [load-balancing]? What if a synchronous call becomes asynchronous?, predicting causal effects on [latency]. Unlike ML dashboards, which can be distorted by confounding factors (e.g., “more replicas cause higher latency” simply because replicas increase under high load), a causal model supports true intervention analysis, helping engineers simulate actions, isolate confounders, and anticipate their impact. There are multiple ways to instantiate this step, depending on the task and the chosen causal reasoning framework. The most direct approach is to estimate the causal effect of action — either those to take or those that could have been taken — to support tasks such as performance prediction, test generation, or root cause analysis.7 With existing tools such as PyWhy,8 causal effect estimates can be produced with confidence intervals and validated through techniques like refutation tests. Alternatively, causal models can be combined with other reasoning components, such as LLMpowered AI agents capable of approximate reasoning [21, 24]. Recent work shows how a causal model can guide an LLM in generating performance-critical configurations for microservice testing [27]. In such setups, the causal model may inject causal knowledge into the LLM’s context or act as a consistency checker to ensure outputs respect established causal relations. In some settings, the aim is not to estimate causal effects but simply to uncover cause–effect relationships. For instance, in root cause analysis, causal models often help traverse the graph to identify likely failure causes, sometimes using heuristics such as weighted edges to approximate influence [39]. The instantiation of a CSE solution depends on several factors: the available inputs (specification and structured/unstructured data), the SE task, the type of causal model (from simple graphs to fully parameterized models), the chosen inference approach (effect estimation, attribution, counterfactuals, graph traversal), and whether it is combined with tools such as LLMs. We next review how causal methods are currently used in software engineering. 5 Where we are, what’s next 5.1 The growing footprint of Causal Reasoning in SE Recent review studies including our own [10, 32] show a growing academic interest in applying causal methods to SE, with more than 90 papers mapped across major digital libraries. With few 7 Guo et al. review and classify methods for estimating causal effects [11]. 8 https://www.pywhy.org/
ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
9
Fault l calizati n
41
4
2
3
Testing & analysis
12
1
2
3
Fault predicti n
7
KPI predicti n
5
6
An maly detecti n
1
2
1
1
30
1
20
1 1
3
1
10
2 1
Eff rt estimati n
1 1
0
Sa fet Ma y int ain ab ilit y Av ail ab ilit y Us ab ilit y Te sta bil ity Ot he rs
Re lia bil ity Pe rfo rm an ce Se cu rit y
Threats m deling
40
1
Paper c unt
Task
Advancing SE through the Lens of Causation
Attribute
Fig. 2. Causal methods in software engineering from the intersection of mapping studies [10, 32]
exceptions, most existing works can be viewed as instances of the CSE framework, typically applying a specific causal learning or inference method to an SE problem. These studies highlight the benefits of combining reasoning with data, especially when both causal discovery and inference are used. Main areas of application (Figure 2) include: (1) Fault localization: Causal graphs are used to model distributed systems and trace failure-propagation chains, especially in microservices. Most work focuses on learning causal structures (e.g., service-dependency graphs), while true causal inference – such as counterfactual root cause analysis — remains uncommon. Extracted graphs are often handed to ranking or graph-traversal algorithms, e.g., PageRank [39]. In debugging, however, causal inference is more prominent, with models derived from programs used for statistical fault localization and program repair [19]. (2) Testing is naturally causal: choosing an input implicitly involves predicting outcomes under hypothetical conditions. CSE operationalizes this reasoning. It has been applied to self-driving cars [9], microservices [8, 27], cyber-physical systems [7], and metamorphic testing [4]. (3) Prediction: Causal modeling enables predictions free from confounding, unlike correlational ML. Applications include estimating design factors (e.g., reuse success [22]), maintenance (refactoring) impact [12], fault prediction [14]. Although relatively few works implement a full discovery and inference pipeline, the range of causal applications is expanding. Opportunities also exist earlier in the lifecycle, such as requirements elicitation and design exploration, where what-if reasoning is highly valuable. Quality attributes. Most work targets reliability, some performance. Applications to security and safety remain rare, despite causal models’ explanatory power is potentially useful for certification. Tools. Causal discovery and inference tooling is maturing rapidly. The PyWhy ecosystem (e.g., causal-learn, dowhy, EconML), IBM’s SPSS Amos9 , and the Tetrad toolbox10 are notable examples. While these are general-purpose tools, the growth of CSE is likely to spur SE-specific extensions (e.g., for testing or debugging), and conversely, SE practices may help improve causal tooling, echoing the two-way synergy already observed between ML and SE. 5.2
Practical Challenges and Pathways to Adoption
Despite the promise shown in the literature, CSE is not yet ready to supplant today’s DDSE solutions. Its adoption in industry will depend on addressing several practical challenges 9 https://www.ibm.com/it-en/products/structural-equation-modeling-sem 10 https:///github.com/cmu-phil/tetrad
ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
10
Pietrantuono et al.
Expertise barriers. Although causal models are interpretable, using them effectively still requires familiarity with causal thinking and with some statistical foundations (e.g., structure discovery, model fitting, causal inference). Most engineering teams today have limited exposure to these concepts. Pathway to adoption. Promote incremental adoption through tools that scaffold causal thinking, such as PyWhy, supported by tutorials, examples, and domain-specific case studies. Data quality and models stability. As with ML, causal inference relies on data that sufficiently capture the relevant variables. Yet many SE datasets — logs, metrics, traces, issues, commits — are noisy, incomplete, sparse, or biased. Unlike physical systems, software behavior is driven by discrete events, rare failures, and non-stationary processes. Consequently, causal structures inferred purely from observational SE data can be unstable, limiting their generalizability. Pathway to adoption. Establish robustness checks and refutation tests as standard practice, a procedures still largely missing in today’s SE causal literature [16]. These include falsification tests, placebo tests (detecting effects where none should exist), subset refutation (testing consistency across time windows), simulated confounders (sensitivity to missing variables), and bootstrapping for stability assessment. Such practices, supported by libraries like DoWhy, are essential for determining whether causal conclusions are trustworthy enough for engineering use. Integration with existing workflows and tools. Most organizations depend on established CI/CD pipelines, observability stacks, testing frameworks, and debugging tools. Introducing causal models requires integration rather than replacement. Pathway to adoption. Develop CSE plug-ins for existing SE tools (e.g., test generators, performance profilers, failure analyzers) so causal reasoning enhances current practices. Like ML, causal reasoning consumes data, but it allows engineers to guide, constrain, and interpret outputs in causal terms. Positioning CSE as an augmentation layer atop mature ML tooling will significantly increase the likelihood of industrial adoption. Computational and tooling maturity. Although causal inference libraries are improving, they are not yet as turnkey, scalable, or optimized as mainstream ML toolkits. Inference can be computationally heavy, and automated discovery requires careful validation. Pathway to adoption. Invest in efficient, domain-specific, SE-tailored implementations, cloud-based causal services, and highlevel abstractions that hide complexity behind intuitive interfaces. Organizational resistance and cultural change. Adopting causal modeling requires a shift in how engineers reason about systems. Many teams, accustomed to correlational ML tools, may view causal modeling as too theoretical or demanding. Pathway to adoption. Highlight success stories and industrial case studies that show tangible benefits, e.g., in terms of fewer failures, more effective tests, clearer explanations. Demonstrated value will be key to cultural adoption. 5.3 Long-term evolution Reasoning- and data-driven integration. Beyond its immediate utility in SE tasks, CSE’s broader promise lies in integrating causal reasoning with data. This shift is already visible in research on LLMs’ emerging reasoning abilities [30] and in LLM-powered AI agents [24], enabling planning and improving explainability. As AI (multi)agent systems such as MetaGPT11 gain traction in software engineering, CSE is well positioned to support these emerging architectures. Logic besides statistics. While we assumed statistical causal inference, there are many flavours of causality. For instance, in law and forensic analysis, logic-based causality dominates, relying on formal rules and domain knowledge [21]. Linguistic causality — based on semantic relations in text — is also valuable, especially when working with natural-language artifacts such as requirements. A comprehensive CSE framework should treat these different forms of causality as first-class citizens. 11 https://github.com/FoundationAgents/MetaGPT
ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
Advancing SE through the Lens of Causation
11
Human in-the-loop. One key strength of causal models is their interpretability, making CSE naturally suited for human-machine co-design. Inspectable models support grounded, trustworthy responses, and experts can refine them by adding or removing causal links. In CSE, engineers are collaborators rather than spectators; we depart from any “push-button” vision of fully autonomous SE, as trustworthy systems cannot be built without humans in the loop. Ethical concerns around AI must not be overlooked. Beyond well-known issues (e.g., safety, privacy, fairness) now under regulatory scrutiny, a subtler risk is the erosion of human judgment and creativity as AI systems grow more capable. In SE, powerful assistants may marginalize human decision-making. An emerging counterpoint is the view of AI as a provocateur rather than a servant [31]: a partner that challenges assumptions, surfaces biases, and stimulates critical thinking. The transparency of causal models naturally supports this reflective engagement. We fully embrace this view: AI can augment human intelligence only when humans remain actively involved.
ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
12
Pietrantuono et al.
References [1] Sebastian Baltes, Timo Speith, Brenda Chiteri, Seyedmoein Mohsenimofidi, Shalini Chakraborty, and Daniel Buschek. 2026. On the Need to Rethink Trust in AI Assistants for Software Development: A Critical Review. IEEE Transactions on Software Engineering (2026), 1–18. https://doi.org/10.1109/TSE.2026.3659804 [2] Sándor Battaglini-Fischer, Nishanthi Srinivasan, Bálint László Szarvas, Xiaoyu Chu, and Alexandru Iosup. 2025. FAILS: A Framework for Automated Collection and Analysis of LLM Service Incidents. In Companion of the 16th ACM/SPEC International Conference on Performance Engineering (ICPE ’25). ACM, 187–194. https://doi.org/10.1145/3680256.3721320 [3] Zhenpeng Chen, Jie M. Zhang, Max Hort, Mark Harman, and Federica Sarro. 2024. Fairness Testing: A Comprehensive Survey and Analysis of Trends. ACM Trans. Softw. Eng. Methodol. 33, 5, Article 137 (June 2024), 59 pages. https://doi.org/10.1145/3652155 [4] Andrew G. Clark, Michael Foster, Neil Walkinshaw, and Robert M. Hierons. 2023. Metamorphic Testing with Causal Graphs. In 2023 IEEE Conference on Software Testing, Verification and Validation (ICST). 153–164. https://doi.org/10.1109/ICST57152.2023.00023 [5] Cloud Native Computing Foundation (CNCF) and Linux Foundation Research. 2023. CNCF Annual Survey 2023. Technical Report. Linux Foundation Research. https://www.cncf.io/reports/cncf-annual-survey-2023/ Accessed: 2026-0316.. [6] Cloud Native Computing Foundation (CNCF) and Linux Foundation Research. 2025. CNCF Annual Survey 2024. Technical Report. Linux Foundation Research. https://www.cncf.io/wp-content/uploads/2025/04/cncf_annual_survey24_031225a.pdf Accessed: 2026-03-16. Report presenting results of the 2024 CNCF Annual Survey.. [7] Michael Foster, Robert M. Hierons, Donghwan Shin, Neil Walkinshaw, and Christopher Wild. 2025. Using causal inference to test systems with hidden and interacting variables: an evaluative case study. In 29th International Conference on Evaluation and Assessment in Software Engineering (EASE 2025). ACM. https://doi.org/10.1145/3756681.3756967 [8] Luca Giamattei, Antonio Guerriero, Ivano Malavolta, Cristian Mascia, Roberto Pietrantuono, and Stefano Russo. 2024. Identifying Performance Issues in Microservice Architectures through Causal Reasoning. In 2024 IEEE/ACM International Conference on Automation of Software Test (AST). 149–153. [9] Luca Giamattei, Antonio Guerriero, Roberto Pietrantuono, and Stefano Russo. 2024. Causality-driven Testing of Autonomous Driving Systems. ACM Transactions on Software Engineering and Methodology 33, 3, Article 74 (2024). https://doi.org/10.1145/3635709 [10] Luca Giamattei, Antonio Guerriero, Roberto Pietrantuono, and Stefano Russo. 2025. Causal reasoning in Software Quality Assurance: A systematic review. Information and Software Technology 178 (2025), 107599. https://doi.org/10.1016/j.infsof.2024.107599 [11] Ruocheng Guo, Lu Cheng, Jundong Li, P. Richard Hahn, and Huan Liu. 2020. A Survey of Learning Causality with Data: Problems and Methods. Comput. Surveys 53, 4, Article 75 (2020), 37 pages. https://doi.org/10.1145/3397269 [12] Oumayma Hamdi, Ali Ouni, Eman Abdullah AlOmar, Mel Ó Cinnéide, and Mohamed Wiem Mkaouer. 2021. An Empirical Study on the Impact of Refactoring on Quality Metrics in Android Applications. In 2021 IEEE/ACM 8th International Conference on Mobile Software Engineering and Systems (MobileSoft). 28–39. https://doi.org/10.1109/MobileSoft52590.2021.00010 [13] Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large Language Models for Software Engineering: A Systematic Literature Review. ACM Trans. Softw. Eng. Methodol. 33, 8, Article 220 (Dec. 2024), 79 pages. https://doi.org/10.1145/3695988 [14] Yamin Hu, Wenjian Luo, and Zongyao Hu. 2023. A practical approach to explaining defect proneness of code commits by causal discovery. Engineering Applications of Artificial Intelligence 123 (2023), 106187. https://doi.org/10.1016/j.engappai.2023.106187 [15] Kaicheng Huang, Fanyu Wang, Yutan Huang, and Chetan Arora. 2025. Prompt Engineering for Requirements Engineering: A Literature Review and Roadmap . In 33rd International Requirements Engineering Conference Workshops. IEEE, Los Alamitos, CA, USA, 548–557. https://doi.org/10.1109/REW66121.2025.00081 [16] Jeremy Hulse, Nasir U. Eisty, and Tim Menzies. 2025. Shaky structures: The wobbly world of causal graphs in software analytics. Empirical Software Engineering 30, 5 (2025), 142. https://doi.org/10.1007/s10664-025-10690-6 [17] Guido W. Imbens. 2020. Potential Outcome and Directed Acyclic Graph Approaches to Causality: Relevance for Empirical Practice in Economics. Journal of Economic Literature 58, 4 (2020), 1129–79. https://doi.org/10.1257/jel.20191597 [18] Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. 2025. A Survey on Large Language Models for Code Generation. ACM Trans. Softw. Eng. Methodol. (2025). https://doi.org/10.1145/3747588 [19] Brittany Johnson, Yuriy Brun, and Alexandra Meliou. 2020. Causal testing: understanding defects’ root causes. In 2020 ACM/IEEE 42nd International Conference on Software Engineering (ICSE) (Seoul, South Korea). ACM, 87–99. https://doi.org/10.1145/3377811.3380377
ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
Advancing SE through the Lens of Causation
13
[20] Dipin Khati, Yijin Liu, David N. Palacio, Yixuan Zhang, and Denys Poshyvanyk. 2025. Mapping the Trust Terrain: LLMs in Software Engineering - Insights and Perspectives. ACM Trans. Softw. Eng. Methodol. (2025). https://doi.org/10.1145/3771282 [21] Emre Kiciman, Robert Ness, Amit Sharma, and Chenhao Tan. 2025. Causal Reasoning and Large Language Models: Opening a New Frontier for Causality. Transactions on Machine Learning Research (2025), 2835–8856. https://openreview.net/forum?id=mqoxLkX210 [22] Gang Li and Honghua Dai. 2004. What will affect software reuse: A causal model analysis. International Journal of Software Engineering and Knowledge Engineering 14, 03 (2004), 351–364. https://doi.org/10.1142/S021819400400166X [23] Chenxi Liu, Yongqiang Chen, Tongliang Liu, Mingming Gong, James Cheng, Bo Han, and Kun Zhang. 2024. Discovery of the Hidden World with Large Language Models. In 38th Annual Conference on Neural Information Processing Systems. https://openreview.net/forum?id=w50ICQC6QJ [24] Xiaoyu Liu, Paiheng Xu, Junda Wu, Jiaxin Yuan, Yifan Yang, Yuhang Zhou, Fuxiao Liu, Tianrui Guan, Haoliang Wang, Tong Yu, Julian McAuley, Wei Ai, and Furong Huang. 2025. Large Language Models and Causal Inference in Collaboration: A Comprehensive Survey. In Findings of the Association for Computational Linguistics: NAACL 2025, Luis Chiruzzo, Alan Ritter, and Lu Wang (Eds.). ACL, Albuquerque, New Mexico, 7668–7684. https://doi.org/10.18653/v1/2025.findings-naacl.427 [25] Yacine Majdoub and Eya Ben Charrada. 2024. Debugging with Open-Source Large Language Models: An Evaluation. In Proceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (Barcelona, Spain) (ESEM ’24). Association for Computing Machinery, New York, NY, USA, 510–516. https://doi.org/10.1145/3674805.3690758 [26] Silverio Martínez-Fernández, Justus Bogner, Xavier Franch, Marc Oriol, Julien Siebert, Adam Trendowicz, Anna Maria Vollmer, and Stefan Wagner. 2022. Software Engineering for AI-Based Systems: A Survey. ACM Trans. Softw. Eng. Methodol. 31, 2, Article 37e (April 2022), 59 pages. https://doi.org/10.1145/3487043 [27] Cristian Mascia, Antonio Guerriero, Luca Giamattei, Roberto Pietrantuono, and Stefano Russo. 2025. Microservices Performance Testing with Causality-enhanced Large Language Models. In 2025 IEEE/ACM Second International Conference on AI Foundation Models and Software Engineering (Forge). 136–140. https://doi.org/10.1109/Forge66646.2025.00022 [28] Bhuwan Paudel, Javier Gonzalez-Huerta, and Ehsan Zabardast. 2026. Temporal Evolution of Architectural Complexity and Technical Debt in Microservices: An Exploratory Case Study. In Product-Focused Software Process Improvement, Giuseppe Scanniello, Valentina Lenarduzzi, Simone Romano, Sira Vegas, and Rita Francese (Eds.). Springer Nature Switzerland, Cham, 285–302. [29] Judea Pearl and Dana Mackenzie. 2018. The Book of Why: The New Science of Cause and Effect (1st ed.). Basic Books, Inc., USA. [30] Aske Plaat, Annie Wong, Suzan Verberne, Joost Broekens, Niki Van Stein, and Thomas Bäck. 2025. Multi-Step Reasoning with Large Language Models, a Survey. ACM Comput. Surv. 58, 6, Article 160 (Dec. 2025), 35 pages. https://doi.org/10.1145/3774896 [31] Advait Sarkar. 2024. AI Should Challenge, Not Obey. Commun. ACM 67, 10 (Sept. 2024), 18–21. https://doi.org/10.1145/3649404 [32] Julien Siebert. 2023. Applications of Statistical Causal Inference in Software Engineering. Information and Software Technology 159, C (2023), 16 pages. https://doi.org/10.1016/j.infsof.2023.107198 [33] Alex Singla, Alexander Sukharevsky, Lareina Yee, and Michael Chui. 2024. The State of AI in Early 2024: Gen AI Adoption Spikes and Starts to Generate Value. McKinsey & Company. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-2024 Accessed: 2026-03-16.. [34] Jiessie Tie, Bingsheng Yao, Tianshi Li, Hongbo Fang, Syed Ishtiaque Ahmed, Dakuo Wang, and Shurui Zhou. 2026. "Should I Give Up Now?" Investigating LLM Pitfalls in Software Engineering. ACM Trans. Softw. Eng. Methodol. (March 2026). https://doi.org/10.1145/3801972 [35] Guangya Wan, Yunsheng Lu, Yuqi Wu, Mengxuan Hu, and Sheng Li. 2025. Large language models for causal discovery: current landscape and future directions. In 34th International Joint Conference on Artificial Intelligence (Montreal, Canada) (IJCAI ’25). Article 1186, 9 pages. https://doi.org/10.24963/ijcai.2025/1186 [36] Junjie Wang, Yuchao Huang, Chunyang Chen, Zhe Liu, Song Wang, and Qing Wang. 2024. Software Testing With Large Language Models: Survey, Landscape, and Vision. IEEE Transactions on Software Engineering 50, 4 (2024), 911– 936. https://doi.org/10.1109/TSE.2024.3368208 [37] Lei Wang, Shanshan Huang, Shu Wang, Jun Liao, Tingpeng Li, and Li Liu. 2024. A survey of causal discovery based on functional causal model. Engineering Applications of Artificial Intelligence 133 (2024), 108258. https://doi.org/10.1016/j.engappai.2024.108258 [38] Simin Wang, Liguo Huang, Amiao Gao, Jidong Ge, Tengfei Zhang, Haitao Feng, Ishna Satyarth, Ming Li, He Zhang, and Vincent Ng. 2023. Machine/Deep Learning for Software Engineering: A Systematic Literature Review. IEEE ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.
14
Pietrantuono et al.
Transactions on Software Engineering 49, 3 (2023), 1188–1231. https://doi.org/10.1109/TSE.2022.3173346 [39] Li Wu, Johan Tordsson, Erik Elmroth, and Odej Kao. 2021. Causal Inference Techniques for Microservice Performance Diagnosis: Evaluation and Guiding Recommendations. In IEEE International Conference on Autonomic Computing and Self-Organizing Systems (ACSOS). IEEE, 21–30. https://doi.org/10.1109/ACSOS52086.2021.00029 [40] Quanjun Zhang, Chunrong Fang, Yang Xie, Yuxiang Ma, Weisong Sun, Yun Yang, and Zhenyu Chen. 2026. A Systematic Literature Review on Large Language Models for Automated Program Repair. ACM Trans. Softw. Eng. Methodol. (March 2026). https://doi.org/10.1145/3799693
Received June 29, 2026
ACM Accepted, Vol. 1, No. 1, Article . Publication date: June 2026.