PaperlayerView exact revision on arXiv

Source-linked AI summary

Artificial Intelligence for Software Architecture: Literature Review and the Road Ahead

Alessio Bucaioni, Martin Weyssow, Junda He, Yunbo Lyu, David Lo

arXiv:2504.04334v2cs.SE

TL;DR

AI's explicit role in software architecture remains limited despite the field's manual, trade-off-intensive work. This paper reviews 51 primary studies, maps their contributions to practitioner-reported challenges, and finds a mismatch between current AI capabilities and evolving architectural needs, distilling six AI-specific challenges.

  • Problem

    AI's explicit use in software architecture remains sparse, while architectural work requires manual, sustained reasoning about complex trade-offs and long-term concerns.

    Source: §1 · p. 1

  • Method

    The paper synthesizes 51 primary studies and maps their findings to practitioner-reported software-architecture challenges to identify AI-specific research gaps.

    Source: §10 · p. 32

  • Results

    Current AI contributions are fragmented and often limited to static, one-off recommendations or narrow settings, unlike practitioners' needs for evolving, trustworthy support.

    Source: §7 · p. 26, §10 · p. 32

  • Takeaways & Limitations

    The six AI-specific challenges point toward adaptive learning, system-wide reasoning, and contextualized, human-centred collaboration.

    Source: §10 · p. 32

    The search strategy may miss work that uses emerging techniques without labeling them AI, and the review excludes software architecture for AI systems.

    Source: §7.4 · p. 28, §8 · p. 29

Abstract

from arXiv · show

Artificial intelligence is increasingly applied across software engineering, yet its explicit role in software architecture remains insufficiently understood. Architectural practices rely on complex trade-offs, documentation, and long-term evolution, all of which are traditionally manual, error-prone, and difficult to sustain. To clarify how artificial intelligence can address these challenges, we conducted a systematic literature review of 51 peer-reviewed primary studies and systematically mapped their contributions onto 17 practitioner-reported software architecture challenges derived from empirical interviews. This analysis identifies 14 topical areas where artificial intelligence has been applied to architectural tasks and identifies six artificial intelligence-specific challenges that expose fundamental gaps between current capabilities and practitioner needs. Building on these findings, we chart a research agenda for artificial intelligence-driven software architecture organized around five strategic pillars. By grounding the roadmap in both systematic evidence and practitioner insights, this work provides the first peer-reviewed comprehensive synthesis of artificial intelligence contributions to software architecture, establishes a foundation for future research, and outlines the conditions under which artificial intelligence can become a trustworthy partner in architectural design, evaluation, and evolution.

1 Introduction

AI has transformed code-level software engineering, but its explicit use in software architecture remains sparse despite the complexity and long-term importance of architectural work. The paper reviews AI applications, maps them to practitioner-reported challenges, and proposes an AI-for-software-architecture roadmap.

1 Introduction

  • AI use in software architecture remains sparse compared with its documented impact on code-level tasks, despite architecture's role as a system blueprint.Early work applies AI to derive partial designs, analyze trade-offs, and prioritize quality attributes, but current techniques struggle with abstraction, long-term reasoning, and conflicting attributes [P2, P20, P26, P34].Source: §1 · pp. 1–2
  • Architectural practice remains manual and experience-driven, requiring sustained reasoning about trade-offs among qualities such as performance, security, and reliability.Short-term time-to-market pressures can undervalue architecture, while neglecting it compromises long-term quality and maintainability.Source: §1 · pp. 1–2
  • The paper asks how AI can address architectural-task difficulties without oversimplifying architecture's complexity.The authors argue that AI-enhanced architecture should follow a sober assessment of challenges rather than fear of missing out.Source: §1 · p. 2
  • The review identifies 14 AI practices, maps them to 32 practitioner-elicited challenges, identifies six AI-specific challenges, and proposes five research directions.The roadmap focuses on AI support for architecture practice and complements broader software-architecture roadmaps.Source: §1 · p. 2

2 Research Process

The research process combines a systematic literature review with practitioner-derived architecture challenges, then uses qualitative synthesis and structured mapping to identify AI contributions and remaining gaps.

2 Research Process

  • The two-phase process reviews AI applications in software architecture, then synthesizes review findings with open practitioner challenges to derive AI-specific gaps and a research vision.The review follows software-engineering secondary-study guidance and documents planning, conducting, and reporting phases.Source: §2 · pp. 2–3

2.1 Research Goal

  • The research goal uses GQM to frame questions about AI techniques and applications across architectural activities and the academic and industrial perspectives.Its scope extends beyond runtime adaptation to contemporary AI techniques supporting architecture across the lifecycle.Source: §2.1 · p. 3

2.2 Search and selection

  • The search queried four major databases with a deliberately simple AI-and-software-architecture string, then applied inclusion and exclusion criteria, venue screening, and snowballing.The process yielded 76 studies before data extraction; the search covered 2019 through August 2025.Source: §2.2 · pp. 3–4

2.3 Data extraction, analysis and synthesis

  • Grounded-theory analysis used inductive open coding, iterative axial coding, and traceability to source studies to synthesize recurring patterns and gaps.Studies without extractable relevant information were removed, leaving 51 primary studies.Source: §2.3 · p. 5

2.4 Integration of open software architecture challenges

  • The authors refined challenges from interviews with 32 practitioners [25], mapped review topics using direct or inferential evidence, and withheld speculative mappings.They assessed full, partial, or absent coverage, formulated AI-specific challenges for remaining gaps, and validated mappings through author consensus; multiple AI practices could map to one challenge.Source: §2.4 · pp. 5–6

3 Review Synthesis: The Current State of Artificial Intelligence in Software Architecture

The review organizes the interplay between AI and software architecture into three thematic clusters, while focusing its detailed analysis on AI for architecture design and decision-making and AI for architecture evolution and adaptation.

3 Review Synthesis: The Current State of Artificial Intelligence in Software Architecture

  • The review identifies three clusters: AI for architecture design and decision-making, AI for architecture evolution and adaptation, and architecture for AI systems.The analysis focuses on the first two clusters and briefly discusses the third elsewhere.Source: §3 · p. 6, Table 3 · p. 6
  • For each primary study, the synthesis records its AI technique, architectural task, and reported evaluation, validation, or deployment, avoiding speculation where details are absent.A separate subsection later presents real-world examples drawn from primary studies [p68].Source: §3 · p. 6

3.1 C1 - AI for Architecture Design and Decision-Making

AI supports architectural design and decision-making as both a reasoning aid and a medium for representing reusable knowledge, but reliability, evaluation, workflow integration, and trust remain concerns.

3.1.1 T1 - AI-Assisted Architecture Design.

  • LLMs can recover documentation-to-code traceability links and generate viable serverless components with context-rich prompts, while human review remains necessary for component quality.Transformer models have also been applied to identify technical debt and defects as inputs to architectural decision-making [P38].Source: §3.1.1 · pp. 7–8
  • AI-assisted design ranges from generating architecture candidates and requirements-derived models to pattern recommendations, microservice decomposition, and LLM-supported architectural reasoning.Reported examples include 70% accuracy for a three-pattern model [P16] and approximately 75% recall across four projects for deriving responsibilities and Use Case Maps [P21].Source: §3.1.1 · pp. 7–8

3.1.2 T2 - AI-Assisted Design Pattern Recognition.

  • Programming language models can detect Singleton implementations without relying explicitly on naming conventions, but results vary across models and example rankings are inconsistent [P14].The study calls for broader benchmarks beyond one pattern and one programming language.Source: §3.1.2 · p. 8

3.1.3 T3 - AI-Assisted Design Decision Analysis.

  • LLMs can generate candidate architectural decisions from ADR contexts, but outputs remain sub-human in completeness; AI-PAG structures adoption knowledge and improved adequacy assessments and confidence in an industrial application [P10, P6].The ADR study compared prompting and fine-tuning configurations, while AI-PAG records existing knowledge, adoption stages, and next steps.Source: §3.1.3 · p. 8, §3.1.4 · p. 8

3.1.4 T4 – AI Knowledge Representation.

  • A foundation-model architecture taxonomy organizes decisions by training and adaptation, model- and system-level options, and responsible-AI measures, while surfacing cost, accuracy, and trustworthiness trade-offs [P8].The reviewed knowledge-representation contributions lack large-scale evaluation in diverse industrial settings.Source: §3.1.4 · pp. 8–9

3.1.5 T5 - AI-Assisted Design Decision and Decision-Making.

  • Decision-support approaches learn preferences to reduce fatigue, guide prompt-based recommendations, generate architectural knowledge from distributed artifacts, compare trade-offs, and adapt policies as systems evolve [P31, P35, P37, P40, P27, P29].Across these approaches, integration into organizational workflows and trust and explainability remain open challenges.Source: §3.1.5 · p. 9

3.2 C2-AI for Architecture Evolution and Adaptation

AI supports architectural evolution through adaptation, recovery, resource management, performance estimation, resilience, and quality-attribute work. The reviewed approaches include concrete gains, but remain bounded by domain, deployment scale, uncertainty, or operational trade-offs.

3.2.1 T6 - ML Component Adaptation.

  • ML-DEECo makes estimators first-class architectural abstractions, automatically training them at runtime to predict resource needs and support adaptive coordination.In a simulated smart-farming case study, drone ensembles used predictions to coordinate charging, reducing crop damage and improving resilience; validation remains limited to one domain.Source: §3.2.1 · p. 10

3.2.2 T7 - AI-Assisted Architecture Recovery and Reverse Engineering.

  • Architecture recovery combines SDK heuristics with clustering to detect mobile-app layers and inconsistencies, while package ranking supports technology selection; both remain domain-specific and need broader recovery-pipeline integration.The mobile tool checks dependency graphs against architectural rules in CI/CD; the package recommender learns from community-project features. Kubernetes evaluation also reports up to 34% lower container deployment times and more accurate forecasts than ARIMA and Holt-Winters.Source: §3.2.2 · p. 10, §3.2.3 · p. 10

3.2.3 T8 - AI-Assisted Resource Management.

  • The Design Engineering Assistant combines knowledge graphs, NLP, and reasoning to provide spacecraft feasibility recommendations with explicit confidence levels.Evaluation reports improved efficiency through reuse of historical data and enhanced trust, but transfer to general software architecture remains unvalidated.Source: §3.2.4 · pp. 10–11

3.2.4 T9 - AI-Assisted Performance Estimation.

  • Hyperautomation produced higher productivity than traditional automation, but also increased maintenance costs and raised interoperability, ROI-measurement, and human-oversight challenges.The framework combines RPA with AI and process automation to identify opportunities, generate artifacts, and optimize processes.Source: §3.2.5 · p. 11

3.2.5 T10 - AI-Enabled Industrial Automation.

  • Reinforcement-learning agents outperformed random fault injection in identifying critical faults; DQN was most stable, while PPO had greater potential but less predictability.The evidence comes from simulated client–server and peer-to-peer systems.Source: §3.2.6 · p. 11

3.2.6 T11 - AI-Assisted Resilience.

  • Studies in this area explore AI for improving quality attributes, particularly in microservices and ML-enabled environments.The supplied overview identifies the area but does not specify a distinct result for it.Source: §3.2.7 · p. 11

3.2.7 T12 - AI-Assisted QAs.

  • In microservices and ML-enabled systems, AI approaches target proactive quality improvement and expose trade-offs such as efficiency versus reliability and accuracy versus explainability.Reported tactics include cloud deployment, containerization, bias mitigation, and human-in-the-loop strategies; the synthesis notes ongoing explainability and operational-integration challenges.Source: §3.2.7 · pp. 11–12

3.3 Real-World Applications of Artificial Intelligence in Software Architecture

Evidence of real-world grounding ranges from industrial deployments to constrained testbeds and academic demonstrations. The reviewed studies show applied potential, but validation depth varies substantially across topics.

3.3 Real-World Applications of Artificial Intelligence in Software Architecture

  • Industrial examples include automotive design-pattern recognition, aerospace performance estimation, cyber-physical resilience analysis, and case studies of quality trade-offs in AI-enabled systems.These cases span safety-critical embedded software, early design, smart grids, healthcare, and autonomous driving, while solutions remain domain-specific.Source: §3.3 · p. 12
  • Constrained but realistic validation includes industrial-partner adequacy assessments, mobile architecture checkers, large-scale package recommendations, Kubernetes testbeds, and studies on microservices and serverless systems.The review characterizes these efforts as applied evidence that remains short of full industrial adoption.Source: §3.3 · p. 12
  • Many design-generation, decision-support, knowledge-management, and design-comparison approaches are evaluated mainly on curated benchmarks, constructed examples, or academic case studies.The review notes that longitudinal deployment evidence is still absent for some exploratory work.Source: §3.3 · p. 12
  • Real-world grounding varies widely: some studies report industrial validation, others use realistic but constrained testbeds, and many remain academic or illustrative.The review places industrial evidence at one end, curated or constructed evaluations at the other, and applied testbeds between them.Source: §3.3 · pp. 12–13

4 AI-Specific Challenges in Software Architecture

The review maps AI practices to practitioner-reported software architecture challenges and identifies six AI-specific gaps. Together, these gaps point to fragmented, often static AI support that does not yet match architecture’s contextual and longitudinal demands.

4 AI-Specific Challenges in Software Architecture

  • Mapping AI practices against 17 practitioner-derived challenges links current contributions to unresolved gaps and frames six AI-specific challenges.The mapping is presented as a bridge between empirical practitioner needs and the research landscape.Source: §4 · p. 13, Table 4 · p. 14

4.1 AICH1 - Develop adaptive and continuously updated recommendations

  • AICH1 calls for recommendations that adapt continuously as requirements, contexts, and operational evidence change, rather than requiring reruns, prompt redesign, or retraining.Current approaches commonly reason from static inputs and rarely incorporate continuous feedback from evolving systems.Source: §4.1 · pp. 14–15

4.2 AICH2 - Ensure continuous traceability and alignment between evolving systems and documentation

  • AICH2 calls for continuous, bidirectional traceability between system evolution and architectural documentation, moving beyond static knowledge representations and snapshot reconstructions.Practitioners report that documentation can become obsolete within a few sprints and then be neglected.Source: §4.2 · p. 15

4.3 AICH3 - Develop context-aware reasoning

  • AICH3 calls for context-aware reasoning that connects architectural structures to semantics, trade-offs, domain knowledge, and changing business, technical, and quality constraints.Existing approaches can suggest boundaries or recognize structures yet remain detached from broader system and organizational context.Source: §4.3 · pp. 15–16

4.4 AICH4 - Incorporate domain-specific expertise and contextual knowledge into AI-supported reviews

  • AICH4 calls for architecture reviews that combine automated analysis with elicited domain expertise to assess decisions within organizational, technical, and regulatory contexts.Current tools may produce plausible suggestions or consistent prompts without grounding them in system realities or stakeholder priorities.Source: §4.4 · p. 16

4.5 AICH5 - Develop adaptive, evidence-based quantitative measures of architectural quality

  • AICH5 calls for adaptive, evidence-based measures that evolve with systems and unify performance, resilience, quality attributes, and conformance into continuous architectural-health insights.Current methods remain fragmented and domain-specific; predictors may depend on historical workloads, and recovery tools can struggle with outdated documentation.Source: §4.5 · pp. 16–17

4.6 AICH6 - Integrate long-term evolution and debt management into AI-supported recommendations

  • AICH6 calls for AI-supported recommendations that integrate longitudinal evidence about smells, debt accumulation, and erosion rather than treating problems as isolated snapshots or decisions.The challenge extends the critique of static reasoning to the historical trajectory and long-term health of a system.Source: §4.6 · p. 17

5 Mainstream AI-supported tools for SA: intelligence levels and coverage of identified challenges

The review uses a time-bound snapshot of mainstream architectural tools to assess their intelligence support and partial coverage of practitioner challenges. Intelligence is unevenly distributed: bounded operational and governance tasks receive more support than context-aware, lifecycle-wide reasoning.

5.1 Illustrative selection and intelligence levels

  • The tool snapshot was illustrative, not exhaustive or a vendor comparison; ISL classifies support from documented capabilities rather than ranking individual products.The five ISL levels range from no intelligence support to generative or agentic intelligence.Source: §5.1 · p. 18
  • Observability tools provide mature runtime analytics, while copilots and static-analysis platforms automate bounded code and policy tasks without lifecycle-wide reasoning.Runtime insights remain siloed from architectural models; local code and rule-based support does not aggregate system-wide erosion or debt.Source: §5.1 · pp. 18–20

5.2 Mainstream AI-supported tools coverage of SACHs

  • Mainstream tools concentrate intelligence in operational and governance domains, while systemic and longitudinal architectural concerns remain weakly addressed.Coverage across the 17 SACHs is uneven rather than uniform.Source: §5.2 · p. 20
  • Support is strongest for measurement and monitoring, but documentation traceability, cross-layer reasoning, and architectural debt aggregation remain limited.Generative change support is reactive, while governance and conformance tooling is predominantly local and checklist-oriented.Source: §5.2 · pp. 20–21

5.3 Implications of Mainstream Tool Coverage for AICHs and the AI4SA Vision

  • Mainstream tools automate bounded workflow tasks but generally do not connect architectural intent and decisions to evolving implementations and runtime evidence.The coverage analysis therefore reinforces the six AI-specific challenges identified by the review.Source: §5.3 · p. 21
  • Across tool categories, intelligence remains local and reactive; lifecycle-wide traceability, context-aware reasoning, and longitudinal erosion modelling are weakly represented.The distribution of support empirically reinforces the need for AICH1–AICH6 and the AI4SA research pillars.Source: §5.3 · p. 21

6 The Road Ahead: Charting a Vision for Artificial Intelligence-Driven Software Architecture

The roadmap organizes research toward trustworthy AI-driven software architecture in dependent phases, from foundational data and metrics to evolving intelligence, collaboration, and industrial validation. It envisions an evidence-grounded system that evolves with software while keeping architects responsible for strategic judgment.

6 The Road Ahead: Charting a Vision for Artificial Intelligence-Driven Software Architecture

  • The roadmap sequences six strategic pillars into dependent phases to move fragmented, reactive AI applications toward a trustworthy partner in architectural design, evaluation, and evolution.The phases connect current research gaps with the long-term goal of reliable and integral AI support.Source: §6 · p. 22
  • The foundation requires living architectural knowledge integrating project data, standardized benchmarks and datasets, and validated quantitative measures of complex qualities.The measures should extend beyond simple code metrics to qualities such as maintainability and resilience.Source: §6 · p. 22

6.1 The Self-Evolving Architectural Intelligence

  • Self-evolving architectural intelligence would continuously monitor systems, synthesize new information, and make proactive decisions using the foundational data and metrics.The proposed loop integrates runtime, repository, requirements, and other signals into knowledge for quantitative trade-off reasoning and recommendations.Source: §6 · p. 22, §6.1 · pp. 23–24
  • Realizing that loop requires scalable analysis, reliable AI decisions, trustworthy architecture models, and actionable metrics for qualities such as evolvability, resilience, and modularity.Large, dynamic repositories make detecting architecturally significant changes efficiently and controlling analysis cost and latency a central challenge.Source: §6.1 · p. 24

6.2 Human-AI Collaborative Architecting

  • The collaboration model assigns AI the chief-analyst role and architects the chief-strategist role, with explainable recommendations subject to human scrutiny and contextual judgment.Architects can critique AI conclusions, add domain expertise, and reprioritize objectives.Source: §6.2 · p. 25

6.3 Benchmarks, Datasets, and Industrial Adoption

  • Credibility and adoption depend on reproducible evaluation and industrial validation, but standardized lifecycle datasets and industrial-scale validation remain scarce.The proposed evaluation should assess generalizability, drift robustness, and effects on human decision-making in real-world workflows.Source: §6.3 · p. 25

7 Discussion

The discussion positions AI4SA as complementary to earlier self-adaptive roadmaps, extending attention from runtime control toward lifecycle-wide architectural reasoning. It highlights practical priorities and scope boundaries, including the distinct but complementary field of architecture for AI systems.

7 Discussion

  • Current AI contributions are fragmented and reactive: bounded tasks can yield efficiency gains, but broader contextual and long-term practitioner concerns remain under-addressed.Most design automation and decision-support approaches remain academic prototypes, while industrial validation is concentrated in a few areas.Source: §7 · p. 26

7.1 Positioning AI4SA with respect to previous roadmaps

  • AI4SA complements self-adaptive systems roadmaps by shifting emphasis from programmed runtime control toward lifecycle-wide reasoning, including traceability, trade-offs, and long-term evolution.The review maps 12 AI usage patterns against 17 empirically derived practitioner challenges.Source: §7.1 · p. 26
  • The study frames its Ts, SACHs, and AICHs as synthesis abstractions: current AI operationalizations, practitioner needs, and recurring barriers, respectively.Examples of AI-specific barriers include continuous traceability, context-aware architectural reasoning, and longitudinal erosion evidence.Source: §7.1 · pp. 26–27

7.2 Implications for research and practice

  • Research priorities include adaptive recommendations, living traceability, context-aware reasoning, evidence-based quality measures, and long-term evolution support, with realistic validation and human scrutiny also needed.Practitioner evidence is strongest where problems are well-defined and quality attributes measurable; early design and strategic decision analysis remain poorly supported.Source: §7.2 · p. 27

7.4 Limitations and complementary perspective on SA4AI

  • The review may omit studies that do not use the term AI, excludes detailed analysis of software architecture for AI systems, and acknowledges interpretive variation in mapping challenges to contributions.The search included work through August 2025 and manual checks in leading architecture venues, but possible omissions remain.Source: §7.4 · p. 28
  • AI4SA and SA4AI address different questions: applying AI to architectural work versus architecting AI systems, with potential for cross-fertilization.SA4AI research includes reference architectures, responsible and explainable AI, domain-specific architectures, AI pipelines, and human–AI collaboration.Source: §7.4 · p. 28

8 Threats to validity

The review addresses threats to external, internal, construct, and conclusion validity, as well as reliability and researcher bias. Mitigations include broad searches, shared coding and mapping, and a replication package, but tool selection and some interpretations remain bounded by the study design.

External validity

  • Peer-reviewed-only coverage may omit recent AI-for-architecture work first shared as preprints or technical reports.The review searched four databases, manually checked ICSA and ECSA proceedings through August 2025, and used snowballing, but acknowledges this completeness risk.Source: §8 · p. 29

Internal validity

  • The tool selection is a representative snapshot, not an exhaustive catalogue, so relevant tools or capabilities may be missing.The review describes its tool selection as a lightweight grey-literature analysis informed by the authors’ experience.Source: §8 · pp. 29–30

Construct validity

  • Tool-capability descriptions rely mainly on vendor information, while challenge mappings and support levels may depend partly on researcher interpretation.The authors used inductive coding and traceability to originating studies to mitigate construct-validity risks.Source: §8 · p. 30

Conclusion validity

  • Tool analysis is diagnostic, identifying recurring maturity patterns and gaps rather than supporting definitive vendor comparisons or rankings.The authors ground their challenge mappings in empirical challenges and literature findings, with all authors participating in the mapping.Source: §8 · p. 30

Reliability and researcher bias

  • Documented procedures and a public replication package support repeatability; five-author coding and consensus reviews were used to reduce synthesis bias.Interpretations were explicitly linked to primary-study evidence, and considering multiple AI practices per challenge reduced the risk of overemphasizing one technique.Source: §8 · p. 30

9 Related Work

Prior work examines AI and architecture through narrower domains, tasks, or broader software-engineering contexts in which architecture is peripheral. This review instead synthesizes peer-reviewed evidence across software architecture and aligns it with practitioner challenges, complementing broader architecture roadmaps.

Evidence scope

  • The related-work discussion restricts itself to peer-reviewed studies, while noting that preprints may contain valuable early insights but have not undergone peer review.The authors frame the restriction as supporting methodological rigour and replicability.Source: §9 · pp. 30–31

Narrower AI-and-architecture studies

  • Earlier reviews focus on enterprise architecture, embedded systems, individual AI techniques, or narrow concerns such as migration, documentation, adaptation, and performance optimization.The embedded-systems survey found available techniques for anticipating and managing AI-driven disruption to be immature; a migration review covered 22 studies and reported clustering in 63% of cases and source code as input in 36.4%.Source: §9 · p. 31

AI in broader software engineering

  • Broader software-engineering reviews treat architecture peripherally, with stronger adoption evidence in development and testing than in architecture.The generative-AI mapping also reported limited insights into requirements specification and architecture, alongside unresolved reliability and applicability issues.Source: §9 · p. 31

Relationship to architecture roadmaps

  • Unlike broad discipline-level roadmaps, this work focuses on contemporary AI techniques as catalysts for architectural change across the lifecycle, beyond runtime control mechanisms.The paper presents its roadmap as complementary to influential software-architecture roadmaps.Source: §9 · p. 31

This review’s scope

  • The review consolidates peer-reviewed evidence on AI contributions to software architecture and aligns it with empirically derived practitioner challenges.The authors distinguish this scope from prior work centered on domains, individual tasks, or software engineering more broadly.Source: §9 · pp. 30, 32

10 Conclusion and Future Work

The review maps 51 primary studies to 17 practitioner-reported challenges and identifies six AI-specific challenges. It finds a mismatch between narrow, static AI contributions and practitioners’ need for continuous, contextualized support, then proposes five pillars for future research.

Findings

  • AI contributions remain fragmented and often detached from practice; mapping 51 studies to 17 practitioner challenges yields six AI-specific challenges.The paper frames these challenges as the frontier of AI-driven software architecture.Source: §10 · p. 32

Persistent mismatch

  • Current techniques often provide static, one-off recommendations in narrow domains or controlled settings, unlike practitioners’ evolving and organizational contexts.The authors identify a need for continuous, explainable, trustworthy support that moves toward adaptive learning, system-wide reasoning, and human-centred collaboration.Source: §10 · p. 32

Research framing

  • The roadmap is a maturation study of how contemporary AI extends or falls short of the vision of intelligent, self-managing architectures.The paper highlights lifecycle-wide reasoning, continuous traceability, and long-term architectural evolution as particular areas of concern.Source: §10 · p. 32

Future research agenda

  • Five pillars organize the agenda: continuous and adaptive architecting, living architectural knowledge, context-aware and human-centred AI, evidence-based quantitative architecting, and benchmarks and industrial adoption.Together, they connect current prototypes with future robust and trustworthy AI-enabled practices.Source: §10 · p. 32

Implications

  • Researchers can use the review to identify gaps and needs for methods, datasets, and evaluation protocols; practitioners can use it to set realistic expectations.The authors call for stronger industrial collaboration, continuous validation in evolving ecosystems, and hybrid approaches that combine AI capabilities with human expertise.Source: §10 · p. 32

Primary studies

The primary-study references include work on design-pattern recognition, architectural decision support, and architecture traceability.

Design-pattern recognition

  • A cited study examines programming-language models for software design-pattern recognition [P14].The reference title identifies the task but the supplied passage gives no study results.Source: Primary studies · p. 34

Decision support

  • A cited study addresses architectural decision-making on training strategies in reinforcement-learning architectures [P17].The reference identifies the decision context but provides no reported findings.Source: Primary studies · p. 34

Traceability

  • A cited study investigates architecture traceability through LLM-based component-name extraction [P47].The reference title names the technique and target task but supplies no results.Source: Primary studies · p. 36

A Online Resources

The paper provides a replication package to support independent replication and verification, including search and selection data and a list of primary studies.

A Online Resources

  • The replication package includes search and selection data and the list of primary studies.It is provided to facilitate independent replication and verification.Source: A Online Resources · p. 37
  • The paper was received in February 2025 and revised in June 2026.Source: A Online Resources · p. 37

Related papers

Loading 2504.04334v2…