Idea principale

Verificare a posteriori il codice prodotto da un agente rispetto a un'ontologia di business funziona, ma troppo tardi: l'agente ha già creato classi, aggiunto metodi e scritto test intorno a una lettura sbagliata del business, e bisogna tornare su tutto questo.

Il TDD ha risolto lo stesso problema per il comportamento: si scrive il test prima del codice. Trasposto al modello di dominio, questo dà all'agente un ordine diverso. Prima di scrivere una riga, individua i concetti e le regole dell'ontologia toccati dalla richiesta, segnala le contraddizioni tra la richiesta e il modello, le fa risolvere, poi sviluppa, e infine verifica che il codice prodotto sia coerente con il modello atteso.

In un ERP in cui ogni ordine nasce obbligatoriamente da un preventivo, la richiesta «permettere un ordine senza preventivo» si scontra con una regola prima che venga modificato un solo file. La contraddizione è visibile nel momento in cui costa ancora solo una decisione.

Perché è importante

Il controllo smette di essere una correzione e diventa un inquadramento. L'agente parte da una comprensione esplicita del dominio invece che dalla propria interpretazione, e le decisioni di business vengono prese prima di essere codificate.

Per farlo l'agente non ha bisogno di caricare tutta l'ontologia: seleziona i concetti, le relazioni e le regole toccati dalla richiesta.

Sfumature e limiti

L'analogia con il TDD ha un limite netto: un'ontologia non è una suite di test, e un'analisi fatta da un LLM non offre la garanzia di un'asserzione deterministica. Ciò che si riprende è l'ordine delle operazioni, non la certezza del verdetto.

Una contraddizione segnalata a monte non è per forza un errore della richiesta: può annunciare un'evoluzione voluta del business.

Domande aperte

• Quante contraddizioni segnalate a monte dall'agente si rivelano, all'esame, falsi positivi?