Pith. sign in

REVIEW 3 major objections 5 minor 36 references

MAAD: Automate Software Architecture Design through Knowledge-Driven Multi-Agent Collaboration

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper proposes MAAD, a four-agent LLM system that claims to automate software architecture design from requirements and to outperform the general-purpose multi-agent baseline MetaGPT on architectural completeness and evaluation quality.

desk verdict A well-described, honest multi-agent LLM framework for architecture design whose quantitative superiority claim rests on a self-evaluating component; worth engaging, but not yet proven. read the letter →

arxiv 2507.21382 v1 pith:PESCHQNJ submitted 2025-07-28 cs.SE cs.AI

Ruiyin Li , Yiran Zhang , Xiyu Zhou , Peng Liang , Weisong Sun , Jifeng Xuan , Zhi Jin , Yang Liu This is my paper
classification cs.SEcs.AI
keywords softwarearchitecturedesignmulti-agentsystemlargelanguagemodelsknowledge-drivenretrieval-augmentedgenerationevaluationrequirementsanalysisATAM
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that software architecture design, traditionally a knowledge-intensive expert task, can be automated by a team of four role-specialized LLM agents that analyze requirements, model the system, produce design documentation, and evaluate the result against the original specification. The proposed framework, MAAD, is said to generate more comprehensive architectural components and more structured evaluation reports than the general-purpose multi-agent baseline MetaGPT. The paper also argues that injecting external architectural knowledge makes generated designs more modular and interface-driven, and that the choice of base LLM substantially affects design quality, with GPT-4o performing best in their case study. If correct, development teams could obtain architectural blueprints and quality assessments automatically, reducing the manual effort of architects and enabling faster iteration on early design decisions.

What carries the argument

The central mechanism is the four-agent workflow with shared artifact pools and knowledge infusion. The Analyst, Modeler, Designer, and Evaluator agents pass artifacts downstream, with the Evaluator feeding mismatch findings back to the other agents for revision, creating a feedback-driven loop that maintains traceability to the original requirements. The knowledge-driven component is a vector database built from the third and fourth editions of Software Architecture in Practice, retrieved via retrieval-augmented generation and injected into the prompts of the Modeler and Designer agents, grounding their outputs in external architectural best practices. The paper's quantitative yardstick is the mismatch rate, computed as the number of mismatches reported by the Evaluator agent divided by the total number of requirements, which connects the evaluation output to the claimed quality of the generated architecture.

What would settle it

Have independent architects, blinded to the generating system, rate MAAD's and MetaGPT's outputs for the same requirements and check whether they judge MAAD's architecture as more comprehensive and better aligned with the requirements; if they do not, the superiority claim is refuted. A more direct probe of the measurement is to give the Evaluator agent an architecture that deliberately omits several stated requirements and see whether its mismatch rate rises accordingly, since a metric that fails to detect obvious omissions cannot support the claimed quality advantage.

Watch

Extended reading notes

Core claim

The central claim is that a knowledge-driven, four-agent collaboration loop can transform a software requirements specification into a complete architecture design with its own quality evaluation, and that this design is better than what a general-purpose software-development multi-agent system produces. The Analyst agent decomposes the requirements into functional, non-functional, architecturally significant requirements and constraints; the Modeler agent produces the "4+1" architecture views; the Designer agent writes detailed architecture documentation including component and connector specifications, design decisions, and an executable prototype skeleton; and the Evaluator agent checks the architecture against the original requirements via ATAM evaluation and mismatch analysis. In the empirical comparison, MetaGPT produced only class and sequence diagrams with a sparse technical solution, whereas MAAD produced the full set of architecture views, detailed documentation, and evaluation reports, with finer-grained requirement categorization. External knowledge infusion changed the component diagram from a runtime-flow-oriented view to a more modular, interface-driven view, while the mismatch rates for GPT-4o and Llama 3.3 were 0.188 versus 0.313 for DeepSeek-R1, which the paper interprets as evidence that the base LLM's reasoning style significantly affects requirements coverage and architectural consistency.

Load-bearing premise

The quantitative evidence for MAAD's superiority rests on mismatch rates and ATAM reports produced by MAAD's own Evaluator agent, so if that self-assessment is not objective or accurate, the quantitative support for the superiority claim collapses.

Editorial extensions

If this is right

  • MAAD could serve as an automated assistant that generates architecture blueprints and evaluation reports from natural-language requirements, reducing the architect's manual workload and speeding up early design iterations.
  • Specialized multi-agent systems appear to outperform a general-purpose software-development multi-agent system on architecture-specific tasks, suggesting that role specialization matters more than broad automation coverage for architecting.
  • Infusing external architectural knowledge changes the style of generated designs toward modular, interface-driven structures, implying that organizations should curate domain-specific knowledge bases to get measurable design improvements.
  • The base LLM choice within a multi-agent framework materially affects requirements coverage and architectural consistency, so teams should evaluate LLMs on the specific architecture task rather than rely on general capability rankings.
  • The framework's knowledge base is extensible, so adding private or industry-specific architectural knowledge could tailor MAAD to specialized domains without changing the agent orchestration.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper's evidence suggests that the evaluator role, not just the generation roles, is what gives MAAD its advantage over MetaGPT, and that adding an explicit self-evaluation step to a single-LLM architecture pipeline could yield similar quality gains with less orchestration overhead.
  • The unchanged mismatch rate despite external knowledge infusion hints that the mismatch metric may be too coarse to capture qualitative design improvements, so future work could measure traceability, design-pattern compliance, or modularity to separate the knowledge effect from other factors.
  • Because interviewed architects raised trustworthiness and explainability concerns, applying MAAD to safety-critical systems would likely require human-in-the-loop validation and independent grounding of the evaluator's judgments rather than relying solely on self-assessed consistency.
  • The architecture domain's inherent subjectivity, noted by the participants, implies that MAAD's evaluation reports should be calibrated against human expert ratings before being used as quantitative evidence of design quality in other contexts.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes MAAD, a knowledge-driven multi-agent framework that automates software architecture design from software requirements specifications. MAAD orchestrates four LLM-based agents (Analyst, Modeler, Designer, Evaluator) that produce requirements artifacts, '4+1' architectural views, detailed design documentation, and ATAM-based evaluation and mismatch reports. The authors evaluate MAAD through a case study on a single system (SFS), a comparative study with MetaGPT, interviews with three architects across 11 requirements specifications, and an ablation across three base LLMs (GPT-4o, DeepSeek-R1, Llama 3.3). The paper claims that MAAD outperforms MetaGPT in architectural completeness and evaluation quality, that external knowledge improves design quality, and that GPT-4o yields better architecture designs than the other LLMs tested.

Significance. The manuscript addresses a genuine and increasingly relevant problem—automating knowledge-intensive software architecture design with LLM-based multi-agent systems. The framework design is coherent and builds on established concepts ('4+1' views, ATAM, RAG-based knowledge infusion), and the authors provide a replication package containing prompts, scripts, and generated artifacts, which is a concrete reproducibility strength. The interview feedback and qualitative comparisons offer useful practical insights. However, the empirical evidence is currently too thin to support the paper's central claims: the quantitative metric (mismatch rate) is produced by a component of the system itself, the RQ1 comparison rests on a single case and qualitative artifact inspection, and the interview evidence is based on only three participants. If the authors supply independent, calibrated evaluation of the generated architectures and broaden the empirical base, the framework could be a solid contribution; in its present form, the strength of the claims outruns the evidence.

major comments (3)
  1. [§5.2, RQ2] The central quantitative support for MAAD's superiority rests on the mismatch rate computed by the Evaluator agent, which is a component of MAAD itself. Section 3.2.4 defines the Evaluator as part of the framework, and Sections 5.2 and 5.3 use its self-reported mismatch rates (0.188 for GPT-4o and Llama 3.3, 0.313 for DeepSeek-R1) as quantitative evidence for RQ2 and RQ3. There is no calibration of this metric against human expert judgment, an independent LLM judge, or a stability analysis across prompt variations, temperature settings, or evaluator model choices. Moreover, MetaGPT has no comparable evaluator, so the RQ1 superiority claim cannot be supported by this metric at all. Because the abstract and conclusions explicitly claim that MAAD yields 'better architecture designs' and that GPT-4o 'exhibits better performance,' these self-generated numbers are load-bearing. Please add an independent evaluation of the generated artifacts (e.g., blind ratings by multiple architects or a pre-registered rubric applied by a separate, non-MAAD evaluator) and report the reliability and stability of the mismatch counts.
  2. [§5.2, RQ2] The RQ2 results do not support the conclusion that external knowledge improves architecture design quality. The mismatch rate is identical (0.188) with and without external knowledge, and the only reported evidence for improvement is a qualitative visual comparison of a single component diagram (Figures 5 and 6). The text itself concedes in §6.2 that the unchanged mismatch rate 'reveals a critical limitation' of generic architectural knowledge. The claim that 'Incorporating external knowledge into MAAD yields more modular and interface-driven architecture design' is thus based on the authors' subjective reading of one example, with no inter-rater agreement or multi-case evidence. Please provide a more systematic comparison, such as multiple SRSs, independent raters, a rubric-based artifact evaluation, or at least a larger sample of diagrams, to substantiate the RQ2 answer.
  3. [§5.1.2, §5.1.3, RQ1] The RQ1 comparison with MetaGPT is a single-case, two-system comparison in which MAAD is purpose-built for architecture design while MetaGPT is a general-purpose, end-to-end development MAS. The reported differences (Table 1, Figures 3–4) are qualitative and not controlled for the differing task scopes. The interview evidence is limited to three architects, with the first author conducting the interviews and performing the primary qualitative analysis; the paper does not report how participants were sampled, how many of the 11 SRSs each architect reviewed, or inter-rater reliability for the thematic coding. These are not merely presentational gaps: the paper's central claims of 'MAAD yields better architecture designs than MetaGPT' and 'practical usability' depend on this evidence. Please expand the evaluation to more cases and report the interview methodology in fuller detail, including participant selection, artifact review procedure, and coding reliability.
minor comments (5)
  1. [§5.2, Eq. (1)] The denominator of the mismatch rate is never explicitly reported. The text says six mismatches yield 0.188 and ten yield 0.313, implying 32 total requirements, but the total count is not given, and it is unclear whether this count is identical across the three LLM conditions and whether the Evaluator's mismatch categorization was checked for consistency. Please report the total requirement count, the mapping of each mismatch to the corresponding requirement, and any weighting of mismatch types.
  2. [§4.2.1] The dataset description is too brief: the paper should specify the number of SRSs in the dataset, their domains, and the criteria used to select the 11 requirements specifications shown to the architects in the interviews.
  3. [§3.2.5] The knowledge base construction is under-specified: the authors should describe the embedding model, vector database, number of text segments, and the pilot experiment that led to the choice of retrieving exactly three segments per prompt.
  4. [§3.3 vs §5] Section 3.3 describes an iterative feedback loop in which the Evaluator collaborates with other agents to resolve mismatches, but the reported results appear to be one-pass outputs without iteration. Please clarify whether iteration was applied in the experiments and, if so, how many rounds were used.
  5. [Table 1, §5.1.2] Table 1 states that MetaGPT 'contain[s] unreal requirements generated by LLMs,' but the text's example (e.g., 'track progress' and 'update questions independently') does not demonstrate that these are 'unreal' rather than reasonable design assumptions. Please either soften this wording or provide evidence that those details contradict the input SRS.

Circularity Check

0 steps flagged · score 0.0 of 10

No construction-level circularity: the mismatch-rate evidence is self-generated but not definitionally forced, and the paper's own validity section concedes the subjectivity of architecture evaluation.

full rationale

The paper's derivation chain is an empirical evaluation rather than a formal derivation: MAAD's outputs are compared against MetaGPT and across knowledge and LLM configurations, with conclusions drawn from artifact inspection, architect interviews, and reported mismatch rates. The Evaluator agent is a component of MAAD and produces the mismatch-rate metric used in RQ2 and RQ3 (Sections 3.2.4, 5.2, Equation 1, and 5.3), so that metric is self-reported rather than independently calibrated. This is a genuine measurement-validity concern, and the paper itself flags it in Section 7: 'architecture evaluation cannot be entirely objective. Consequently, the current assessment may not fully capture the quality or effectiveness of the generated architecture designs.' Nevertheless, this is not circularity by construction: the mismatch counts are LLM outputs that can differ across conditions (0.188 vs. 0.313), and the paper does not define 'quality' as 'whatever the Evaluator reports.' The RQ1 superiority claim does not rest on this self-generated metric; Section 5.1.2 explicitly states that MetaGPT has no equivalent evaluation mechanism and that the authors therefore could not compare the two systems using LLM-executed architectural evaluation, leaving RQ1 supported by qualitative artifact comparison and three architect interviews. The self-citations to the authors' prior vision paper and requirements dataset provide inputs or extension context but are not load-bearing justifications for the central performance claims. No fitted parameter is renamed as a prediction, no uniqueness theorem is imported from the authors' prior work, and no ansatz is smuggled in via citation. Overall, the central claims retain independent content, and the identified issues are correctness and validity threats rather than definitional circularity.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

The framework's effectiveness is tied to design choices such as the retrieval count, the knowledge base content, and the self-evaluating Evaluator agent. The mismatch rate is an ad hoc metric defined by the authors and produced by the system itself. No new physical or formal entities are introduced.

free parameters (2)
  • k_retrieval = 3
    Number of knowledge-base text segments injected into Modeler and Designer prompts, chosen via pilot experiments (Section 3.2.5).
  • external knowledge sources = Software Architecture in Practice, 3rd and 4th editions
    These two books form the vectorized knowledge base; the choice of sources is a hand-picked design decision (Section 5.2).
assumptions (5)
  • domain assumption The 4+1 view model is a valid and sufficient framework for representing software architectures.
    MAAD's Modeler produces 4+1 views as the complete architectural blueprint (Section 3.2.2).
  • domain assumption ATAM is a valid method for evaluating architecture quality.
    The Evaluator agent uses ATAM to produce evaluation reports (Section 3.2.4).
  • ad hoc to paper Mismatch rate, defined as mismatches divided by total requirements, is a meaningful measure of architecture quality.
    This metric is introduced in Equation 1 and used to quantify quality, yet it depends on the Evaluator's own identification of mismatches (Section 5.2).
  • domain assumption The Space Fraction System (SFS) case is representative enough to support general claims about MAAD's effectiveness.
    Only SFS is used for detailed comparison with MetaGPT and for the LLM comparison (Sections 4.2.1 and 5.1).
  • domain assumption LLM-generated UML diagrams can be qualitatively compared for completeness and granularity without a scoring rubric.
    The paper compares diagrams produced by MAAD and MetaGPT based on inspection (Section 5.1.2).

how reviews work

0 comments
Cite this review

Pith. "Pith review of MAAD: Automate Software Architecture Design through Knowledge-Driven Multi-Agent Collaboration." pith.science (2026). https://pith.science/paper/PESCHQNJ

@misc{pith2026250721382,
  author       = {Pith},
  title        = {Pith review of: MAAD: Automate Software Architecture Design through Knowledge-Driven Multi-Agent Collaboration},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PESCHQNJ}},
  note         = {Machine review of arXiv:2507.21382}
}
read the original abstract

Software architecture design is a critical, yet inherently complex and knowledge-intensive phase of software development. It requires deep domain expertise, development experience, architectural knowledge, careful trade-offs among competing quality attributes, and the ability to adapt to evolving requirements. Traditionally, this process is time-consuming and labor-intensive, and relies heavily on architects, often resulting in limited design alternatives, especially under the pressures of agile development. While Large Language Model (LLM)-based agents have shown promising performance across various SE tasks, their application to architecture design remains relatively scarce and requires more exploration, particularly in light of diverse domain knowledge and complex decision-making. To address the challenges, we proposed MAAD (Multi-Agent Architecture Design), an automated framework that employs a knowledge-driven Multi-Agent System (MAS) for architecture design. MAAD orchestrates four specialized agents (i.e., Analyst, Modeler, Designer and Evaluator) to collaboratively interpret requirements specifications and produce architectural blueprints enriched with quality attributes-based evaluation reports. We then evaluated MAAD through a case study and comparative experiments against MetaGPT, a state-of-the-art MAS baseline. Our results show that MAAD's superiority lies in generating comprehensive architectural components and delivering insightful and structured architecture evaluation reports. Feedback from industrial architects across 11 requirements specifications further reinforces MAAD's practical usability. We finally explored the performance of the MAAD framework with three LLMs (GPT-4o, DeepSeek-R1, and Llama 3.3) and found that GPT-4o exhibits better performance in producing architecture design, emphasizing the importance of LLM selection in MAS-driven architecture design.

Figures

Figures reproduced from arXiv: 2507.21382 by the authors.

Figure 1
Figure 1. Overview of the MAAD framework [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. Process of the sudy design 4.2.1 Dataset. The requirements dataset is collected from Jin et al. [26], which was gathered from public datasets, including PURE [27] (a dataset of 79 publicly available natural language require￾ments documents collected from the Web) and private industrial requirements documents [28]. We then select the requirements of the “Space Fraction System” (SFS) as the input to conduct a case stu… view at source ↗
Figure 3
Figure 3. Comparison of class diagrams generated by MAAD and MetaGPT [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Comparison of sequence diagrams generated by MAAD and MetaGPT [PITH_FULL_IMAGE:figures/full_fig_p013_4.png]
Figure 5
Figure 5. Figure 5: The component diagram of SFS with reference knowledge [PITH_FULL_IMAGE:figures/full_fig_p016_5.png]
Figure 6
Figure 6. Figure 6: The component diagram of SFS without reference knowledge [PITH_FULL_IMAGE:figures/full_fig_p016_6.png]
Figure 7
Figure 7. Figure 7: The component diagram of SFS generated by DeepSeek-R1 [PITH_FULL_IMAGE:figures/full_fig_p017_7.png]
Figure 8
Figure 8. Figure 8: The component diagram of SFS generated by Llama 3.3 [PITH_FULL_IMAGE:figures/full_fig_p018_8.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

36 extracted references · 26 canonical work pages

  1. [1]

    L. Bass, P. Clements, and R. Kazman,Software Architecture in Practice (4th Edition), 4th ed. Addison-Wesley Professional, 2021

    work page 2021

  2. [2]

    Architectural mismatch: Why reuse is still so hard,

    D. Garlan, R. Allen, and J. Ockerbloom, “Architectural mismatch: Why reuse is still so hard, ”IEEE Software, vol. 26, no. 4, pp. 66–69, 2009

    work page 2009

  3. [3]

    Unveiling the Role of ChatGPT in Software Development: Insights from Developer-ChatGPT Interactions on GitHub,

    R. Li, P. Liang, Y. Wang, Y. Cai, W. Sun, and Z. Li, “Unveiling the Role of ChatGPT in Software Development: Insights from Developer-ChatGPT Interactions on GitHub, ”arXiv preprint arXiv:2505.03901, 2025

    work page arXiv 2025

  4. [4]

    A systematic review of the limitations and associated opportunities of ChatGPT,

    N. Cong-Lem, A. Soyoof, and D. Tsering, “A systematic review of the limitations and associated opportunities of ChatGPT, ”International Journal of Human–Computer Interaction , vol. 41, no. 7, pp. 3851–3866, 2025

    work page 2025

  5. [5]

    Siren’s Song in the AI Ocean: A Survey on Hallucination in Large Language Models,

    Y. Zhang, Y. Li, L. Cui, D. Cai, L. Liu, T. Fu, X. Huang, E. Zhao, Y. Zhang, Y. Chen, L. Wang, A. T. Luu, W. Bi, F. Shi, and S. Shi, “Siren’s Song in the AI Ocean: A Survey on Hallucination in Large Language Models, ”Computational Linguistics, pp. 1–45, 2025

    work page 2025

  6. [6]

    Mare: Multi-agents collaboration framework for requirements engineering,

    D. Jin, Z. Jin, X. Chen, and C. Wang, “Mare: Multi-agents collaboration framework for requirements engineering, ” arXiv preprint arXiv:2405.03256, 2024

    arXiv 2024

  7. [7]

    LLM-Based Multi-Agent Systems for Software Engineering: Literature Review, Vision and the Road Ahead,

    J. He, C. Treude, and D. Lo, “LLM-Based Multi-Agent Systems for Software Engineering: Literature Review, Vision and the Road Ahead, ”ACM Transactions on Software Engineering and Methodology , vol. 34, no. 5, pp. 1–30, 2025

    work page 2025

  8. [8]

    Towards detecting LLMs hallucination via markov chain-based multi-agent debate framework,

    X. Sun, J. Li, Y. Zhong, D. Zhao, and R. Yan, “Towards detecting LLMs hallucination via markov chain-based multi-agent debate framework, ” inProceedings of the 50th IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP). IEEE, 2025, pp. 1–5

    work page 2025

Show all 36 references
  1. [9]

    Improving factuality and reasoning in language models through multiagent debate,

    Y. Du, S. Li, A. Torralba, J. B. Tenenbaum, and I. Mordatch, “Improving factuality and reasoning in language models through multiagent debate, ” inProceedings of the 41st International Conference on Machine Learning (ICML) . OpenRe- view.net, 2024, pp. 1–9

    2024

  2. [10]

    Multi-agent collaboration: Harnessing the power of intelligent LLM agents,

    Y. Talebirad and A. Nadiri, “Multi-agent collaboration: Harnessing the power of intelligent LLM agents, ”arXiv preprint arXiv:2306.03314, 2023

    2023 arXiv

  3. [11]

    MetaGPT: Meta programming for multi-agent collaborative framework,

    S. Hong, X. Zheng, J. Chen, Y. Cheng, J. Wang, C. Zhang, Z. Wang, S. K. S. Yau, Z. Lin, L. Zhou et al., “MetaGPT: Meta programming for multi-agent collaborative framework, ”arXiv preprint arXiv:2308.00352, 2023

    2023 arXiv

  4. [12]

    Knowledge-based multi-agent framework for automated software architecture design,

    Y. Zhang, R. Li, P. Liang, S. Weisong, and L. Yang, “Knowledge-based multi-agent framework for automated software architecture design, ” inProceedings of the 33rd ACM International Conference on the Foundations of Software Engineering (FSE) IVR Track. ACM, 2025

    2025

  5. [13]

    Shaw and D

    M. Shaw and D. Garlan, Software Architecture: Perspectives on An Emerging Discipline . Prentice Hall, 1996, vol. 1

    1996

  6. [14]

    Software architecture in practice: Challenges and opportunities,

    Z. Wan, Y. Zhang, X. Xia, Y. Jiang, and D. Lo, “Software architecture in practice: Challenges and opportunities, ” in Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). ACM, 2023, pp. ...

    2023

  7. [15]

    The architecture analysis & design language (AADL): An introduction,

    P. H. Feiler, D. P. Gluch, and J. J. Hudak, “The architecture analysis & design language (AADL): An introduction, ” Tech. Rep. CMU/SEI-2006-TN-011, 2006

    2006

  8. [16]

    A classification and comparison framework for software architecture description languages,

    N. Medvidovic and R. N. Taylor, “A classification and comparison framework for software architecture description languages, ”IEEE Transactions on Software Engineering , vol. 26, no. 1, pp. 70–93, 2000

    2000

  9. [17]

    S. J. Mellor, K. Scott, A. Uhl, and D. Weise,MDA Distilled: Principles of Model-Driven Architecture . Addison-Wesley Professional, 2004

    2004

  10. [18]

    Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

    E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software . Addison-Wesley Professional, 2004

    2004

  11. [19]

    ATAM: Method for architecture evaluation,

    R. Kazman, M. Klein, and P. Clements, “ATAM: Method for architecture evaluation, ” Tech. Rep. CMU/SEI-2000-TR-004, 2000

    2000

  12. [20]

    Towards human-bot collaborative software architecting with chatgpt,

    A. Ahmad, M. Waseem, P. Liang, M. Fahmideh, M. S. Aktar, and T. Mikkonen, “Towards human-bot collaborative software architecting with chatgpt, ” inProceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering (EASE). ACM, 2023, pp. 279–285

    2023

  13. [21]

    Generative ai for software architecture. applications, challenges, and future directions,

    M. Esposito, X. Li, S. Moreschini, N. Ahmad, T. Cerny, K. Vaidhyanathan, V. Lenarduzzi, and D. Taibi, “Generative ai for software architecture. applications, challenges, and future directions, ”arXiv preprint arXiv:2503.13310, 2025

    2025 arXiv

  14. [22]

    Software architecture meets llms: A systematic literature review,

    L. Schmid, T. Hey, M. Armbruster, S. Corallo, D. Fuchß, J. Keim, H. Liu, and A. Koziolek, “Software architecture meets llms: A systematic literature review, ”arXiv preprint arXiv:2505.16697, 2025. ACM Trans. Softw. Eng. Methodol., Vol. 0, No. 0, Article 0. Publication date: 20...

    2025 arXiv

  15. [23]

    From requirements to architecture: An ai-based journey to semi-automatically generate software architectures,

    T. Eisenreich, S. Speth, and S. Wagner, “From requirements to architecture: An ai-based journey to semi-automatically generate software architectures, ” inProceedings of the 1st International Workshop on Designing Software (Designing) . ACM, 2024, pp. 52–55

    2024

  16. [24]

    Can LLMs Generate Architectural Design Decisions?-An Exploratory Empirical study,

    R. Dhar, K. Vaidhyanathan, and V. Varma, “Can LLMs Generate Architectural Design Decisions?-An Exploratory Empirical study, ”arXiv preprint arXiv:2403.01709, 2024

    2024 arXiv

  17. [25]

    The 4 + 1 view model of architecture,

    P. B. Kruchten, “The 4 + 1 view model of architecture, ”IEEE Software, vol. 12, no. 6, pp. 42–50, 1995

    1995

  18. [26]

    An evaluation of requirements modeling for cyber- physical systems via LLMs,

    D. Jin, S. Zhao, Z. Jin, X. Chen, C. Wang, Z. Fang, and H. Xiao, “An evaluation of requirements modeling for cyber- physical systems via LLMs, ”arXiv preprint arXiv:2408.02450, 2024

    2024 arXiv

  19. [27]

    Pure: A dataset of public requirements documents,

    A. Ferrari, G. O. Spagnolo, and S. Gnesi, “Pure: A dataset of public requirements documents, ” inProceedings of the 25th IEEE International Requirements Engineering conference (RE) . IEEE, 2017, pp. 502–505

    2017

  20. [28]

    Intelligent program synthesis framework and key scientific problems for embedded software,

    M. Yang, B. Gu, Z. Duan, Z. Jin, N. Zhan, Y. Dong, C. Tian, G. Li, X. Dong, and X. Li, “Intelligent program synthesis framework and key scientific problems for embedded software, ”Chinese Space Science and Technology, vol. 42, no. 4, pp. 1–7, 2022

    2022

  21. [29]

    Gpt-4 technical report,

    J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, and S. Anadkat, “Gpt-4 technical report, ” Tech. Rep., 2023

    2023

  22. [30]

    The llama 3 herd of models,

    A. Dubey et al., “The llama 3 herd of models, ”arXiv preprint arXiv:2407.21783, 2024

    2024 arXiv

  23. [31]

    DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning,

    D. Guo, D. Yang, H. Zhang, J. Song, R. Zhang, R. Xu, Q. Zhu, S. Ma, P. Wang, X. Biet al., “DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, ”arXiv preprint arXiv:2501.12948, 2025

    2025 arXiv

  24. [32]

    Wohlin, P

    C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and A. Wesslén,Experimentation in Software Engineering . Springer Science & Business Media, 2012

    2012

  25. [33]

    Replication Package for the Paper: MAAD: Automate Software Architecture Design through Knowledge-Driven Multi-Agent Collaboration

    R. Li, Y. Zhang, X. Zhou, P. Liang, W. Sun, J. Xuan, Z. Jin, and Y. Liu, “Replication Package for the Paper: MAAD: Automate Software Architecture Design through Knowledge-Driven Multi-Agent Collaboration. ” https://github.com/ RuiyinL/MAAD, 2025

    2025

  26. [34]

    L. Bass, P. Clements, and R. Kazman,Software Architecture in Practice (3rd Edition), 3rd ed. Addison-Wesley Professional, 2012

    2012

  27. [35]

    Retrieval-augmented generation for large language models: A survey,

    Y. Gao, Y. Xiong, X. Gao, K. Jia, J. Pan, Y. Bi, Y. Dai, J. Sun, M. Wang, and H. Wang, “Retrieval-augmented generation for large language models: A survey, ”arXiv preprint abs/2312.10997v5, 2024

    2024 arXiv

  28. [36]

    Do Large Language Models Contain Software Architectural Knowledge? An Exploratory Case Study with GPT,

    M. Soliman and J. Keim, “Do Large Language Models Contain Software Architectural Knowledge? An Exploratory Case Study with GPT, ” inProceedings of the 22nd IEEE International Conference on Software Architecture (ICSA) . IEEE, 2025, pp. 13–24. ACM Trans. Softw. Eng. Methodol., ...

    2025

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.