The application of large language models (LLMs) in software engineering has expanded rapidly, supporting tasks such as code generation, system design, error correction, and documentation. However, LLMs face persistent challenges in multi-step development workflows, where accumulated design decisions, dependencies, and constraints require a structured, persistent memory. Existing approaches, including extended context windows and retrieval-augmented generation, rely on statistical similarity between text fragments and lack explicit, formal representations of the evolving system state, limiting their ability to maintain semantic coherence across development stages. We propose an architecture that integrates a dynamically evolving ontology, represented in OWL (Web Ontology Language), as a structured knowledge base, maintained automatically to reflect changes in the codebase and user interactions. OWL is a standard language for formal knowledge representation, allowing the explicit modeling of entities, relationships, and constraints in a machine-readable way. A secondary LLM (LLM2) functions as a context manager, querying the ontology using OWLready2 to retrieve structured information about entities, classes, methods, and associated constraints. This context is provided to the primary LLM (LLM1), which directly interacts with the user to generate code that adheres to both current requirements and historical design decisions. This hybrid approach combines symbolic knowledge representation with generative capabilities, enabling context-aware, semantically coherent, and explainable code generation. We validated the approach through a proof-of-concept implementation in a multi-stage object-oriented development scenario. Comparative evaluation using the same base model, with and without the ontology layer, showed that the ontology-enhanced configuration improved adherence to prior decisions, maintained semantic consistency across stages, and produced outputs that were more interpretable and reliable. These results demonstrate the potential of ontology-supported LLMs to facilitate long-term, semantically grounded software development.
Large language models (LLMs) have become essential tools in software engineering, supporting tasks
such as system design, code development, debugging, and documentation generation from natural
language descriptions [
In typical software projects, development is incremental: high-level architectural definitions are
established first and subsequently refined with additional components, constraints, and implementation
details. This iterative process produces a growing set of decisions, dependencies, and design rules that
must be preserved and referenced to maintain semantic consistency. Current LLMs, however, frequently
lose track of evolving context, leading to outputs that contradict or ignore earlier specifications [
To address these limitations, we propose an architecture that integrates a structured and dynamically
evolving knowledge base in the form of an OWL ontology [
Our approach combines the generative capabilities of LLMs with a dynamically updated ontology that captures the evolving state of the system. This structured memory provides domain-specific context to guide code generation, ensuring semantic consistency and alignment with prior design decisions.
By combining symbolic knowledge representation with generative capabilities, this architecture supports explainable, context-aware, and semantically coherent code generation. Comparative evaluations using the same base model, with and without the ontology layer, demonstrate that the ontologyenhanced configuration significantly improves adherence to prior design decisions and reduces inconsistencies in generated outputs, efectively bridging the gap between natural language interaction and formal software design rigor.
Large language models (LLMs) have transformed software engineering, establishing themselves as
efective assistants in tasks such as code synthesis, system design, debugging, and documentation
generation from natural language [
Complementarily, the literature has explored the use of ontologies to formally represent software
artifacts, relationships, and constraints, providing benefits in contextual reasoning, traceability, and
semantic coherence. For example, the OntoTrace V2.0 ontology allows the inference of links between
artifacts via SPARQL (SPARQL Protocol and RDF Query Language), yielding empirical improvements in
precision and speed for traceability tasks [
In parallel, multi-agent architectures have emerged that separate code generation from contextual
knowledge management. Configurations such as AutoGen and MetaGPT assign specific roles to diferent
agents to generate, review, and validate code in sequential stages, integrating external tools and
retrievalaugmented methods [
Although current approaches have advanced context management through retrieval-augmented generation or multi-agent architectures, a fundamental limitation remains: the absence of a structured memory that explicitly, persistently, and dynamically represents the evolving state of the system. None of the reviewed works integrates a dynamic ontology that is automatically updated during development and serves as a formal knowledge source to guide code generation. Our proposal addresses this gap by integrating an OWL ontology, maintained by a secondary language model, which models system entities, relationships, and constraints, enabling semantic reasoning over past decisions. This explicit symbolic memory complements the generative capabilities of the primary LLM, promoting sustained semantic coherence, traceability, and alignment throughout the entire development cycle, an aspect not previously explored at the intersection of LLMs and software engineering.
This section describes the architecture, implementation, and evaluation of the ontology-based contextual code generation system.
The motivation for the modular architecture stems from two common limitations in LLM-based code generation: first, the models’ tendency to produce code that is syntactically valid but semantically inconsistent with the target domain; and second, the challenge of injecting evolving domain knowledge into a conversational flow without retraining the model. By decoupling the generative component (LLM1) from the semantic control component (LLM2), we aimed to mitigate both issues.
The architecture was deliberately designed so that LLM1 never directly queries the ontology. Instead, it always obtains the relevant semantic context from LLM2, which is responsible for maintaining an accurate, up-to-date representation of the domain. This enforces a clean separation of concerns and allows for easy replacement or upgrade of either LLM without disrupting the pipeline.
The ontology itself serves as a persistent, machine-readable memory of the project domain. It actively participates in generation: its constraints influence prompt construction, and its structure adapts dynamically to new user requests. This bidirectional relationship between generation and knowledge representation is one of the key novelties of the method.
To further clarify the interaction flow, Figure 1 shows the step-by-step process from user request to final code generation, including context retrieval, code generation, ontology updates, and optional error handling.
The ontology builder extracts modules, classes, methods, attributes, and relationships directly from the codebase, operating independently of file naming conventions. This makes the approach agnostic to project structures, so diferent entry points (e.g., main.py or app.py) can be handled without errors.
LLM1 was implemented in Python using the LangChain [
Prompts to LLM1 were structured in three sections: (1) the user’s original request verbatim; (2) a context block summarizing ontology facts, often in tabular or key-value format; and (3) explicit formatting instructions for code syntax, inline comments, and docstring style. This format allowed for deterministic outputs while keeping flexibility for natural language variations.
LLM1 also implements an internal validation step to check semantic consistency against the ontologyenriched context. If inconsistencies are detected, LLM1 generates a warning or requests additional context from LLM2 before finalizing the code. This mechanism ensures that generated outputs adhere to domain constraints.
LLM2 acts as the intermediary between the ontology and LLM1. It uses gpt-4o to interpret user requests and code analysis results, generating precise OWLready2 update commands. LLM2 retrieves relevant ontology knowledge to inject into LLM1’s prompts and updates the ontology when new entities, relationships, or constraints are detected.
Future implementations may incorporate SPARQL-based queries for more advanced retrieval, but the current system relies on direct OWLready2 API calls. Retrieval is optimized to select only the relevant subset of ontology data, reducing prompt size and avoiding overload during inference.
The ontology was implemented in OWL using OWLready2, encapsulating core object-oriented programming concepts: modules, classes, attributes, methods, parameters, and return types. Each entity is enriched with datatype and relational constraints, including cardinality restrictions and domain-range specifications, to ensure semantic integrity and enable consistent reasoning over the model. Once stored, information in the ontology is preserved across updates, ensuring persistence of memory throughout the development process.
At initialization, the ontology begins as an empty schema that defines only the fundamental structures mentioned above. These classes serve as predefined containers that are gradually populated as the system analyzes the evolving codebase. In practice, LLM2 generates precise instructions for OWLready2 to insert new entities such as modules, classes, methods, or attributes whenever they are detected, as well as to modify or remove elements when changes occur in the source code. This incremental population process guarantees that the ontology remains synchronized with the actual state of the project at all times. Furthermore, because the ontology is serialized and stored as an OWL file on disk, it can be reloaded in subsequent sessions, ensuring that accumulated knowledge is never lost across executions and that memory persists independently of runtime constraints.
Incremental updates are continuously orchestrated by LLM2, which monitors the evolving codebase and triggers ontology modifications whenever new entities or relationships appear. Newly instantiated entities are linked through well-defined object properties, maintaining referential integrity, avoiding inconsistencies, and supporting full traceability between code artifacts and their semantic representations.
Although the current implementation relies on OWLready2 for direct API-driven access, future extensions will incorporate SPARQL queries to enable more sophisticated semantic searches and reasoning across entities. This will provide enhanced contextual awareness for code generation, facilitate automated refactoring, and open the door to more advanced reasoning strategies in large-scale projects.
Overall, this ontology-driven approach ensures that the LLM-generated code is not only syntactically correct but also semantically aligned with the underlying conceptual model. By combining persistence, incremental synchronization, and semantic reasoning, the system improves maintainability, traceability, and overall software quality, while laying the foundations for scalable and explainable AI-assisted software engineering.
The experiments were orchestrated using LangChain, which enables systematic control over prompt execution and context management across multiple LLM agents. The primary objective of the setup was to evaluate the efect of ontology-enriched context on code generation quality while minimizing variability due to stochastic sampling. Accordingly, the model temperature was set to 0.3 to favor determinism, while other parameters were maintained at their default values, ensuring a controlled baseline for comparison. Parameter Model Temperature Top-p Frequency penalty Presence penalty Max tokens Framework API Python version
Value gpt-4o
0.3 default default default default
LangChain OpenAI Chat API 3.11
The proof-of-concept implementation and sample datasets are available at https://github.com/ daraya78/LLM_Ontology_Mem_WAAI2025
To assess the feasibility of the proposed approach, we implemented a proof-of-concept system and evaluated it using a controlled software engineering scenario. The task involved the progressive development of a simplified object-oriented system for managing software project architectures. The development was divided into three sequential stages: project loading, requirement analysis, and architecture design. This progression was chosen to reflect a realistic software engineering workflow while maintaining manageable complexity for controlled experimentation.
The initial codebase, contained in a module named ejemplo3.py, was parsed and analyzed by the ontology builder. The parser successfully extracted structural elements and mapped them to ontological entities, ensuring that the representation was both machineinterpretable and aligned with the domain semantics. The system instantiated the following classes within the ontology: ProjectLoader_ejemplo3, RequirementAnalyzer_ejemplo3, and ArchitectureDesigner_ejemplo3. Each class was populated with its corresponding methods, along with metadata such as visibility, parameter types, return types, and textual descriptions derived from docstrings or inferred from naming conventions.
For example, the class ProjectLoader_ejemplo3 was associated with three public methods: __init__(source_path), load_projects(), and validate_project_name(name). The method load_projects() included a descriptive annotation indicating its purpose: "Loads projects from the specified source path". Similarly, RequirementAnalyzer_ejemplo3 defined methods for extracting and grouping requirements, while ArchitectureDesigner_ejemplo3 encapsulated logic for generating and summarizing architectural modules.
The populated ontology was serialized and stored in an OWL file ( ontologia.owl). This persisted representation served as the authoritative source of truth for subsequent development stages. Leveraging this internal state, the system could generate structured queries, which in turn enabled the retrieval of highly relevant development information. This structured context was then automatically integrated into prompts sent to LLM1, ensuring that the generated code was consistent with previously defined structures.
A preliminary qualitative evaluation was conducted by Hernan Astudillo (software architect) who examined whether the ontology-supported configuration preserved a coherent internal representation of the system across stages. The evaluation confirmed that the approach enabled the identification of previously defined elements, supported traceable and explainable code generation, and facilitated a structured interface for visualizing system components. As part of the visualization process, a highlevel system diagram was generated directly from the ontology, highlighting the interaction between components and their associated methods (see Figure 1).
These initial results conrfim the viability of using dynamic ontologies to maintain context and support structured reasoning in code generation tasks involving LLMs. While quantitative performance measures were not computed at this stage, the qualitative findings provide strong preliminary evidence of the approach’s promise.
The results obtained from the proof-of-concept system confirm the feasibility of using a dynamically
evolving ontology to support code generation tasks involving large language models (LLMs). The
system demonstrated the ability to maintain semantic consistency across multiple development stages,
validating the core hypothesis of this work: that a structured, external knowledge base can guide
generative models in a traceable and coherent manner. This observation is consistent with evidence that
coupling LLMs with external structured knowledge via retrieval, augmented generation, or knowledge
graphs improves factuality, controllability, and provenance [
One of the main strengths of the approach lies in the use of a formal OWL ontology to capture and persist the evolving design context. By storing classes, methods, attributes, and their associated constraints, the ontology acts as an explicit long-term memory that complements the inherently limited context window of current LLMs. This enables the system to recall previously defined elements and enforce design consistency without relying solely on prompt engineering or repeated manual input.
Another notable advantage is the interpretability of the generated outputs. In contrast to typical LLM-based code assistants, whose internal reasoning is opaque, our architecture makes each decision step explainable through direct references to ontological entities. The inclusion of semantic annotations, method signatures, and preconditions allows users to trace the rationale behind generated code, aligning the approach with explainable AI principles and making it more suitable for critical or regulated domains.
Nonetheless, there are limitations to consider. The evaluation conducted was qualitative and restricted to a simplified scenario, meaning that results may not generalize directly to large-scale, real-world projects. Additionally, the LLM parameters used were temperature = 0.3, top-p = default, frequency penalty = default, presence penalty = default, max tokens = default, which may have influenced output variability. While much of the workflow is automated, some tasks, particularly prompt validation and semantic accuracy checks, still require human oversight. This limits full automation and could be a bottleneck in larger deployments.
Future work should address scalability, as larger ontologies will require eficient reasoning strategies
and possibly modular decomposition to maintain performance. Another promising direction is the
integration of automated ontology validation tools to reduce human intervention. Furthermore, deeper
coupling between the LLM and the ontology, whether through specialized prompting strategies,
finetuning, or symbolic-neural hybrid methods, could enhance robustness and reduce ambiguity in context
interpretation. Similar directions have been highlighted by recent studies that couple LLMs with
structured knowledge sources, suggesting that hybrid symbolic–neural methods are a promising avenue
for long-term consistency (Edge et al., 2025; [
In conclusion, the proposed architecture demonstrates the potential of combining LLMs with dynamic ontologies to enable structured, explainable, and context-aware code generation. These findings lay the groundwork for developing AI-assisted software engineering tools capable of maintaining long-term semantic consistency, supporting human oversight, and adapting to evolving project requirements.
The authors acknowledge the support provided by the National Fund for Scientific and Technological Development (FONDECYT), Chile, through project No. 1251519 “Continual learning for recognizing abnormal activity patterns related to dementia in the elderly,” led by Prof. Carla Andrea Taramasco Toro (Universidad Andrés Bello).
The authors have not employed any Generative AI tools.