Martin Fowler ha pubblicato un articolo esteso che propone una tesi controcorrente: gli agenti AI sono più robusti quando operano all’interno di un Domain-Specific Language (DSL) piuttosto che quando gli chiedi di fare qualsiasi cosa in linguaggio naturale. Un dominio ristretto non è una limitazione, è una guida: l’agente commette meno errori perché il vocabolario possibile è più piccolo e più preciso.

L’articolo parte dall’impossibilità di una specifica completa a priori e arriva a un’osservazione pratica: chi utilizza Claude Code o Codex su codebase ben strutturate ottiene risultati più affidabili di chi chiede loro di costruire da zero senza vincoli. L’articolo documenta due esempi concreti: un sistema per generare presentazioni PowerPoint ricche di diagrammi e Tickloom, un DSL per illustrare il comportamento di sistemi distribuiti. In entrambi i casi, il modello impara il linguaggio del dominio e lo utilizza come interfaccia naturale, producendo output più verificabili.

Perché è rilevante per te: se stai progettando un agente per un compito ricorrente nel tuo settore, vincolare il linguaggio invece di lasciarlo libero può fare la differenza fra uno strumento affidabile e un generatore di sorprese. L’idea attraversa anche la lezione sul primo agente utile: gli obiettivi e i limiti dichiarati non sono burocrazia, sono il DSL implicito del tuo agente.

Nel dettaglio

Il contesto che mancava.

Gli agenti AI sono nati con l’idea di lavorare su linguaggio naturale aperto: chiedi quello che vuoi, e il modello decide i passi. Fowler capovolge la prospettiva: il linguaggio naturale è troppo ampio per un dominio specifico. Quando progetti un agente per un compito ricorrente—generare diagrammi architetturali, testare scenari distribuiti, produrre report strutturati—hai un vocabolario limitato di operazioni ed entità. Rendere esplicito quel vocabolario in un DSL (anche molto semplice) fornisce all’agente un’interfaccia più precisa e verificabile.

L’articolo sviluppa l’argomento attraverso due casi:

1. Presentazioni PowerPoint ricche di diagrammi. Un modello semantico delle diapositive (titolo, punti elenco, diagramma, note) diventa il DSL. L’utente descrive in linguaggio naturale ciò che vuole comunicare, l’LLM genera il DSL, un secondo passaggio lo trasforma in PowerPoint. Il punto cruciale: separare la generazione semantica (controllabile) dalla resa finale (meccanica).

2. Tickloom: un DSL per sistemi distribuiti. Fowler e il suo team hanno costruito un linguaggio minimo per descrivere interazioni fra nodi in un sistema distribuito (messaggi, fallimenti, retry). L’LLM legge descrizioni testuali di scenari e genera Tickloom, che poi produce il diagramma. Il DSL funge da contratto: se l’output non compila, l’errore è immediatamente identificabile.

La tesi centrale è che il DSL diventa la fonte di verità: l’output verificabile non è il testo generato dall’LLM, ma il codice DSL che l’LLM ha prodotto. Un DSL ben progettato è più facile da parsare, testare e correggere rispetto a una risposta in prosa.

Convergenza con Claude Code e Codex.

L’idea risuona con l’esperienza di chi utilizza agenti di coding in produzione. Claude Code e Codex funzionano meglio su codebase con astrazioni chiare e convenzioni consistenti—di fatto, un DSL implicito. Quando la struttura è debole, l’agente genera codice che compila ma non si integra, oppure fa assunzioni sbagliate sui confini.

Fowler cita Domain-Driven Design e Ubiquitous Language: costruire un modello concettuale condiviso è sempre stato il modo per sviluppare software complesso. L’LLM accelera il processo, ma non lo sostituisce: l’LLM aiuta a scoprire il vocabolario giusto, poi lo utilizza.

I limiti e cosa resta aperto.

L’articolo non affronta due problemi pratici:

• Chi scrive il DSL? Fowler descrive il processo iterativo (l’LLM come partner di brainstorming), ma non specifica quanto tempo serve per arrivare a un DSL stabile. Se il dominio cambia frequentemente, il DSL diventa un secondo codebase da mantenere.
• Quando il DSL non è sufficiente. Ci sono compiti dove il vocabolario è veramente aperto (scrittura creativa, esplorazione di idee). Fowler non discute quando il linguaggio naturale è la scelta corretta.

La discussione su Hacker News (121 punti, 80 commenti) conferma che l’idea trova riscontro in chi sviluppa agenti: molti riferiscono che vincolare il dominio riduce gli errori e semplifica il debugging. Altri sollevano il dubbio opposto: costruire un DSL ha senso solo se il compito è veramente ricorrente, altrimenti il costo di design supera il beneficio.

Implicazioni per chi progetta agenti.

Se stai costruendo un agente che risolve lo stesso tipo di problema molte volte, considera di definire esplicitamente il vocabolario delle operazioni e delle entità invece di lasciarlo emergere dal prompt. Non è necessario un linguaggio formale: anche uno schema JSON o una lista di comandi riconosciuti è un DSL.

Il metodo si collega a due strumenti del sito:

• La lezione sul primo agente utile insiste su obiettivo e limiti dichiarati: quel contratto implicito è già un DSL minimo.
• Il playbook per scrivere specifiche eseguibili propone di definire criteri di accettazione prima di generare: anche lì, stai vincolando il dominio per ottenere output verificabili.

Fowler conclude con un’osservazione valida per tutto il lavoro con gli agenti: il DSL è il luogo dove design e generazione si incontrano. L’LLM accelera, ma il design—decidere cosa conta e cosa no—rimane tua responsabilità.