Ideia principal

Manter uma ontologia de negócio atualizada em relação ao código exige duas operações de natureza diferente, que precisam ser separadas.

A primeira é mecânica: determinar com precisão o que mudou. Um script lê o histórico do Git e lista as funções, classes, interfaces, módulos, assinaturas de API e contratos expostos via MCP que foram adicionados, alterados ou removidos. Uma ferramenta como o Tree-sitter permite analisar a estrutura sintática para identificar os elementos afetados.

A segunda é semântica: entender se essas mudanças introduzem, alteram ou contradizem um conceito de negócio. Uma classe não é necessariamente um conceito; um pacote novo pode ser só uma reorganização; uma função pode implementar uma regra sem ser um conceito. É aí que entra um LLM, que confronta o inventário com a ontologia e com a solicitação que deu origem ao desenvolvimento, e classifica cada mudança: conceito novo, conceito que muda de sentido, conceitos que ficaram incoerentes entre si, vocabulário que diverge, ou mudança puramente técnica.

Por que isso importa

A separação torna a verificação viável. Você não pede a um LLM que releia a aplicação inteira a cada alteração: concentra a análise dele no que o script apontou. E a parte que pode ser exata é exata, em vez de ser confiada a um modelo que poderia fazer só uma aproximação.

Ela também protege a ontologia da arquitetura: o script descreve a estrutura técnica, o LLM decide o que é do domínio, e uma arquitetura hexagonal ou um código bagunçado não impõem o seu recorte ao modelo de domínio.

Nuances e limites

Uma mudança real de negócio pode não deixar nenhum rastro nos nomes: uma condição alterada dentro de uma função que não mudou escapa a um inventário baseado em símbolos. E o julgamento semântico produz falsos positivos num volume que ainda não é conhecido.

Questões em aberto

• Como detectar uma alteração de negócio que não muda nenhum nome de classe, de função ou de assinatura?