I Large Language Models sono ormai ampiamente utilizzati nello sviluppo software. Generano codice, test, documentazione e persino bozze architetturali. Il problema, però, non è la loro capacità. È la loro mancanza di contesto durabile.
Anche quando vengono guidati da prompt ben scritti, gli LLM producono output spesso inconsistenti, imprevedibili e, soprattutto, subdolamente disallineati dall’intento del dominio. Non perché “sbagliano”, ma perché fanno esattamente ciò per cui sono progettati: generare testo plausibile, non ragionare sul dominio.
Il vero problema: contesto effimero e interpretazione
Prompt, istruzioni e conversazioni sono per loro natura temporanee. Ogni nuova iterazione rischia di perdere decisioni precedenti, compromessi architetturali, vincoli di business. In assenza di memoria, il modello è costretto a interpretare. E dove c’è interpretazione, c’è ambiguità.
Nei sistemi complessi, l’ambiguità è pericolosa.
Specification-Driven Development come memory bank
Specification-Driven Development (SDD) nasce per affrontare questo problema. Le specifiche non sono semplici input per la generazione di codice, ma diventano una memoria persistente: una costituzione di principi non negoziabili che definisce come un agente AI può ragionare, decidere e agire all’interno di un dominio.
Le specifiche:
- catturano decisioni di dominio,
- rendono espliciti vincoli e invarianti,
- fissano un linguaggio condiviso,
- riducono drasticamente lo spazio di interpretazione.
In SDD non si chiede all’AI di “fare la cosa giusta”.
Si definisce esplicitamente cosa significa giusto in quel contesto.
Perché SDD parla la lingua del Domain-Driven Design
SDD non è un’alternativa al Domain-Driven Design. È una sua estensione naturale nell’era dell’AI.
- Rafforza l’Ubiquitous Language
- Rende operativi i Bounded Context
- Preserva l’autorità degli esperti di dominio
- Trasforma le decisioni in regole leggibili da umani e macchine
Il codice smette di essere la fonte primaria di verità. Diventa una conseguenza di un modello esplicito.
Tool che rendono praticabile Specification-Driven Development
Negli ultimi mesi sono emersi strumenti che rendono SDD concretamente applicabile.
Spec Kit, Kiro, Tessl e BMAD condividono un presupposto comune: l’AI non deve lavorare su prompt isolati, ma su specifiche persistenti, versionabili e condivise.
- Spec Kit enfatizza specifiche in linguaggio naturale strutturato come fonte di verità.
- Kiro tratta le specifiche come un contratto operativo tra umani e agenti.
- Tessl riduce l’ambiguità attraverso intent dichiarativi e vincoli espliciti.
- BMAD allinea business model, dominio e generazione automatizzata.
Questi strumenti non sostituiscono il DDD: lo rendono eseguibile anche per l’AI.
Esempi concreti
Dal prompt alla specifica come memoria
Prompt:
“Generate the code to place an order and handle discounts.”
Specifica SDD:
An Order belongs to exactly one Customer.
Discounts are applied only if the Customer is eligible at checkout time.
Discount rules are owned by the Sales bounded context.
👉 Il miglioramento non viene dal modello, ma dall’assenza di interpretazione.
Linguaggio ubiquo eseguibile
A Subscription is Active only if payment is confirmed and the trial period has ended.
A Subscription cannot be suspended retroactively.
La specifica diventa l’ancora semantica del contesto.
Governare l’AI, non collaborare sul significato
In SDD:
- l’AI non propone alternative di dominio,
- non negozia il significato,
- esegue ciò che è consentito dalla costituzione del dominio.
Confronto concettuale dei tool
| Aspetto | Spec Kit | Kiro | Tessl | BMAD |
|---|---|---|---|---|
| Ruolo delle specifiche | Fonte di verità | Contratto | Intent dichiarativo | Allineamento business |
| Relazione con l’AI | Agente vincolato | Governato | Limitato | Allineato |
| Affinità DDD | Linguaggio ubiquo | Bounded Context | Invarianti | Strategic Design |
Conclusione: specificare è un atto di design
Specification-Driven Development non riguarda l’AI.
Riguarda controllo, chiarezza e responsabilità del design.
In un mondo in cui il software può essere generato, la competenza chiave diventa definire ciò che non è negoziabile.