Solving AI Hallucination in Software Architecture with Code Property Graphs and .NET 9

The rise of Generative AI tools has radically transformed software engineering productivity. Today, coding assistants can generate entire classes, refactor complex algorithms, and propose design patterns in seconds.

However, as a Software Engineer working in highly complex enterprise environments, I repeatedly hit the biggest bottleneck of these tools: contextual hallucination and the breaking of architectural boundaries.

Who hasn't seen an AI suggest creating a file in completely the wrong directory? Or worse, make the Domain layer directly depend on an Infrastructure component, blatantly violating the principles of Clean Architecture?

To solve this problem deterministically, I decided to build the Code Property Graph (CPG): an ecosystem that maps the entire static structure of the code (layers, namespaces, classes, and dependencies) and acts as a "border guard" against AI hallucinations.

The Concept: Mapping Code as Knowledge
The project, which I open-sourced on my GitHub (CodePropertyGraph), was designed in three major modules, embracing an approach I call the Hybrid Paradigm (Relational + Graph).

1. The Hybrid Engine: SQL with a Graph Soul (1-Sql) Mapping dependencies in purely relational databases usually generates complex associative tables. On the other hand, forcing a team to adopt a native graph database (like Neo4j) just for this analysis can cause operational friction.

My solution was to create a relational database optimized for traversals. A central CodeElement table (the graph node) stores Classes, Interfaces, and Records. Associative tables like ElementDependency act as the edges.

With this setup, before the AI generates code, the system can run a deterministic validation:

SQL
-- Identifying a classic violation: Domain depending on Infrastructure
SELECT
SourceElem.Name AS IncorrectFile,
TargetElem.Name AS ForbiddenDependency
FROM ElementDependency Dep
INNER JOIN CodeElement SourceElem ON Dep.SourceElementId = SourceElem.Id
INNER JOIN Layer SourceLayer ON SourceElem.LayerId = SourceLayer.Id
INNER JOIN CodeElement TargetElem ON Dep.TargetElementId = TargetElem.Id
INNER JOIN Layer TargetLayer ON TargetElem.LayerId = TargetLayer.Id
WHERE SourceLayer.Name = 'Domain' AND TargetLayer.Name = 'Infrastructure';

If the query returns any data, the AI is blocked from proceeding with the suggestion. Simple and bulletproof.

1. The Brain: .NET 9.0 Backend (2-BackEnd) To orchestrate this logic, I built a robust API in .NET 9.0. Strictly following SOLID principles, I implemented the CQRS pattern using MediatR.

Commands: Handle the heavy ingestion of code metadata extracted via static analyzers (like Roslyn).

Queries: Execute real-time architectural validations.

Everything is abstracted by the Repository Pattern, ensuring that the architectural validation business rules remain isolated from how the data is persisted.

1. The Vision: Interactive Knowledge Graph with React (3-FrontEnd) Raw data doesn't provide architectural intuition. The front-end module, built in React, consumes the .NET 9 API and renders the entire architecture as an interactive Knowledge Graph (similar to a complex mind map).

Developers can click on a specific module and immediately see its dependency tree. More importantly, they can "draw" the intent for a new feature, and the front-end will validate in real-time if this new structure violates the system's design—before a single line of code is written.

Conclusion
Generative AI is an extraordinary co-pilot, but we are still the architects. By creating a Code Property Graph, we give AI the "eyes" it needs to understand the domain and infrastructure boundaries of our applications. Projects structured with .NET 9, optimized databases, and interactive React interfaces are the bridge to truly safe AI-assisted development.

Feel free to explore the code, submit PRs, or discuss ideas over at the project repository!