Idea principale

Un'ontologia di business può essere completata da una mappa: il concetto di fattura associato alle classi, funzioni, eventi e operazioni di API che contribuiscono alla sua implementazione. Queste associazioni non definiscono il concetto; dicono dove è implementato.

Questa distinzione rende possibili domande che nessuno dei due livelli permette da solo. Se si modifica il concetto di fattura, quali parti del codice rischiano di essere toccate? Se una funzione di business scompare, quale regola potrebbe non essere più implementata? Una nuova operazione di API espone un concetto esistente o rivela una nozione nuova? Una classe rinominata è un refactoring o un vero cambiamento del dominio?

La mappa può essere aggiornata man mano che arrivano le modifiche, ma ogni associazione deve conservare la sua prova: i file, i simboli e i cambiamenti osservati su cui si fonda.

Perché è importante

L'analisi d'impatto smette di dipendere dalla memoria della persona che conosce il codice. E pretendendo la prova si separano due cose che un LLM confonde facilmente: una corrispondenza dimostrata e una relazione semplicemente dedotta.

Sfumature e limiti

Una corrispondenza dedotta da un LLM somiglia in tutto e per tutto a una corrispondenza dimostrata. Senza la prova allegata, la mappa accumula collegamenti plausibili che nessuno sa più distinguere da quelli veri.

Anche la mappa invecchia: bisogna riesaminare le corrispondenze, con una frequenza che nulla ancora stabilisce.

Domande aperte

• Con quale frequenza bisogna riesaminare le corrispondenze tra concetti e codice perché restino affidabili?