L’intelligenza artificiale non elimina l’ambiguità: la rende più veloce, più scalabile e più difficile da individuare.
Molte discussioni sull’AI nello sviluppo software si concentrano sulla qualità del codice generato — correttezza, sicurezza, performance e affidabilità — ma rischiano di trascurare un problema più profondo.
I modelli linguistici non comprendono il dominio come un essere umano: interpretano il linguaggio tramite correlazioni statistiche e completano le informazioni mancanti in base al contesto. Se quel contesto è ambiguo, incompleto o incoerente, l’ambiguità non scompare: si amplifica.
In questo articolo vedremo perché il vero rischio dei sistemi AI-driven non è la generazione automatica del codice, ma l’attribuzione del corretto significato ai concetti del dominio. Analizzeremo come la plausibilità possa essere più pericolosa dell’errore evidente e perché pratiche Ubiquitous Language e Bounded Context siano oggi ancora più importanti.
Per avere una visione più alta e generale della questione, vi rimando al mio precedente articolo “Domain-Driven Design e AI: il problema non è il codice ma il significato”.
Perché il problema dei sistemi AI-driven non è la generazione del codice, ma l’interpretazione del significato
Quando si parla di AI nello sviluppo software, gran parte della discussione ruota attorno alla qualità del codice generato. Ci chiediamo se un LLM produca implementazioni corrette, se introduca vulnerabilità, se utilizzi pattern appropriati o se sia sufficientemente affidabile per lavorare in produzione.
Sono domande legittime, ma rischiano di concentrare l’attenzione sul livello sbagliato del problema.
La vera criticità dei sistemi AI-driven non è la capacità di generare codice. È la capacità di interpretare correttamente la semantica del dominio. Immaginiamo un sistema e-commerce in cui il termine “ordine” viene utilizzato per molteplici scenari: indicare un acquisto completato, una prenotazione e una richiesta di preventivo. Un LLM può generare codice perfettamente funzionante, ma costruire regole e workflow attorno a significati differenti dello stesso concetto. Il risultato non sarà un errore tecnico, ma un errore di interpretazione del dominio.
Questa distinzione può sembrare sottile, ma cambia radicalmente il modo in cui dovremmo osservare l’evoluzione dello sviluppo software assistito dall’AI.
Un modello linguistico non “comprende” il dominio nel senso umano del termine. Non possiede esperienza del business, non costruisce una rappresentazione intenzionale del sistema e non distingue realmente tra ciò che è semanticamente corretto e ciò che è soltanto plausibile.
Un LLM completa sequenze linguistiche sulla base di correlazioni statistiche. Ed è proprio questo il punto più importante da comprendere.
Il problema non è l’errore sintattico
Ogni volta che un compilatore segnala un errore sintattico, il problema è generalmente evidente. Il codice non compila, un test fallisce oppure il comportamento è immediatamente incoerente.
I problemi semantici sono molto più insidiosi.
Un sistema semanticamente errato può apparire corretto sotto quasi ogni punto di vista tecnico. Il codice può essere pulito, ben organizzato, aderente ai pattern architetturali più diffusi e persino coperto da test automatici. Eppure, il modello concettuale sottostante potrebbe essere sbagliato.
Questo accade perché gran parte delle informazioni che utilizziamo nello sviluppo software non è realmente esplicita.
Molte decisioni dipendono dal contesto. Altre dal linguaggio condiviso dal team. Altre ancora da assunzioni implicite costruite nel tempo attraverso conversazioni, riunioni, esperienza del dominio e conoscenza aziendale.
Gli esseri umani riescono a gestire questa ambiguità grazie alla capacità di interpretare continuamente il contesto. I modelli linguistici, invece, tendono a riempire gli spazi mancanti utilizzando correlazioni probabilistiche.
Più il contesto è ambiguo, maggiore sarà lo spazio lasciato all’interpretazione statistica.
Il codice plausibile è il vero rischio
Uno degli aspetti più pericolosi dell’AI-generated code è la sua capacità di produrre implementazioni plausibili.
In passato, strumenti immaturi tendevano a produrre output evidentemente errati. Questo rendeva il problema relativamente semplice da individuare: il sistema falliva immediatamente oppure risultava chiaramente inutilizzabile.
Gli LLM moderni funzionano in modo diverso.
Il codice prodotto appare spesso corretto, leggibile e coerente con le convenzioni tecniche più diffuse. Proprio questa plausibilità aumenta enormemente il rischio di accettare come corrette interpretazioni semanticamente sbagliate.
Il focus si sposta dal riconoscere un errore evidente al distinguere un modello corretto da uno semplicemente plausibile.
Ed è qui che emerge uno degli aspetti più sottovalutati dell’AI-assisted development: l’AI non elimina gli spazi interpretativi presenti nel linguaggio umano. Li amplifica.
Ambiguità umana, velocità artificiale
Nel dibattito pubblico sull’AI esiste spesso la tendenza a considerare le allucinazioni come una sorta di “difetto” dei modelli linguistici.
Anche i team di sviluppo interpretano continuamente concetti incompleti, requisiti vaghi e definizioni parziali del dominio. La differenza è che gli esseri umani possiedono meccanismi continui di riallineamento semantico. Discussioni, feedback, confronti con il business e revisione reciproca permettono gradualmente di correggere interpretazioni errate.
L’AI accelera enormemente questo processo, ma non introduce automaticamente gli stessi meccanismi di riallineamento.
Di conseguenza, un’ambiguità che in passato avrebbe generato un piccolo misunderstanding locale può oggi produrre in pochi minuti interi flussi applicativi coerenti… ma costruiti attorno a un modello concettuale sbagliato.
Il rischio non cresce linearmente con la velocità della generazione. Cresce esponenzialmente.
Perché il linguaggio torna centrale
Per molti anni una parte significativa dell’ingegneria del software si è concentrata soprattutto sugli aspetti strutturali dei sistemi: modularità, performance, distribuzione, resilienza, scalabilità.
Sono tutti temi fondamentali, naturalmente. Ma l’AI-assisted development sta riportando al centro un problema molto più profondo: la precisione del linguaggio con cui descriviamo e condividiamo la conoscenza del dominio.
Quando un team utilizza termini ambigui, incoerenti o sovrapposti, anche il modello linguistico eredita la stessa ambiguità.
Se “ordine”, “spedizione”, “richiesta” e “prenotazione” vengono utilizzati come sinonimi in contesti differenti, l’AI tenderà inevitabilmente a mescolare responsabilità, regole e confini semantici.
Questo non accade perché il modello sia “stupido”. Accade perché il linguaggio che gli stiamo fornendo è semanticamente instabile.
Ed è proprio qui che molte pratiche del Domain-Driven Design assumono un significato completamente nuovo.
Ubiquitous Language non serve soltanto a migliorare la comunicazione tra sviluppatori e business. Diventa un meccanismo di riduzione dell’ambiguità semantica anche per i sistemi AI-driven.
Allo stesso modo, i Bounded Context smettono di essere soltanto strumenti architetturali e diventano veri e propri confini linguistici che limitano lo spazio interpretativo lasciato al modello.
L’AI non sostituisce la progettazione
Uno degli errori più comuni nel modo in cui interpretiamo l’AI-generated code è immaginare che la generazione automatica riduca la necessità di progettazione.
In realtà accade esattamente il contrario.
Più la produzione di codice diventa economica, più aumenta il valore della precisione semantica. Quando implementare una soluzione richiede pochi secondi, il vero problema non è più produrre software, ma garantire che il sistema rappresenti correttamente il dominio che dovrebbe modellare.
La progettazione software non scompare. Cambia focus.
Sempre meno attenzione sarà dedicata alla scrittura manuale delle implementazioni e sempre più energia verrà spesa nella definizione del linguaggio, dei vincoli, dei confini semantici e dei meccanismi di validazione architetturale.
In questo senso, l’AI non sta riducendo l’importanza dell’architettura software, bensì sta rendendo evidente un problema che era sempre esistito, ma che fino a oggi era rimasto nascosto dietro il costo della produzione manuale del codice.