Idea principale

Tenere un'ontologia di business aggiornata rispetto al codice richiede due operazioni di natura diversa, che vanno separate.

La prima è meccanica: stabilire con precisione cosa è cambiato. Uno script legge la cronologia Git ed elenca funzioni, classi, interfacce, moduli, firme di API e contratti esposti tramite MCP aggiunti, modificati o eliminati. Uno strumento come Tree-sitter permette di analizzare la struttura sintattica per identificare gli elementi toccati.

La seconda è semantica: capire se questi cambiamenti introducono, modificano o contraddicono un concetto di business. Una classe non è per forza un concetto; un nuovo package può essere solo una riorganizzazione; una funzione può implementare una regola senza costituire un concetto. È qui che entra in gioco un LLM, che confronta l'inventario con l'ontologia e con la richiesta che ha avviato lo sviluppo, e classifica ogni cambiamento: nuovo concetto, concetto che cambia significato, concetti diventati incoerenti, vocabolario che diverge, oppure cambiamento puramente tecnico.

Perché è importante

La separazione rende il controllo sostenibile. Non si chiede a un LLM di rileggere tutta l'applicazione a ogni modifica: si concentra la sua analisi su ciò che lo script ha indicato. E la parte che può essere esatta lo è, invece di essere affidata a un modello che potrebbe approssimarla.

Protegge anche l'ontologia dall'architettura: lo script descrive la struttura tecnica, l'LLM decide ciò che riguarda il dominio, e un'architettura esagonale o un codice disordinato non impongono la loro suddivisione al modello di dominio.

Sfumature e limiti

Un cambiamento di business reale può non lasciare alcuna traccia nei nomi: una condizione modificata all'interno di una funzione invariata sfugge a un inventario basato sui simboli. E il giudizio semantico produce falsi positivi il cui volume non è ancora noto.

Domande aperte

• Come rilevare una modifica di business che non cambia nessun nome di classe, di funzione o di firma?