Martin Fowler ha pubblicato un pezzo lungo che propone una tesi controcorrente: gli agenti AI reggono meglio quando operano dentro un Domain-Specific Language (DSL) che quando gli chiedi qualsiasi cosa in linguaggio naturale. Il dominio ristretto non è un limite, è una guida: l’agente commette meno errori perché il vocabolario possibile è più piccolo e più preciso.

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

Perché ti riguarda: se stai progettando un agente per un compito ripetuto nel tuo campo, vincolare il linguaggio invece di lasciarlo libero può essere la differenza fra un tool affidabile e un generatore di sorprese. L’idea attraversa anche la lezione sul primo agente utile: l’obiettivo e i limiti dichiarati prima 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 inverte la prospettiva: il natural language è troppo ampio per un dominio specifico. Quando progetti un agente per un compito ripetuto—generare diagrammi architetturali, testare scenari distribuiti, produrre report strutturati—hai un vocabolario limitato di operazioni e entità. Esplicitare quel vocabolario in un DSL (anche molto semplice) dà 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 slide (titolo, bullet, diagramma, note) diventa il DSL. L’utente descrive in linguaggio naturale cosa vuole comunicare, l’LLM genera il DSL, un secondo passo lo trasforma in PowerPoint. Il punto: 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 fa da contratto: se l’output non compila, l’errore è immediatamente riconoscibile.

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 fatto è più facile da parsare, testare e correggere di una risposta in prosa.

Convergenza con Claude Code e Codex.

L’idea risuona con l’esperienza di chi usa 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, o fa assunzioni sbagliate sui confini.

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

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 dice quanto tempo serve per arrivare a un DSL stabile. Se il dominio cambia spesso, il DSL diventa un secondo codebase da mantenere.
• Quando il DSL non basta. Ci sono compiti dove il vocabolario è davvero aperto (scrittura creativa, esplorazione di idee). Fowler non discute quando il natural language è la scelta giusta.

La discussione su Hacker News (121 punti, 80 commenti) conferma che l’idea trova riscontro in chi sviluppa agenti: molti riportano 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 è davvero ripetuto, 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 serve un linguaggio formale: anche uno schema JSON o una lista di comandi riconosciuti è un DSL.

Il metodo si lega 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 chiude con un’osservazione che vale 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—resta responsabilità tua.