Angolo

Un modello di dominio scritto protegge il codice prodotto da agenti solo se tiene la sua posizione tra due derive: congelato, blocca ogni evoluzione del prodotto; allineato al codice, ratifica ogni errore. Ciò che gli permette di reggere è un terzo termine, l'intenzione della richiesta, che distingue l'evoluzione voluta dalla deriva, e un ciclo che funziona nei due sensi: il codice fa evolvere il modello quando l'intenzione lo giustifica, il modello inquadra il codice prima che venga scritto.

Sintesi

I test e la compilazione controllano il comportamento che l'agente ha appena scritto, non il modello che avrebbe dovuto rispettare. Il modello di dominio colma questa mancanza, ma è utile solo se interviene in più momenti: prima del codice, come il TDD, per inquadrare la richiesta; durante e dopo, per qualificare i cambiamenti del repository; prima dell'integrazione, per produrre un report di coerenza.

Il ciclo regge solo grazie a una ripartizione rigorosa. Ciò che può essere esatto — l'inventario dei cambiamenti, gli invarianti trasformati in test — è affidato a script e asserzioni. Ciò che richiede un giudizio — un cambiamento di classe è un cambiamento di concetto? uno scostamento è voluto? — è affidato all'LLM, con l'intenzione come arbitro e la prova come requisito. E ogni evoluzione del modello è trattata esplicitamente, versionata e collegata alla sua decisione, perché il modello resti un riferimento e non uno specchio.

Il risultato si riassume in una ripartizione dei ruoli: il codice fa fede sul comportamento implementato, l'ontologia sul significato di business, l'intenzione sulla ragione per cui quel significato può cambiare.

Tensioni / contraddizioni

Con la tesi secondo cui il codice è la fonte di verità: qui il codice non deve avere automaticamente ragione. La tensione si risolve con una ripartizione — il codice fa fede sul comportamento, non sul significato — ma resta reale quando l'intenzione è andata persa.

Non è ancora misurato nulla. Il volume di falsi positivi del giudizio semantico, il costo di esecuzione e il costo in attenzione umana della convalida delle evoluzioni restano da mettere alla prova su vere evoluzioni del software.

Domande

• Il guadagno in coerenza giustifica il costo di esecuzione e di manutenzione del ciclo, e su quali tipi di software?
• Come evitare che l'ontologia si carichi di dettagli tecnici man mano che il ciclo la alimenta a partire dal codice?