A ascensão das ferramentas de Inteligência Artificial Generativa transformou radicalmente a produtividade na engenharia de software. Hoje, assistentes de código conseguem gerar classes inteiras, refatorar algoritmos complexos e propor padrões de projeto em segundos.
No entanto, como Engenheiro de Software trabalhando em ambientes corporativos de alta complexidade, esbarrei repetidamente no maior gargalo dessas ferramentas: a alucinação contextual e a quebra de fronteiras arquiteturais.
Quem nunca viu uma IA sugerir a criação de um arquivo no diretório errado? Ou pior, fazer a camada de Domain depender diretamente de um componente de Infrastructure, violando frontalmente os princípios da Clean Architecture?
Para resolver esse problema de forma determinística, decidi criar o Code Property Graph (CPG): um ecossistema que mapeia toda a estrutura estática do código (camadas, namespaces, classes e dependências) e atua como uma "guarda de fronteira" contra as alucinações da IA.
🏗️ O Conceito: Mapeando Código como Conhecimento
O projeto, que disponibilizei de forma open-source no meu GitHub (CodePropertyGraph), foi desenhado em três grandes módulos, abraçando uma abordagem que chamo de Paradigma Híbrido (Relacional + Grafo).
- O Motor Híbrido: SQL com Alma de Grafo (1-Sql) Mapear dependências em bancos puramente relacionais costuma gerar tabelas associativas complexas. Por outro lado, forçar uma equipe a adotar um banco de grafos nativo (como Neo4j) apenas para essa análise pode gerar fricção operacional.
Minha solução foi criar um banco relacional otimizado para travessias. Uma tabela central CodeElement (o nó do grafo) armazena Classes, Interfaces e Records. Tabelas associativas como ElementDependency atuam como as arestas.
Com isso, antes de a IA gerar um código, o sistema pode rodar uma validação determinística:
SQL
-- Identificando violação clássica: Domain dependendo de Infrastructure
SELECT
SourceElem.Name AS ArquivoIncorreto,
TargetElem.Name AS DependenciaProibida
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';
Se a query retornar dados, a IA é bloqueada de prosseguir com a sugestão. Simples e infalível.
- O Cérebro: Backend em .NET 9.0 (2-BackEnd) Para orquestrar essa lógica, criei uma API robusta em .NET 9.0. Seguindo estritamente os princípios SOLID, implementei o padrão CQRS utilizando o MediatR.
Commands: Lidam com a ingestão pesada de metadados de código extraídos via analisadores estáticos (como o Roslyn).
Queries: Executam as validações arquiteturais em tempo real.
Tudo é abstraído pelo Repository Pattern, garantindo que as regras de negócio de validação arquitetural fiquem isoladas de como os dados estão persistidos.
- A Visão: Interactive Knowledge Graph com React (3-FrontEnd) Dados puros não fornecem intuição arquitetural. O módulo front-end, construído em React, consome a API do .NET 9 e renderiza a arquitetura inteira como um Knowledge Graph interativo (semelhante a um mapa mental complexo).
O desenvolvedor pode clicar em um módulo específico e ver imediatamente a árvore de dependências. Mais importante: ele pode "desenhar" uma intenção de nova feature, e o front-end validará em tempo real se essa nova estrutura fere o design do sistema, antes mesmo de uma única linha de código ser escrita.
🚀 Conclusão
A IA Generativa é um co-piloto extraordinário, mas nós ainda somos os arquitetos. Ao criar um Code Property Graph, damos à IA os "olhos" necessários para entender os limites de domínio e infraestrutura de nossas aplicações. Projetos estruturados com .NET 9, bancos de dados otimizados e interfaces interativas em React são a ponte para um desenvolvimento assistido por IA verdadeiramente seguro.
Sinta-se à vontade para explorar o código, enviar PRs ou discutir ideias no repositório do projeto!
English Version 🇬🇧 / 🇺🇸
This is a submission for the Google I/O Writing Challenge
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).
- 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.
- 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.
- 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!