Why the Architect AI Copilot Still Hasn’t Arrived

The discussion concerns a systematic review of 51 studies on AI in architecture from 2019–2025. The authors grouped them by topic: design and decision-making, evolution and adaptation, ADRs, patterns, and non-functional requirements. Section 2.2 of arXiv v2 reports 874 initial candidates and 597 after cleanup. The captions give 8,074 at this point: that differs from the paper and is not the size of the final corpus.

Baranov explains why this kind of induction stalls: building the general from the particular takes a large sample, yet here the very notion of architecture is derived from the papers found. He would rather start with the architecture process from textbooks and show which parts the studies cover. His first impression was of scattered findings without Brooks’s conceptual integrity. His metaphor: someone photographed Africa, so the territory is there but the map is not.

Alexander then walks through the benchmarks. In ArchBench, by his account, five tasks appeared in total, the model choice is dated, and a generated ADR is scored by textual overlap with the reference one; the repository exists, there are no commits, and nobody is joining in. The fresher requirements-to-architecture benchmark is put together more carefully: from requirements in student and GitHub projects, 68 in total, the model produces a UML diagram, and components are guessed reasonably well while the arrows point in the wrong directions — the F1 score for relationships is dismal. Baranov finds the pattern-recognition task especially funny: the work sounds like industrial confirmation of experience, yet inside it is a search for the singleton in two or three projects. He says frankly that he never found an answer to why anyone would burn tokens teaching a model to spot a Singleton or a Factory: he once ran monthly pattern hackathons himself, but to teach the team to localise change. He also notes that the levels are mixed up: work with code sits next to non-functional requirements and infrastructure subjects.

ADR generation is the most hyped scenario, and both find it small. Baranov points out that he was already laying out text templates back when he contributed to httpd: an ADR is an architecture decision record, not the decision — a read model of a choice already made, half a percent of a process that still contains research, design, comparing the options, and gathering the data behind them. Alexander recalls how T-Bank spent last year building an assistant you could ask questions about your own ADR, while today Codex or Claude will challenge the draft an order of magnitude better and help finish it, as long as you answer the key questions. He saw the comical side there too: people generate a UML diagram out of an ADR that nobody in the process reads anyway, because few people can read UML, and no review step for what the tools produced is built into such pipelines.

The second half of the review is a map of tooling across four levels of autonomy, from rules to agents. At the top sit Jira and Confluence with their agentic features and ADR support, GitHub, GitLab, and Sonar, while Postman landed there for validating API design, next to modelling tools, which the two find amusing; Cursor and Codex, the most widely used tools of all, did not make the list at all. Planning, coding, and cloud operations are shaded in well, design and modelling almost not at all, and the authors admit that a shared memory of the system's history and evolution is missing: the chain from requirements to ADR to model to code to runtime is broken. Alexander bets the model providers will assemble it by climbing up from code, and that an ADR with a full analysis of your system will then cost not fifteen or twenty dollars, like a review of one change, but a hundred and fifty. Baranov answers that this is lock-in no longer on a tool but on brains.

The closing slide lists what the assistant still lacks: adaptation when the facts change, traceability from intent to implementation, local context, checks against expert constraints, evidence for quality attributes, and a long horizon. Alexander backs the first item with recent benchmarks: when requirements reach an agent in portions rather than one package, the pass rate of top models drops from roughly half the tasks to a quarter — and that is at code level, so at architecture level the fall should be more dramatic. Baranov unpacks traceability: notations such as ArchiMate have layer linkage in their heart, yet editing one block changes elements, relationships, and rationale alike, so the output is more often a new model than a corrected one, and at high change rates you also get race conditions and no way to check consistency in advance without pessimistically locking everything. Alexander counters that full end-to-end traceability is not needed: it is enough to see whether a requirement is reflected in an ADR and whether the change reached production. Live on air Baranov arrives at a new thought — a closed loop able to spin, by his reckoning, a hundred trillion iterations almost instantly needs brakes.

Context is a pain of its own: Alexander has long wanted a company's rules, its components, and a team's domain to flow into the agent instead of living in the architect's head. Baranov reduces the constraints to three: the data is always incomplete, weakly structured, and enormous in volume, and the model has none of the anxiety that helps a human rank uncertainties by criticality. His own experiment: he loaded the accumulated data of a finished project into a model and repeated the customer's original request, and the answer came back averaged and almost non-technical; specifics appeared only once he switched to strict engineering language and discussed abstract factories and the state pattern. The conclusion is that getting a professional answer requires you to be a strong engineer yourself — it is the same bounded context. Alexander adds the study from the episode with Evgeny Sergeev: expertise shows up most clearly during failures, where novices abandon the investigation nearly four times more often than experts. Baranov closes with his own frontier: people are left the non-typical work, and the first non-typical task is building the thing that handles the typical ones.