pith. sign in

arxiv: 2604.08293 · v1 · submitted 2026-04-09 · 💻 cs.SE · cs.AI

CIAO - Code In Architecture Out - Automated Software Architecture Documentation with Large Language Models

Marco De Luca , Tiziano Santilli , Domenico Amalfitano , Anna Rita Fasolino , Patrizio Pelliccione This is my paper

Pith reviewed 2026-05-10 17:20 UTC · model grok-4.3

classification 💻 cs.SE cs.AI
keywords software architecture documentationlarge language modelsautomated documentationsystem-level architectureISO 42010C4 modelGitHub repositoriesdeveloper evaluation
0
0 comments X

The pith

A structured standards-based workflow lets LLMs generate usable system-level architecture documentation directly from GitHub repositories.

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

The paper presents CIAO as a defined process that feeds a repository into large language models and produces coherent architectural documentation following a template drawn from ISO/IEC/IEEE 42010, SEI Views & Beyond, and the C4 model. This addresses the frequent absence of system-wide descriptions that help teams understand overall structure rather than isolated code pieces. Developers who contributed to the evaluated projects reviewed the output and found it generally valuable, comprehensible, and aligned with the source code. The process completes in minutes and incurs low cost, showing that guided LLMs can deliver practical documentation without heavy manual effort.

Core claim

By following a standards-derived template through a repeatable LLM workflow, the CIAO process produces system-level architectural documentation that contributors to the original repositories judge as valuable, comprehensible, and broadly accurate with respect to the code, while operating in only a few minutes at modest expense.

What carries the argument

The CIAO workflow, a sequenced LLM process that ingests a GitHub repository and assembles documentation according to a template combining ISO/IEC/IEEE 42010, SEI Views & Beyond, and the C4 model.

Load-bearing premise

That LLMs following the defined workflow and templates will output documentation that accurately captures the system architecture without major omissions or inaccuracies, as judged by subjective review from contributing developers.

What would settle it

Independent verification by several developers of the same project showing systematic mismatches between the generated documentation and the actual codebase structure or behavior.

Figures

Figures reproduced from arXiv: 2604.08293 by Anna Rita Fasolino, Domenico Amalfitano, Marco De Luca, Patrizio Pelliccione, Tiziano Santilli.

Figure 1
Figure 1. Figure 1: Overview of the CIAO automated documentation workflow. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Distribution of participants’ Likert-scale ratings for RQ1 [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Distribution of participants’ Likert-scale ratings for RQ2 [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Distribution of participants’ Likert-scale ratings for RQ3 - General [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Distribution of participants’ Likert-scale ratings for RQ3 - Section [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
read the original abstract

Software architecture documentation is essential for system comprehension, yet it is often unavailable or incomplete. While recent LLM-based techniques can generate documentation from code, they typically address local artifacts rather than producing coherent, system-level architectural descriptions. This paper presents a structured process for automatically generating system-level architectural documentation directly from GitHub repositories using Large Language Models. The process, called CIAO (Code In Architecture Out), defines an LLM-based workflow that takes a repository as input and produces system-level architectural documentation following a template derived from ISO/IEC/IEEE 42010, SEI Views \& Beyond, and the C4 model. The resulting documentation can be directly added to the target repository. We evaluated the process through a study with 22 developers, each reviewing the documentation generated for a repository they had contributed to. The evaluation shows that developers generally perceive the produced documentation as valuable, comprehensible, and broadly accurate with respect to the source code, while also highlighting limitations in diagram quality, high-level context modeling, and deployment views. We also assessed the operational cost of the process, finding that generating a complete architectural document requires only a few minutes and is inexpensive to run. Overall, the results indicate that a structured, standards-oriented approach can effectively guide LLMs in producing system-level architectural documentation that is both usable and cost-effective.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 3 minor

Summary. The paper introduces CIAO, a structured LLM workflow that ingests a GitHub repository and outputs system-level architectural documentation following a template derived from ISO/IEC/IEEE 42010, SEI Views & Beyond, and the C4 model. The central claim is that this standards-oriented process produces documentation that 22 contributing developers perceive as valuable, comprehensible, and broadly accurate, while being inexpensive (a few minutes and low cost) to generate.

Significance. If the results hold, the work shows a practical, template-guided method for automating system-level architecture documentation, an area where manual effort is high and coverage is often poor. Strengths include the explicit use of established standards for structure, the direct developer usability study, and the operational cost assessment. These elements support the claim that such an approach can be both usable and cost-effective for real repositories.

major comments (2)
  1. [§4 and §5] §4 (Developer Study) and §5 (Results): The accuracy and completeness claims rest on subjective ratings from 22 developers who contributed to the evaluated repositories. No ground-truth architecture documents, independent architect reviews, inter-rater reliability statistics, or objective metrics (e.g., component coverage, view completeness scores) are reported. This setup risks confirmation bias, as reviewers may accept LLM outputs that align with their existing mental models while missing high-level omissions or hallucinations.
  2. [§3 and §4.2] §3 (CIAO Process) and §4.2: The workflow relies on LLM prompting with the defined templates to ensure system-level fidelity, yet no mechanism is described for detecting or correcting code-to-document mismatches (e.g., incorrect component boundaries or missing deployment views). The paper notes limitations in diagram quality and deployment views but does not quantify how often these occur or provide mitigation beyond post-generation review.
minor comments (3)
  1. [Abstract and §1] The abstract and §1 could more explicitly distinguish the contribution from prior LLM-based documentation generators that focus on local artifacts (e.g., method-level comments) versus system-level views.
  2. [Figures and §5] Figure captions and the description of generated diagrams should clarify which C4 levels are produced and how visual quality issues were assessed by participants.
  3. [§4.1] The paper would benefit from a table summarizing the 22 repositories (size, domain, languages) and the exact prompts/templates used in the workflow for reproducibility.

Simulated Author's Rebuttal

2 responses · 2 unresolved

We thank the referee for their insightful comments on our manuscript. We have carefully considered the points raised regarding the evaluation methodology and the robustness of the CIAO process. Our responses to the major comments are provided below, and we indicate where revisions will be made to the manuscript.

read point-by-point responses

  1. Referee: [§4 and §5] §4 (Developer Study) and §5 (Results): The accuracy and completeness claims rest on subjective ratings from 22 developers who contributed to the evaluated repositories. No ground-truth architecture documents, independent architect reviews, inter-rater reliability statistics, or objective metrics (e.g., component coverage, view completeness scores) are reported. This setup risks confirmation bias, as reviewers may accept LLM outputs that align with their existing mental models while missing high-level omissions or hallucinations.

    Authors: We acknowledge the limitations of relying solely on subjective ratings from contributing developers, which may indeed introduce confirmation bias. Our rationale for this study design was to assess the practical value and perceived accuracy from the perspective of those most familiar with the codebases, as external reviewers would lack this context. Ground-truth architecture documents are not available for the selected repositories, which underscores the motivation for our work. We did not compute inter-rater reliability because each participant evaluated a unique repository. However, we agree that additional objective measures would strengthen the claims. In the revised manuscript, we will expand the discussion in §5 to explicitly address potential biases and include suggestions for future objective evaluations, such as component coverage metrics. We will also report any available statistics from the study on specific issues raised. revision: partial

  2. Referee: [§3 and §4.2] §3 (CIAO Process) and §4.2: The workflow relies on LLM prompting with the defined templates to ensure system-level fidelity, yet no mechanism is described for detecting or correcting code-to-document mismatches (e.g., incorrect component boundaries or missing deployment views). The paper notes limitations in diagram quality and deployment views but does not quantify how often these occur or provide mitigation beyond post-generation review.

    Authors: The CIAO workflow is intentionally positioned as a generation aid rather than a fully autonomous system, with the expectation that generated documentation undergoes human review before integration into the repository. No automated mismatch detection is included because current LLM capabilities do not reliably identify high-level semantic errors without external verification tools, which would add significant overhead. Regarding quantification, the developer study collected feedback on specific limitations, and we can extract and report the prevalence of comments related to diagram quality and deployment views in the results section. We will revise §4.2 and §5 to include this quantification and clarify that post-generation review is the primary mitigation strategy, consistent with standard practices in software architecture documentation. revision: yes

standing simulated objections not resolved
  • We cannot provide ground-truth architecture documents since they were not present in the evaluated open-source repositories.
  • Independent architect reviews were not feasible within the scope and resources of this study.

Circularity Check

0 steps flagged

No significant circularity in derivation chain

full rationale

The paper presents an LLM workflow guided by external standards (ISO/IEC/IEEE 42010, SEI Views & Beyond, C4 model) and evaluates it via a new study with 22 developers reviewing generated docs for repositories they contributed to. No equations, fitted parameters, or predictions appear. No self-citations are load-bearing for the central claim; templates and process are defined directly in the paper without reducing to prior self-work by construction. Evaluation uses subjective reviews against developer knowledge of the code, which is independent of any fitted inputs or self-definitional loops. This is a standard empirical software engineering study with no reduction of results to inputs.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the domain assumption that LLMs can synthesize coherent system-level views from raw code when given structured prompts and standards-based templates. No free parameters or invented entities are introduced.

axioms (1)
  • domain assumption LLMs can be effectively guided by templates derived from ISO/IEC/IEEE 42010, SEI Views & Beyond, and C4 model to produce usable system-level architecture documentation
    This assumption underpins the entire CIAO workflow and its claim of effectiveness.

pith-pipeline@v0.9.0 · 5546 in / 1182 out tokens · 36932 ms · 2026-05-10T17:20:36.070394+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Towards LLM-Assisted Architecture Recovery for Real-World ROS~2 Systems: An Agent-Based Multi-Level Approach to Hierarchical Structural Architecture Reconstruction

    cs.SE 2026-05 unverdicted novelty 4.0

    An enhanced LLM-assisted pipeline with refined prompting and multi-level staged representations improves consistency, scalability, and robustness when recovering hierarchical architectures from a real-world ROS 2 disa...

Reference graph

Works this paper leans on

81 extracted references · 81 canonical work pages · cited by 1 Pith paper · 1 internal anchor

  1. [1]

    Architectural mismatch: Why reuse is still so hard,

    D. Garlan et al., “Architectural mismatch: Why reuse is still so hard,” IEEE Software, vol. 26, no. 4, pp. 66–69, July 2009

    work page 2009

  2. [2]

    Architectural technical debt: A grounded theory,

    R. Verdecchia et al., “Architectural technical debt: A grounded theory,” in Software Architecture: 14th European Conference, ECSA 2020, L’Aquila, Italy, September 14–18, 2020, Proceedings. Berlin, Hei- delberg: Springer-Verlag, 2020

    work page 2020

  3. [3]

    Technical debt: From metaphor to theory and practice,

    P. Kruchten et al., “Technical debt: From metaphor to theory and practice,” IEEE Softw., vol. 29, no. 6, p. 18–21, Nov. 2012. [Online]. Available: https://doi.org/10.1109/MS.2012.167

    work page doi:10.1109/ms.2012.167 2012

  4. [4]

    An empirical study of architectural decay in open- source software,

    D. M. Le et al., “An empirical study of architectural decay in open- source software,” in 2018 IEEE International Conference on Software Architecture (ICSA), 2018

    work page 2018

  5. [5]

    ISO/IEC/IEEE 42010:2011 systems and software engineering— architecture description,

    “ISO/IEC/IEEE 42010:2011 systems and software engineering— architecture description,” International Organization for Standardization, 2011

    work page 2011

  6. [6]

    Clements, F

    P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, P. Merson, and J. Stafford, Documenting Software Architectures: Views and Beyond. Addison-Wesley, 2010

    work page 2010

  7. [7]

    Large language models for software engineering: A systematic literature review,

    Z. Fan, R. Liu, X. Chen, and H. Yu, “Large language models for software engineering: A systematic literature review,” ACM Computing Surveys, 2024

    work page 2024

  8. [8]

    A survey on large language models for software engineering,

    F. Zhang, Q. Kang, and D. Yu, “A survey on large language models for software engineering,” arXiv preprint arXiv:2308.11679, 2023

    work page arXiv 2023

  9. [9]

    A survey on large language models for code generation,

    J. Jiang, F. Wang, J. Shen, S. Kim, and S. Kim, “A survey on large language models for code generation,” 2024

    work page 2024

  10. [10]

    Inferfix: End-to-end program repair with llms,

    M. Jin et al., “Inferfix: End-to-end program repair with llms,” in Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2023

    work page 2023

  11. [11]

    The state of open source and ai: Github octoverse report,

    GitHub, “The state of open source and ai: Github octoverse report,” https://octoverse.github.com/, 2023

    work page 2023

  12. [12]

    Extracting rest api endpoints from mi- croservices using llm agents,

    O. Chaplia and H. Klym, “Extracting rest api endpoints from mi- croservices using llm agents,” in 2024 14th International Conference on Dependable Systems, Services and Technologies (DESSERT), 2024, pp. 1–7

    work page 2024

  13. [13]

    Make llm a testing expert: Bringing human-like interaction to mobile gui testing via functionality- aware decisions

    D. Nam et al., “Using an llm to help with code understanding,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, ser. ICSE ’24. New York, NY , USA: Association for Computing Machinery, 2024. [Online]. Available: https://doi.org/10.1145/3597503.3639187

    work page doi:10.1145/3597503.3639187 2024

  14. [14]

    Using large language models to generate concise and understandable test case summaries,

    N. Djajadi et al., “Using large language models to generate concise and understandable test case summaries,” in 2025 IEEE/ACM 33rd International Conference on Program Comprehension (ICPC), 2025, pp. 322–326

    work page 2025

  15. [15]

    Xu et al., AutoReqGen: A Pipeline Approach for Automated Requirements Generation from Source Code, 07 2025, pp

    R. Xu et al., AutoReqGen: A Pipeline Approach for Automated Requirements Generation from Source Code, 07 2025, pp. 444–455

    work page 2025

  16. [16]

    Using large language models to extract uml class diagrams from java programs,

    H. A. Siala and K. Lano, “Using large language models to extract uml class diagrams from java programs,” in 2025 8th International Conference on Software and System Engineering (ICoSSE), 2025, pp. 70–74

    work page 2025

  17. [17]

    Towards an in-context llm-based approach for automating the definition of model views,

    J. Miranda et al., “Towards an in-context llm-based approach for automating the definition of model views,” 2024

    work page 2024

  18. [18]

    Mdre-llm: A tool for analyzing and applying llms in software reverse engineering,

    A. Boronat and J. Mustafa, “Mdre-llm: A tool for analyzing and applying llms in software reverse engineering,” in 2025 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2025, pp. 850–854

    work page 2025

  19. [19]

    Automated domain modeling with large language models: A comparative study,

    K. Chen et al., “Automated domain modeling with large language models: A comparative study,” in 2023 ACM/IEEE 26th International Conference on Model Driven Engineering Languages and Systems (MODELS), 2023

    work page 2023

  20. [20]

    Brown, The C4 Model for Visualising Software Architecture

    S. Brown, The C4 Model for Visualising Software Architecture. Leanpub, 2018. [Online]. Available: https://c4model.com

    work page 2018

  21. [21]

    A survey of reverse engineering and program compre- hension,

    M. L. Nelson, “A survey of reverse engineering and program compre- hension,” ArXiv, vol. abs/cs/0503068, 2005

    work page internal anchor Pith review arXiv 2005

  22. [22]

    Comparison of software architecture reverse engineering methods,

    C. Stringfellow et al., “Comparison of software architecture reverse engineering methods,” Information and Software Technology, vol. 48, no. 7, pp. 484–497, 2006

    work page 2006

  23. [23]

    An open visualization toolkit for reverse architecting,

    A. Telea et al., “An open visualization toolkit for reverse architecting,” in Proceedings 10th International Workshop on Program Comprehension, 2002

    work page 2002

  24. [24]

    A comparative analysis of software architecture recovery techniques,

    J. Garcia et al., “A comparative analysis of software architecture recovery techniques,” in 2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE), 2013, pp. 486–496

    work page 2013

  25. [25]

    Controlling software architecture erosion: A survey,

    “Controlling software architecture erosion: A survey,” Journal of Systems and Software, 2012

    work page 2012

  26. [26]

    Architecture as code,

    A. Bucaioni et al., “Architecture as code,” in 2025 IEEE 22nd International Conference on Software Architecture (ICSA). IEEE, 2025, pp. 187–198

    work page 2025

  27. [27]

    Improving the consistency and usefulness of architec- ture descriptions: Guidelines for architects,

    R. Wohlrab et al., “Improving the consistency and usefulness of architec- ture descriptions: Guidelines for architects,” in 2019 IEEE International Conference on Software Architecture (ICSA), 2019, pp. 151–160

    work page 2019

  28. [28]

    Static and dynamic reverse engineering techniques for java software systems,

    T. Syst ¨a, “Static and dynamic reverse engineering techniques for java software systems,” 2000

    work page 2000

  29. [29]

    Revealer: a lexical pattern matcher for architecture recovery,

    M. Pinzger et al., “Revealer: a lexical pattern matcher for architecture recovery,” in Ninth Working Conference on Reverse Engineering, 2002. Proceedings., 2002, pp. 170–178

    work page 2002

  30. [30]

    Helping program comprehension of large software systems by identifying their most important classes,

    I. S ¸ora, “Helping program comprehension of large software systems by identifying their most important classes,” in Evaluation of Novel Approaches to Software Engineering, L. A. Maciaszek and J. Filipe, Eds. Cham: Springer International Publishing, 2016, pp. 122–140

    work page 2016

  31. [31]

    Automatic semantic augmentation of language model prompts (for code summarization),

    T. Ahmed et al., “Automatic semantic augmentation of language model prompts (for code summarization),” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, 2024

    work page 2024

  32. [32]

    Evaluating large language models for real-world vulnerability repair in c/c++ code,

    L. Zhang et al., “Evaluating large language models for real-world vulnerability repair in c/c++ code,” in Proceedings of the 10th ACM International Workshop on Security and Privacy Analytics, 2024

    work page 2024

  33. [33]

    Llms for science: Usage for code generation and data analysis,

    M. Nejjar, L. Zacharias, F. Stiehle, and I. Weber, “Llms for science: Usage for code generation and data analysis,” Journal of Software: Evolution and Process, 2023

    work page 2023

  34. [34]

    Pre-train, prompt, and predict: A systematic survey of prompting methods in natural language processing,

    P. Liu et al., “Pre-train, prompt, and predict: A systematic survey of prompting methods in natural language processing,” ACM Comput. Surv., vol. 55, no. 9, Jan. 2023

    work page 2023

  35. [35]

    Uncovering intention through llm-driven code snippet description generation,

    Y . S. Nugroho et al., “Uncovering intention through llm-driven code snippet description generation,” in 2025 International Conference on Smart Computing, IoT and Machine Learning (SIML), 2025, pp. 1–6

    work page 2025

  36. [36]

    Leveraging llms for legacy code modernization: Evalu- ation of llm-generated documentation,

    C. Diggs, et al., “Leveraging llms for legacy code modernization: Evalu- ation of llm-generated documentation,” in2025 IEEE/ACM International Workshop on Large Language Models for Code (LLM4Code), 2025, pp. 177–184

    work page 2025

  37. [37]

    Automated software architecture design recovery from source code using llms,

    D. Amalfitano, M. D. Luca, T. Santilli, P. Pelliccione, and A. R. Fasolino, “Automated software architecture design recovery from source code using llms,” in Software Architecture. Cham: Springer Nature Switzerland, 2026, pp. 73–89

    work page 2026

  38. [38]

    A comparison of large language mod- els and model-driven reverse engineering for reverse engineering,

    H. Siala and K. Lano, “A comparison of large language mod- els and model-driven reverse engineering for reverse engineering,” Frontiers in Computer Science, vol. 7, 2025, publisher Copyright: Copyright © 2025 Siala and Lano

    work page 2025

  39. [39]

    Evaluating chatgpt’s proficiency in understanding and answering microservice architecture queries using source code insights,

    Q. Caballero et al., “Evaluating chatgpt’s proficiency in understanding and answering microservice architecture queries using source code insights,” SN Computer Science, 2024

    work page 2024

  40. [40]

    Using generative artificial intelligence for sug- gesting software architecture patterns from requirements,

    B. Gustrowsky et al., “Using generative artificial intelligence for sug- gesting software architecture patterns from requirements,” in Intelligent Systems and Applications, 2024

    work page 2024

  41. [41]

    State of Practice: LLMs in Software Engineering and Software Architecture ,

    J. Jahic and A. Sami, “ State of Practice: LLMs in Software Engineering and Software Architecture ,” in2024 IEEE 21st International Conference on Software Architecture Companion (ICSA-C), 2024

    work page 2024

  42. [42]

    Automating software documentation: Employing llms for precise use case description,

    L. Naimi, et al., “Automating software documentation: Employing llms for precise use case description,” Procedia Computer Science, vol. 246, pp. 1346–1354, 2024, 28th International Conference on Knowledge Based and Intelligent information and Engineering Systems (KES 2024). [Online]. Available: https://www.sciencedirect. com/science/article/pii/S1877050924026176

    work page 2024

  43. [43]

    Evaluating large language models in exercises of uml use case diagrams modeling,

    G. Garaccione et al., “Evaluating large language models in exercises of uml use case diagrams modeling,” in 2025 IEEE/ACM International Workshop on Natural Language-Based Software Engineering (NLBSE), 2025, pp. 41–44

    work page 2025

  44. [44]

    Naghshzan, Automating API Documentation with LLMs: A BERTopic Approach

    A. Naghshzan, Automating API Documentation with LLMs: A BERTopic Approach. New York, NY , USA: Association for Computing Machinery, 2025, p. 1013–1015. [Online]. Available: https://doi.org/10.1145/3696630.3728615

    work page doi:10.1145/3696630.3728615 2025

  45. [45]

    Bala et al., ChatGPT for Tailoring Software Documentation for Managers and Developers, 01 2025, pp

    S. Bala et al., ChatGPT for Tailoring Software Documentation for Managers and Developers, 01 2025, pp. 103–109

    work page 2025

  46. [46]

    Generative ai efficiency and effectiveness in software project documentation review process,

    K. A. Demir, et al., “Generative ai efficiency and effectiveness in software project documentation review process,” in 2025 International Conference on Artificial Intelligence, Computer, Data Sciences and Applications (ACDSA), 2025, pp. 1–7

    work page 2025

  47. [47]

    Codedocs: Genai to generate documentation from git repositories,

    A. Emerson, T. Meehan, M. Rogers, W. Cowen, and C. Darabos, “Codedocs: Genai to generate documentation from git repositories,” in Practice and Experience in Advanced Research Computing 2025: The Power of Collaboration, ser. PEARC ’25. New York, NY , USA: Association for Computing Machinery, 2025. [Online]. Available: https://doi.org/10.1145/3708035.3736102

    work page doi:10.1145/3708035.3736102 2025

  48. [48]

    Document- ing software architectures: views and beyond,

    P. Clements, D. Garlan, R. Little, R. Nord, and J. Stafford, “Document- ing software architectures: views and beyond,” in 25th International Conference on Software Engineering, 2003. Proceedings., 2003, pp. 740–741

    work page 2003

  49. [49]

    [Online]

    Software, systems and enterprise – Architecture description, International Standard ISO/IEC/IEEE 42 010:2022, November 2022. [Online]. Available: https://www.iso.org/standard/74393.html

    work page 2022

  50. [50]

    https://c4model.info/\#app

    work page

  51. [51]

    Adopting the c4 model for lightweight architecture modeling - an experience report,

    R. Jongeling, N. J. Strøm, L. P. T. Nissen, M. Kitchen, and J. Carlson, “Adopting the c4 model for lightweight architecture modeling - an experience report,” inSoftware Engineering and Advanced Applications, D. Taibi and D. Smite, Eds. Cham: Springer Nature Switzerland, 2026, pp. 393–409

    work page 2026

  52. [52]

    https://plantuml.com/

    work page

  53. [53]

    A comprehensive taxonomy of prompt engineering techniques for large language models,

    Y . Y . Liu, Z. Zheng, F. Zhang, and et al., “A comprehensive taxonomy of prompt engineering techniques for large language models,” Front. Comput. Sci., vol. 20, p. 2003601, 2026. [Online]. Available: https://doi.org/10.1007/s11704-025-50058-z

    work page doi:10.1007/s11704-025-50058-z 2026

  54. [54]

    Better zero-shot reasoning with role-play prompting,

    A. Kong, S. Zhao, H. Chen, Q. Li, Y . Qin, R. Sun, X. Zhou, E. Wang, and X. Dong, “Better zero-shot reasoning with role-play prompting,” in Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (V olume 1: Long Papers), K. Duh, H. Gomez, and S. Bethard, Eds. Mexico Ci...

    work page 2024

  55. [55]

    Large language models understand and can be enhanced by emotional stimuli,

    C. Li, J. Wang, K. Zhu, Y . Zhang, W. Hou, J. Lian, and X. Xie, “Large language models understand and can be enhanced by emotional stimuli,”

    work page

  56. [56]

    Available: https://api.semanticscholar.org/CorpusID: 260126019

    [Online]. Available: https://api.semanticscholar.org/CorpusID: 260126019

    work page

  57. [57]

    Language models are few-shot learners,

    T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, S. Agarwal, A. Herbert-V oss, G. Krueger, T. Henighan, R. Child, A. Ramesh, D. Ziegler, J. Wu, C. Winter, C. Hesse, M. Chen, E. Sigler, M. Litwin, S. Gray, B. Chess, J. Clark, C. Berner, S. McCandlish, A. Radford, I. Sutskever, and D. Amodei...

    work page 2020

  58. [58]

    Available: https://proceedings.neurips.cc/paper files/ paper/2020/file/1457c0d6bfcb4967418bfb8ac142f64a-Paper.pdf

    [Online]. Available: https://proceedings.neurips.cc/paper files/ paper/2020/file/1457c0d6bfcb4967418bfb8ac142f64a-Paper.pdf

    work page 2020

  59. [59]

    https://github.com/AntonioEmmanuele/Group-Key-Phemap

    work page

  60. [60]

    https://github.com/SalvatoreBarone/pyALS-RF/tree/tmr

    work page

  61. [61]

    https://github.com/rdinizcal/sa-bsn

    work page

  62. [62]

    https://github.com/SaraPettinari/ocean-lib

    work page

  63. [63]

    https://github.com/gianlucafilippone/robethichor

    work page

  64. [64]

    https://github.com/gianlucafilippone/springboot-microservices-development

    work page

  65. [65]

    https://github.com/DockerSecurityPlayground/DSP/tree/master/public

    work page

  66. [66]

    https://github.com/DockerSecurityPlayground/DSP/tree/master/app

    work page

  67. [67]

    https://github.com/QuTAM/QuFI

    work page

  68. [68]

    https://github.com/alessandrasomma28/BoMoDT

    work page

  69. [69]

    https://github.com/alessandrasomma28/m2dt

    work page

  70. [70]

    https://github.com/AposVinc/GymportalService

    work page

  71. [71]

    https://github.com/s4hri/pyicub

    work page

  72. [72]

    https://github.com/francescodaghero/treeco

    work page

  73. [73]

    https://github.com/Testing-Game-SAD-2023/A13/tree/main/T4/ gamerepo

    work page 2023

  74. [74]

    https://github.com/ykris152/rse2025-priv

    work page

  75. [75]

    https://github.com/deangelisdf/write2audiobook

    work page

  76. [76]

    https://github.com/deangelisdf/BF-JITcompiled

    work page

  77. [77]

    https://github.com/deangelisdf/visual novel pyarcade

    work page

  78. [78]

    https://github.com/VSecLab/SAM-CyFra

    work page

  79. [79]

    https://github.com/NS-unina/SCASS

    work page

  80. [80]

    https://github.com/NS-unina/OSINT-Collector

    work page

Showing first 80 references.