Prompt to architecture: has anyone built this pipeline?

The pitch is seductive. A person describes their problem in plain language. A system extracts the intent, selects an architecture pattern from a curated library, instantiates the solution, checks it against the organisation's standards, and hands back a finished artifact. Prompt in, solution out.

I set out to build exactly this and asked the question every builder should ask first: has anyone walked this path before? The short answer is yes—every stage exists separately, in research and in industry trials. Nobody has assembled the whole pipeline. Here is the map I found.

Two data structures carry the whole product

Before looking at prior work, it helps to state the design plainly. Two things hold the judgment, and the model holds very little of it:

• A pattern library. A curated, versioned set of architecture patterns—"API front door with private backend", "event-driven ingestion", "hub-spoke landing zone"—each with its intent, applicability criteria, a component skeleton, known trade-offs and anti-patterns.
• A standards rulebase. Organisational requirements expressed as machine-checkable rules: "all API traffic goes through the API gateway", "no public endpoints for data stores", "secrets live in a vault, accessed by managed identity".

The model's job narrows to three stages: extract the requirements from the prompt, select a pattern and justify the choice, and instantiate the skeleton with concrete components. It never authors architectural opinion. It helps to think of it as a compiler: the pattern is the authority, the standards are the constraints, and the model is the assembly engine.

What research has already established

The closest academic work treats architecture decisions as a retrieval problem rather than a generation problem. A four-stage methodology pipeline takes architecturally significant requirements and recommends architectural tactics using retrieval-augmented generation, with expanding the knowledge base to architectural decision records named as future work. [1] Structurally, that is the first half of the pipeline: requirements in, grounded pattern recommendation out.

The reverse direction—using models to check architectures—has also been studied. Recent work evaluated language models for detecting architectural decision violations in real repositories and found they can meaningfully support violation detection when paired with well-designed prompts and context. [2] That legitimises a model as a first-pass checker. A deterministic checker remains the trustworthy backstop.

On the generation side, researchers have identified concrete strategies for guiding models to actually use design patterns in what they produce. [3] And a recent paper at the International Conference on Software Architecture examines how AI coding agents shape software architecture in practice: the agents arrive at recognisable patterns organically, but without deliberate, standards-governed selection. [4] The consistent finding across these studies: models gravitate toward plausible patterns and need external structure to select and apply them correctly. Which is precisely the argument for treating the pattern library as data.

There is also a pre-AI lineage worth knowing. The Software Engineering Institute formalised "requirements → applicable tactics → instantiated design" through its architectural tactics and attribute-driven design method decades ago. This pipeline is that methodology with a model replacing the manual reasoning steps.

What industry has tried—and what it learned

Review agents, not generation agents. Microsoft has published an open-source architecture review agent. Feed it a design document or a brain dump and it infers the components and their connections, renders an editable diagram, and flags single points of failure, missing API gateways and shared-database anti-patterns. [5] Notice the direction of travel: it validates and renders an existing architecture rather than synthesising one from patterns. The pipeline described here sits one step upstream.

Decision assistants with pattern retrieval. An architect-built assistant takes context and constraints, retrieves relevant architecture patterns, and generates decision options rather than final answers. Its post-mortem is the most valuable data point I found: after publishing, the tool saw little actual use, and the author concluded the problem itself needs validating before investing in better retrieval or ranking. [6] Architects may simply prefer guidance embedded in the workflow they already have over a standalone destination.

Diagram generators without standards. A wave of tools turns prompts into cloud architecture diagrams directly. None of them enforce an organisational standard—they produce plausible shapes. That is exactly the gap a standards-validation stage closes.

Spec-driven development. The fastest-moving adjacent discipline. Tools like Kiro and GitHub's spec-kit formalise "spec first, code second", where a structured specification is the source of truth the AI must conform to. [7] Microsoft has adopted the same pattern for AI-native engineering. [8] This pipeline is spec-driven development one layer up: the spec is the selected pattern plus the constraint set, and the artifact is an architecture instead of code.

Policy-as-code is the validator you should not rebuild. Machine-checkable rules already exist as a mature discipline: Open Policy Agent, Azure Policy, AWS Config rules, PSRule, Checkov. A January 2026 empirical study maps how widely policy-as-code is applied and which tools dominate. [9] The proven pattern is simple: the model proposes, the policy engine disposes. Nothing requires the validator to be a language model, and the strongest designs keep it deterministic.

Where the real gap sits

Three things recur across the trials that stalled: thin pattern libraries, no validation loop, and adoption friction with the people the tools were meant to help. The systems that did ship—spec-driven tools, policy engines—succeed because they are deterministic where judgment is not needed, and keep a human in the loop where it is.

The composition nobody has productised: curated patterns as versioned data, organisation rules as machine-checkable policy, a model confined to selection and instantiation, and a deterministic validation loop that forces repair before any artifact is emitted. That loop—validate, feed the failures back, regenerate, prove adherence—is the genuinely under-explored piece. It is also the part that turns an opinion generator into an advisory system you can actually trust in a review meeting.

So the question is not whether the pipeline can work. The parts have each been proven somewhere. The question is whether anyone will do the slow, unglamorous work of writing down the patterns and rules their own organisation actually trusts—and let the model assemble within them.

That is where I would start: not with the model, but with the library. Five to ten patterns written properly, ten rules that a policy engine can actually check, and one narrow domain I know well enough to judge the output. The model comes last.

References

1. [1] Springer — From Requirements to Design Decisions: A Four-Stage Methodology Pipeline for ASR-Driven Architectural Tactic Recommendation Using RAG
2. [2] arXiv — Evaluating Large Language Models for Detecting Architectural Decision Violations
3. [3] arXiv — Strategies for Guiding LLMs to Use Software Design Patterns
4. [4] IEEE — Architecture Without Architects: How AI Coding Agents Shape Software Architecture
5. [5] Microsoft Tech Community — Stop Drawing Architecture Diagrams Manually: Meet the Open-Source AI Architecture Review Agents
6. [6] Adel Ghlamallah — Architecture Decisions Need Options – Can an ADR Assistant Help Create Them?
7. [7] Martin Fowler — Understanding Spec-Driven-Development: Kiro, spec-kit
8. [8] Microsoft — A Spec-First Approach to AI-Native Engineering
9. [9] arXiv — An Empirical Study of Policy-as-Code Adoption in Open-Source