Hai provato a far scrivere codice a un assistente AI e il risultato sembrava giusto, finché non l'hai messo alla prova? È l'esperienza più comune di chi lavora con gli agenti di sviluppo. La spec driven development (sviluppo guidato dalle specifiche) nasce proprio per questo: prima si scrive con cura cosa il software deve fare, poi si lascia lavorare l'agente, e si controlla il risultato rispetto a quel documento.
In questo articolo vediamo cos'è lo spec-driven development, come funziona nella pratica, quando ha senso adottarlo in un progetto aziendale e quali limiti conviene conoscere prima di partire.
Cos'è lo spec-driven development
Lo spec-driven development (SDD) è un modo di sviluppare software con gli agenti AI in cui la specifica diventa il punto di riferimento del lavoro. Non è un semplice documento di requisiti scritto all'inizio e poi dimenticato: è un testo strutturato che descrive obiettivi, comportamenti attesi, vincoli tecnici e criteri di accettazione, e che l'agente usa per generare, testare e verificare il codice.
GitHub, presentando nel settembre 2025 il suo toolkit open source Spec Kit, ha riassunto il cambio di prospettiva così: si passa da un mondo in cui «il codice è la fonte di verità» a uno in cui «l'intento è la fonte di verità». In altre parole, il valore sta nel descrivere bene cosa serve, non nel digitare più in fretta.
Perché è nato: i limiti del "vibe coding"
Il cosiddetto vibe coding è il modo più immediato di usare un agente: gli descrivi a parole cosa vuoi e accetti quello che produce. Per un prototipo da buttare funziona. Per un'applicazione che deve reggere processi aziendali, molto meno.
GitHub stesso descrive i problemi tipici: codice che sembra plausibile ma non compila, che risolve solo una parte del problema o che usa lo stack e l'architettura sbagliati. Secondo GitHub il punto non è la capacità dell'agente di scrivere codice, ma il modo in cui lo si guida.
Come funziona: le quattro fasi
Gli strumenti di SDD oggi più citati, come Spec Kit di GitHub e Kiro di AWS, seguono uno schema simile. Prendiamo come riferimento quello di Spec Kit:
- Specificare. Descrivi cosa vuoi costruire e perché. L'agente produce una specifica dettagliata con percorsi utente e criteri di successo.
- Pianificare. Indichi stack, architettura e vincoli (integrazioni, sicurezza, sistemi esistenti). L'agente ricava un piano tecnico.
- Scomporre in attività. Specifica e piano diventano una lista di compiti piccoli, ognuno implementabile e verificabile da solo.
- Implementare. L'agente esegue le attività una alla volta e chi sviluppa rivede modifiche circoscritte, invece di un unico blocco di codice difficile da controllare.
Il vantaggio non è solo tecnico. Una specifica scritta in linguaggio chiaro è leggibile anche da chi non programma: il titolare, il responsabile operativo, chi conosce davvero il processo. Diventa un punto di incontro tra business e sviluppo, come lo erano i buoni documenti di analisi nel ciclo di vita del software tradizionale.
Tre livelli di adozione
Birgitta Böckeler di Thoughtworks, in un'analisi pubblicata su martinfowler.com, distingue tre modi di intendere lo spec-driven development:
- Spec-first: la specifica si scrive prima di sviluppare e guida quella singola attività.
- Spec-anchored: la specifica resta anche dopo e si aggiorna quando la funzionalità evolve o va mantenuta.
- Spec-as-source: la specifica è l'unico artefatto che le persone modificano; il codice viene sempre rigenerato.
Per un'azienda la distinzione conta. Il primo livello migliora la qualità del singolo sviluppo. Il secondo è quello che fa la differenza nel tempo, perché la specifica diventa documentazione viva: quando tra un anno qualcuno dovrà modificare l'applicazione, troverà scritto cosa fa e perché. Il terzo è ancora in larga parte sperimentale.
Quando ha senso per una PMI o una startup
Lo spec-driven development non è utile solo alle grandi software house. Anzi, dà il meglio proprio dove c'è poco tempo per rimediare agli errori. Alcuni casi in cui conviene:
- Software su misura che tocca processi critici, come gestione ordini, rapportini, magazzino o fatturazione, dove un comportamento sbagliato ha costi reali.
- Evoluzione di una piattaforma esistente, dove l'agente deve rispettare architettura e convenzioni già presenti e non reinventarle.
- Integrazioni tra gestionali, in cui regole, formati e casi limite vanno scritti in modo esplicito.
- MVP di un nuovo servizio, se l'obiettivo è arrivare in fretta a qualcosa che si possa poi far crescere senza riscriverlo da capo.
Ha meno senso per correzioni minime o esperimenti di poche ore: lì il costo di scrivere e rivedere una specifica completa supera il beneficio.
Vuoi capire se l'SDD fa al caso del tuo progetto? Partiamo da un obiettivo concreto e ti mostriamo come lo trasformeremmo in specifica, piano e primo risultato da provare. Parliamone
Limiti ed errori comuni
L'SDD è una pratica giovane e gli strumenti cambiano in fretta. Nella stessa analisi, Böckeler segnala alcuni rischi che vale la pena conoscere.
Specifiche sproporzionate al problema
Un flusso rigido applicato a ogni modifica produce troppa carta. Nei suoi test, un piccolo bug è stato trasformato da uno strumento in quattro user story con sedici criteri di accettazione. La regola pratica: la profondità della specifica deve essere proporzionata al rischio della modifica.
Troppi documenti da rivedere
Se l'agente genera molti file ripetitivi, la revisione diventa faticosa e si finisce per approvarli senza leggerli. Una specifica utile è breve, precisa e scritta per essere letta da una persona.
Falso senso di controllo
Avere una specifica non garantisce che l'agente la rispetti. Gli agenti possono ignorare istruzioni o duplicare codice già esistente. Per questo servono comunque test automatici, revisione del codice e passi piccoli e verificabili.
Confondere specifica funzionale e tecnica
Mescolare "cosa deve fare" e "come va costruito" nello stesso documento rende difficile coinvolgere chi conosce il processo ma non il codice. Tenere separati i due livelli aiuta tutti.
Spec-driven development e metodologie agili
Una domanda frequente è se l'SDD sia un ritorno al modello a cascata. Non deve esserlo. Il rischio esiste se si pretende di specificare tutto all'inizio, ma la pratica migliore è iterativa: si specifica una porzione di valore, la si implementa, si verifica con chi la userà e si aggiorna la specifica. Se vuoi approfondire le differenze tra i due approcci, trovi un confronto in Metodologia Waterfall o Agile?.
Come lo affrontiamo in Mine Consulting
Usiamo lo spec-driven development nel nostro ciclo di sviluppo con agenti AI, adattandolo alla dimensione di ogni progetto. Il metodo è quello che applichiamo sempre, descritto in come lavoriamo:
- Obiettivo condiviso. Prima di scrivere codice mettiamo per iscritto, insieme a chi conosce il processo, cosa deve cambiare e come capiremo che funziona. Questa è la base della specifica.
- Primo risultato da provare. Scegliamo una porzione piccola ma utile, la specifichiamo, la sviluppiamo con gli agenti e la mettiamo nelle mani di chi la userà. Codice e specifica vengono rivisti da persone del team.
- Un percorso che continua. Le specifiche restano nel progetto e si aggiornano a ogni evoluzione, così l'applicazione resta comprensibile e modificabile anche a distanza di tempo.
Gli agenti accelerano il lavoro ripetitivo; le decisioni su cosa costruire, i compromessi tecnici e la responsabilità della qualità restano al team.
In sintesi
- Lo spec-driven development mette la specifica al centro dello sviluppo con agenti AI: prima si descrive cosa serve, poi si genera e si verifica il codice.
- Le fasi tipiche sono specificare, pianificare, scomporre in attività e implementare, con revisione a ogni passo.
- È utile soprattutto per software su misura, integrazioni ed evoluzioni di sistemi esistenti; meno per piccoli interventi.
- Non sostituisce test, revisione e iterazione: va dosato in base al rischio di ogni modifica.
Se stai valutando di sviluppare un nuovo strumento o di far evolvere quello che hai, possiamo ragionare insieme su come impostarlo. Parliamone.