Una nuova frontiera per lo sviluppo software

I Large Language Model possono scrivere codice, generare suggerimenti architetturali e persino proporre modelli di dominio. La loro fluidità linguistica spesso dà l’impressione che comprendano davvero il sistema che stanno aiutando a progettare.

Ma questa fluidità nasconde un limite fondamentale: il modello non comprende il nostro dominio, ma semplicemente reagisce in modo coerente a quanto gli forniamo attraverso il linguaggio naturale.

Per questo motivo, la disciplina più importante quando si collabora con un LLM non riguarda prompt sofisticati o tecniche particolari. È la stessa disciplina che sta al centro del Domain-Driven Design: l’Ubiquitous Language.

Quando si usa un LLM per generare codice, progettare API, definire eventi o proporre strutture architetturali, la qualità del risultato dipende quasi interamente dalla precisione e dalla coerenza del linguaggio che si utilizza. In pratica, l’Ubiquitous Language diventa il sistema di controllo dello sviluppo assistito dall’AI.

Perché il linguaggio conta ancora di più con gli LLM

In un team di sviluppo tradizionale, un linguaggio ambiguo è scomodo ma gestibile: gli sviluppatori fanno domande di chiarimento, gli architetti revisionano le decisioni, gli esperti di dominio correggono eventuali incomprensioni.

Detto in maniera sintetica: gli esseri umani risolvono naturalmente l’ambiguità, i modelli LLM dell’Intelligenza artificiale no!

Quando il linguaggio è vago o incoerente, il modello non può chiedere chiarimenti; al contrario, riempie i vuoti generando ciò che appare statisticamente plausibile. Il risultato può sembrare corretto, ma potrebbe non riflettere le vere regole del tuo dominio.

Ambiguità e discrepanze strutturali

Questo significa che l’ambiguità ha una conseguenza diversa quando si collabora con un LLM: espande lo spazio delle possibili interpretazioni. Consideriamo una richiesta molto semplice:

Crea gli eventi del sistema

Con un collega umano probabilmente riceveremmo subito alcune domande.

Quale sistema? Quale parte? Quali convenzioni di naming? Quali confini?

Un LLM non farà queste domande. Genererà qualcosa che sembra ragionevole.

Ora confrontiamolo con una richiesta espressa attraverso un linguaggio di dominio disciplinato:

Definisci i domain event per il bounded context Order nella piattaforma BrewUp. Usa nomi al passato e non introdurre nuovi aggregate.

La differenza non è stilistica: è strutturale. Nel secondo caso, il modello ha un vocabolario chiaro e confini espliciti. Le possibili interpretazioni si riducono drasticamente e l’output generato diventa molto più allineato con il dominio previsto. In altre parole: la precisione del linguaggio riduce l’ambiguità nei risultati generati.

Ubiquitous Language come sistema di confini

Nel Domain-Driven Design, l’Ubiquitous Language assicura che ogni concetto importante abbia un significato condiviso all’interno del team. Termini come Order, Payment o Inventory Reservation non sono parole generiche. Sono concetti di dominio precisi che esistono all’interno di confini ben definiti.

Quando si collabora con un LLM, questi confini diventano ancora più importanti. Se nei prompt si alternano più termini per indicare lo stesso concetto, il modello li interpreta come segnali diversi. Potrebbe considerarli concetti distinti e iniziare a generare strutture che non erano mai state previste. È quello che succederebbe se, ad esempio, usassimo per lo stesso concetto tre parole diverse di significato simile:

Order
Purchase
Request

Cosa succederebbe? Si inzia con il chiedere di definire gli eventi per un Order, e poi ci si ritrova con eventi come PurchaseCreated o RequestSubmitted semplicemente perché questi termini compaiono spesso in contesti simili.

Sono modelli linguistici

Il modello non sta prendendo una decisione concettuale, sta seguendo pattern linguistici e, per questo motivo, un Ubiquitous Language disciplinato diventa essenziale.

Se il concetto di dominio è Order, allora tutto dovrebbe riferirsi coerentemente a Order:

OrderCreated

OrderPaid

OrderCancelled

La coerenza stabilizza il processo di generazione e previene la deriva concettuale.

Scrivere codice con un LLM richiede disciplina linguistica

Quando chiediamo a un LLM di scrivere codice, la precisione del linguaggio diventa ancora più critica. La scrittura di codice da parte di un modello AI dipende fortemente da come vengono descritti i concetti. Se il vocabolario del dominio è poco chiaro, anche le strutture generate saranno poco chiare. Ad esempio, una richiesta vaga potrebbe essere:

Genera un servizio che gestisce gli acquisti.

Il modello deve indovinare cosa significhi “acquisto”. È la creazione di un ordine? Il processo di pagamento? Il checkout?

Ora consideriamo la stessa richiesta espressa con un linguaggio di dominio chiaro:

Genera un servizio che gestisce il posizionamento degli Order

nel bounded context Ordering. L’aggregate Order emette un evento OrderPlaced

quando il pagamento viene confermato.

Qui il vocabolario definisce il sistema:

• Order è il concetto centrale;
• OrderPlaced è l’evento;
• Ordering è il confine del contesto.

Poiché il linguaggio è strutturato, il codice generato tenderà a riflettere quella struttura. Ricordiamoci sempre che il modello non “capisce” il dominio ma è invece in grado di seguire i segnali presenti nel linguaggio. Quando questi segnali sono precisi e riflettono il dominio, il codice risultante si allinea con il modello di dominio.

Ubiquitous Language come sistema di vincoli

Un altro modo di vedere questa dinamica è considerare l’Ubiquitous Language come un sistema di vincoli. Quando il linguaggio di un prompt è vago, il modello ha molte possibili direzioni per completare la richiesta. Quando il linguaggio è preciso, l’insieme delle possibili risposte diventa più piccolo e prevedibile. Questo è particolarmente utile quando si generano:

• domain event
• aggregate
• command
• API
• confini di servizi

Vediamo due esempi diversi di prompt

Prompt non vincolato

In questo prompt, i vincoli non sono specificati, la richiesta è vaga e la risposta non sarà indirizzata precisamente per corrispondere al nostro modello di dominio.

Crea i command del sistema

Prompt vincolato

Invece, nel prompt seguente, vengono ben esplicitati i vincoli attraverso l’Ubiquitous Language.

Crea i command per l’aggregate Order nel bounded context Ordering.

I command devono rappresentare intenzioni dell’utente

e non devono bypassare gli invarianti dell’aggregate.

Questa seconda richiesta incorpora direttamente la conoscenza del dominio nel linguaggio. L’output del modello tende quindi ad allinearsi a quella conoscenza, perché il vocabolario limita ciò che è plausibile. L’LLM diventa più utile non perché sia più intelligente, ma perché il linguaggio guida il risultato.

Quando il modello deraglia, controlla il linguaggio

Quando un LLM produce un risultato errato, la reazione più comune è pensare che il modello abbia sbagliato, ma spesso il vero problema è linguistico. Se l’output introduce concetti o confini inattesi, spesso significa che il linguaggio del dominio era sottospecificato.

Invece di chiedersi perché il modello abbia sbagliato, è spesso più utile interrogarsi su quali parti del linguaggio di dominio fossero poco chiare.

Individuare il linguaggio impreciso

Tra le cause più comuni di linguaggio sottospecificato ci sono

• confini tra bounded context non definiti chiaramente;
• naming inconsistente degli aggregati;
• regole di dominio implicite ma mai esplicitate;
• mescolanza tra termini tecnici e termini di business.

Quando esistono questi “vuoti”, il modello li riempie usando pattern appresi altrove. In questo senso, gli LLM funzionano anche come uno specchio della chiarezza del nostro modello di dominio. Se il linguaggio è preciso, l’output tende a rimanere coerente; se il linguaggio è confuso, l’output rivela quella confusione.

Il ruolo dell’architetto dei sistemi non scompare

Usare un LLM per generare codice o esplorare soluzioni architetturali non elimina la necessità della responsabilità architetturale. Il modello può aiutare a

• strutturare idee;
• esplorare alternative;
• generare codice o artefatti di dominio.

Ma il Large Language Model non può verificare se quei risultati riflettono davvero le regole del business: solo architetti ed esperti di dominio possono farlo. La responsabilità dell’architetto quindi si sposta leggermente. Invece di produrre manualmente ogni artefatto, l’architetto diventa responsabile di progettare i vincoli linguistici che guidano il processo di generazione. Il lavoro passa dallo scrivere tutto a mano all’ingegnerizzare il linguaggio che guida la collaborazione.

Una riflessione conclusiva

Quando si lavora con gli LLM, il rapporto tra linguaggio e modellazione diventa più diretto che mai. I modelli di dominio sono espressi attraverso il linguaggio ma anche il comportamento degli LLM è guidato dal linguaggio: questo crea un allineamento molto potente, ma introduce anche un rischio.

Se trattiamo il modello come un esperto di dominio, rischiamo di delegare l’autorità concettuale a un sistema che invece non possiede una vera comprensione. Se invece lo trattiamo come un collaboratore guidato dal linguaggio e vincolato dall’Ubiquitous Language, i LLM diventa un assistente estremamente potente per l’esplorazione e la generazione di codice.

La stessa disciplina che il Domain-Driven Design ha introdotto per la collaborazione tra esseri umani diventa altrettanto importante nella collaborazione tra umani e AI. Il principio fondamentale resta semplice: un linguaggio preciso produce sistemi precisi. E quando un LLM entra nel processo di sviluppo, l’Ubiquitous Language diventa il volante che mantiene il sistema allineato con il dominio.