AI for Software Architecture: Why the Architect Copilot Still Hasn’t Arrived

The most important result of the review can be stated without its specialized terminology: today’s AI works with a snapshot, while architecture lives as history. A model receives requirements, a piece of code, or a set of ADRs at one moment and proposes the next artifact. An architect must remember why a decision appeared, which trade-off was acceptable, what changed in the organization, and how the system behaved after deployment.

This distinction is easy to miss because a local result can look persuasive. The diagram is syntactically valid. The ADR is coherent. The components have plausible names. Yet architectural quality is determined not by the polish of one artifact, but by the relationship between intent, decision, implementation, operational evidence, and the next round of change.

That makes “can an LLM draw an architecture?” the wrong question. The practical question is whether the system can maintain verifiable architectural memory and update recommendations as requirements, code, constraints, and operational data evolve. The reviewed literature does not yet demonstrate that end-to-end capability.

The authors did not run one experiment with one model. They conducted a systematic literature review following Kitchenham’s guidance: searching IEEE Xplore, the ACM Digital Library, Scopus, and Web of Science; manually screening ICSA and ECSA proceedings; and following citation links. The corpus covered peer-reviewed work from January 2019 through August 2025.

The funnel began with 874 candidates. Removing non-research material and duplicates left 597 papers; selection and manual search produced 76; data extraction yielded 51 primary studies. All five authors took part in coding and consolidating the themes. Search results, selection decisions, and coding tables are available in the replication package (Bucaioni et al., 2026).

The researchers then mapped the academic findings to challenges from their earlier interviews with 32 software architecture practitioners (Wan et al., 2023). This is an important strength: the review does not merely enumerate techniques; it asks whether they address real difficulties in design, maintenance, and system evolution.

It is still a synthesis rather than a direct measurement of AI’s effect on industrial architecture quality. Some links between techniques and practitioner challenges are the authors’ analytical interpretation. The rest of this article therefore separates a measured result, a prototype’s promise, and a research direction.

The strongest evidence appears when the task is narrow, the input is bounded, and the output is testable. A Llama 2 7B model fine-tuned to select an architecture pattern from requirements reached 70% accuracy—but only across MVC, microservices, and client–server. It often gave useful explanations while also showing pattern bias and output-format drift (Gustrowsky et al., 2024).

Another study used natural-language processing to extract architectural responsibilities and derive Use Case Maps from requirements. Across four projects, the authors reported an F-measure of roughly 75% (Rodríguez et al., 2021). That is a valuable first pass that can reduce manual effort, but it measures the discovery of elements rather than the quality of an entire resulting architecture.

For architecture decision analysis, researchers used a corpus of 95 ADRs. GPT-4 in a zero-shot setup generated coherent, context-appropriate decisions but remained below human completeness. GPT-3.5 with examples reached comparable quality, while a fine-tuned Flan-T5 was competitive and feasible for on-premises use. The result is not “delegate ADRs to the model.” It is “the model can accelerate a candidate when a human checks completeness, rationale quality, and traceability” (Dhar et al., 2024).

Tasks with a measurable operational feedback loop look stronger. A Kubernetes framework on Azure Kubernetes Service combined load forecasting, proactive scaling, and chaos experiments; in a small testbed, it reduced container deployment time by up to 34% (Hettiarachchi et al., 2022). Reinforcement-learning agents found critical faults more effectively than a random chaos monkey in client–server and peer-to-peer models—although the evidence came from simulation (Canonico et al., 2020).

Architecture work is not a set of independent buttons labeled “select a pattern,” “write an ADR,” and “find a smell.” A decision changes boundaries, cost, security, deployment, and future options. Real support requires AI to retain relationships and consequences, not merely produce a locally plausible answer.

In early design studies, models propose components, patterns, microservice names, and decisions from the current description. Corporate constraints, regulation, team capabilities, the history of earlier trade-offs, and migration cost are usually absent or reduced to a few lines. The model optimizes a formulation within the supplied context rather than the system’s lifecycle.

The authors also examined 21 mainstream tools as of March 2026, ranging from GitHub Copilot and GitLab Duo to Datadog, Dynatrace, cloud advisors, and ADR tools. This was not an independent product benchmark; it was a diagnostic snapshot built primarily from vendor documentation (Bucaioni et al., 2026). Even so, the pattern matched the literature: more support for observability, conformance, local remediation, and generation; less for system-wide reasoning, accumulated architecture erosion, and connecting intent with operations.

Industry has learned to embed intelligence in individual stages, but it has not assembled a complete architectural feedback loop. Isolated assistance can be valuable. The mistake is treating it as system-level understanding.

Mapping the studies to practitioner challenges produced six areas where current support remains insufficient. They are more useful as properties of an architecture knowledge system than as a feature list for a future product (Bucaioni et al., 2026).

1. Adaptation. A recommendation must evolve with requirements and system behavior rather than remain valid only for the original prompt.
2. Continuous traceability. Requirements, ADRs, models, code, and operational data must stay aligned in both directions.
3. Context-aware reasoning. System boundaries depend on the domain, team structure, data, constraints, and accumulated history—not just the task text.
4. Expert review. Architecture review must incorporate industry standards, security, regulation, and domain knowledge.
5. Evidence-based measures. Quality cannot be reduced to one universal score; metrics must connect quality attributes to the observed behavior of a particular system.
6. The long horizon. AI must see debt, smells, erosion, and consequences accumulating across versions, not only the current branch state.

The review corpus ends in August 2025, so its diagnosis needs a freshness check. Several projects published over the following year attempt to measure architecture capabilities directly. They do not invalidate the review; instead, they turn part of its roadmap into concrete measurement infrastructure.

ArchBench provides a shared platform for architecture tasks, with dataset download, trajectory logging, and automated evaluation. This matters because models and agents can be compared through a reproducible pipeline, while new architecture tasks can be added as modules.

R2ABench evaluates requirements-to-architecture generation across 68 projects. Current systems often produce syntactically valid, readable views, yet recover relationships between components substantially less reliably than the components themselves. Hallucinated edges are the dominant structural failure, while requirement coverage and traceability remain the principal substantive gaps. A correct form still does not guarantee a connected design.

CAKE evaluates cloud architecture knowledge with 188 expert-validated questions and 22 model configurations. Multiple-choice accuracy quickly approaches a ceiling, while free-form responses continue to separate models; the evaluation format itself changes the competency conclusion. SAKE expands the test to 2,154 questions across eight architecture categories and shows that strong average accuracy can hide significant gaps in individual areas.

These should be described as fresh benchmarks, not mature industrial proof. R2ABench, CAKE, and SAKE were preprints when this article was written. Architecture terminology and a correct answer are also necessary but insufficient evidence that a system can make a decision for a concrete organization with real trade-offs.

The most practical part of the authors’ agenda is its dependency order. Starting with a universal AI architect makes little sense when a team lacks a connected base of requirements, decisions, models, code, and operational evidence. A larger context window cannot reconstruct missing organizational memory.

The first layer is living architectural knowledge: versioned ADRs, explicit links to requirements and components, machine-readable constraints, quality attributes, and runtime evidence. Next comes adaptive decision support that revises recommendations as facts change. Only then do evidence-based metrics and lifecycle-wide benchmarks become useful.

The human role is not reduced to clicking approve. The paper proposes a division of responsibility: AI acts as an analyst that gathers data, finds relationships, proposes options, and explains the basis; the architect remains the strategist who owns the why, priorities, and acceptable trade-off. This division works only when the recommendation can be challenged and traced to evidence.

I would not begin by selecting a model or buying an “architecture copilot.” Start with one real change and attempt to reconstruct its causal chain.

1. 01Which requirement or operational signal initiated the change?
2. 02Which ADRs and architecture boundaries does it affect?
3. 03Where do those decisions appear in code, configuration, and infrastructure?
4. 04Which quality attributes and constraints must change or remain invariant?
5. 05Which metrics, incidents, or user signals will confirm the decision’s consequences?

Then walk the path backward: from an incident or architecture smell to the component, change, ADR, and original intent. If either direction depends on one person’s memory, AI cannot make it reliable. It can only produce another disconnected document more quickly.

Once that chain exists, choose one bounded use case—ADR conformance, change-impact analysis, or link recovery—and evaluate it on your own history. A model recommendation and accountability for the architecture trade-off must remain separate process steps.

The review is strong in its transparent method and open replication package, but it does not establish a causal effect of AI on architecture quality. Most primary studies test one technique on a bounded dataset, and early-design tasks have little long-term industrial validation.

The search string ("Artificial Intelligence" OR AI) AND "software architecture*" is intentionally simple. It may miss papers that use LLMs without labeling the method as AI. Excluding non-peer-reviewed work makes the corpus more consistent while cutting off the newest results. The mainstream-tool snapshot also relies primarily on vendor documentation and is not a product ranking.

arXiv v2 contains editorial inconsistencies: the abstract, main tables, and roadmap section disagree on the number of topical areas, practitioner challenges, and strategic directions. I do not build conclusions on those aggregate counts. The reliable anchors are the 51-study corpus, the reported results of the primary studies, and the six explicitly stated capability gaps.

That does not weaken the practical conclusion. AI does not remove architecture; it raises the value of architecture discipline. The cheaper it becomes to generate a locally plausible decision, the more important it is to preserve intent, boundaries, trade-offs, and consequences over time.