A research map is not an architecture process
The main paper synthesizes studies published between 2019 and 2025 and maps them to challenges previously identified through practitioner interviews. The field includes design and decision-making, evolution and adaptation, architecture-element extraction, ADRs, patterns, failure recovery, and quality optimization. This is a useful map of activity, not an experiment with one coherent copilot: the authors did not measure long-term architecture quality, product ROI, or sustained production impact.
Baranov highlights the gap between an inductive catalog of narrow studies and a complete architecture process: the territory is visible, but the route through it is missing. Recent benchmarks reinforce the point. ArchBench contains only a handful of tasks and grades ADRs partly through textual similarity; R2A-Bench models recover plausible components from requirements but perform much worse on relationships. The broader the decision, the harder it is to define a trustworthy reference answer.
An artifact is easier to generate than a decision
An ADR, diagram, or pattern list is the shape of an output, not the decision itself. Before recording an ADR, a team must explore alternatives, prioritize quality attributes, test constraints, and accept residual risk. AI is therefore strongest as a first pass: collecting facts, recovering elements from code and traces, checking rules, proposing alternatives, and documenting an already understood choice. In routine systems with known boundaries, this automation can remove substantial mechanical work.
The harder problem lies between tools. Planning and coding, cloud operations, and incident response already receive strong AI support, while modeling, architecture governance, and artifact linkage remain fragmented. No shared memory connects a requirement to an ADR, a model, a code change, and a production signal. A provider that captures this context could sell completed architecture outcomes instead of tokens—but it would also introduce high context-processing costs and a deeper form of vendor lock-in.
What a real assistant is still missing
The discussion condenses the gaps into six capabilities: adapting a decision when facts change, maintaining traceability, incorporating local context and tacit knowledge, enforcing expert constraints, demonstrating quality-attribute evidence, and observing consequences over a long horizon. Every change must propagate across related views without creating contradictions or races. Progressive disclosure already causes sharp performance drops for coding agents; at architecture level, the cost of losing context is considerably higher.
Architects work with incomplete, weakly structured information, decide which uncertainty deserves attention first, and remain accountable for consequences. Baranov’s practical experiment exposed another boundary: the model produced a concrete engineering answer only after the conversation shifted to precise professional language. Expertise is what frames the task, detects failure, and drives verification. AI’s near-term role is therefore to complete standard operations quickly, leaving humans more time for unusual decisions, system trade-offs, and ownership.
What to take away
- 01The research landscape contains many useful narrow methods, but it does not demonstrate an end-to-end AI copilot for architecture.
- 02A generated ADR or diagram matters only when its facts, alternatives, trade-offs, and downstream consequences can be verified.
- 03The central technical barrier is a living link across requirements, models, code, and runtime signals as the system changes.
- 04Architecture expertise remains essential for task framing, precise language, uncertainty management, verification, and acceptance of residual risk.