Negli ultimi mesi lo sviluppo software con l’AI è passato dai primi esperimenti di curiosità a una pratica quotidiana per molti team. Strumenti come Copilot e gli altri LLM per sviluppatori ti permettono di generare codice partendo da prompt sempre più ricchi, ma quando il progetto cresce emergono limiti chiari del semplice vibecoding. È qui che entra in gioco lo Spec Driven Development (SDD), un paradigma che prova a mettere ordine nel modo in cui usi l’intelligenza artificiale per scrivere software.
Vediamo uno scenario tipico. Scrivi un prompt al tuo assistente AI:
“Implementa un form di registrazione React con validazione real‑time per email e password, gestione errori, invio POST a /api/register, stile moderno con Tailwind, gestione stato tramite Zustand e chiamate con Axios.”
In pochi secondi l’LLM genera un componente completo. Sembra ben strutturato, ha validazioni, feedback visivi, persino un piccolo toast di successo. Lo integri, testi l’happy path, tutto funziona. Commit e deploy. Poi la realtà bussa alla tua porta, e il team di quality segnala una infinità di anomalie.
Questo è un esempio di sviluppo software con AI basato esclusivamente su prompt “di pancia”, ossia vibecoding. Da qui emergono chiaramente i limiti concreti del vibe‑coding:
Insomma, il vibecoding ha avuto (e ha ancora) un ruolo importante: ha accelerato la prototipazione, ha abbassato la barriera d’ingresso e ha fatto scoprire a molti team il potenziale reale degli AI coding agent e dell’AI al servizio degli sviluppatori. Però non è più sufficiente quando si parla di software che deve operare in contesti enterprise.
Per andare oltre il semplice prompt engineering “a sensazione”, serve un cambiamento di paradigma. Bisogna cambiare prospettiva: dal codice guidato dall’intuizione e dall’apparenza, al codice guidato da specifiche esplicite, verificabili e condivise. È qui che si inserisce lo Spec Driven Development.
Spec Driven Development (SDD) significa trattare le specifiche come l’elemento centrale e più importante del progetto, la vera fonte di verità, invece del codice che viene generato. Non si parla però delle classiche specifiche in Word, PDF o Confluence che diventano obsolete subito dopo il rilascio.
Parliamo di specifiche eseguibili, nate per lo sviluppo software con l’AI, scritte in un linguaggio comprensibile sia dagli esseri umani che dalle macchine, che descrivono in modo preciso e non ambiguo lo scopo del sistema, gli scenari d’uso e i vincoli.
Se conosci il Test Driven Development (TDD) e/o il Behavior Driven Development (BDD), queste sono le analogie: pensa allo SDD come a un TDD portato al livello superiore e reso collaborativo con l’AI:
In altre parole, l’intento dello sviluppatore (il tuo intento) diventa la vera “spec” che governa l’LLM.
Per capire come questo approccio cambi il tuo modo di lavorare, è utile schematizzare il workflow tipico di uno sviluppatore che adotta Spec Driven Development. Possiamo tenere a mente le fasi descritte qui sotto.
Nella fase di specifica lo sviluppatore descrive in linguaggio naturale ma strutturato il comportamento atteso del sistema: il percorso dell’utente passo dopo passo, gli obiettivi di business, i casi d’uso principali insieme agli scenari limite rilevanti e tutte le regole di validazione o i vincoli non negoziabili.
Qui il tuo lavoro è soprattutto di analisi e di formalizzazione dell’intento, più che di scrittura di codice.
L’AI, a partire da questa narrazione, genera una specifica formale e dettagliata: schemi JSON per request e response, regole di validazione con esempi concreti, casi attesi e di fallimento in formato GivenWhenThen, invarianti di business e mock di eventuali servizi esterni.
Importante, non è un’attività “one-shot”, ovvero non c’è semplicemente una definizione iniziale da parte dello sviluppatore, seguita da una rifinizione e strutturazione da parte dell’AI. Piuttosto, si tratta di un processo iterativo in cui lo sviluppatore lavora assieme all’AI, definendo le specifiche, il cosa ed il perché del progetto.
Altrettanto importante, le specifiche devono essere mantenute nel tempo, affinché non diventino obsolete a seguito della fase di implementazione vera e propria e dell’evoluzione naturale di un progetto.
Nella fase di pianificazione lo sviluppatore definisce i vincoli tecnici non negoziabili: lo stack tecnologico, l’architettura preferita, le librerie da utilizzare per validazione, gestione dello stato, chiamate HTTP e testing, oltre a eventuali limiti di performance o bundle size.
L’AI elabora quindi un piano tecnico completo e realistico, indicando la struttura delle cartelle, i componenti principali con le rispettive responsabilità, il flusso dei dati, le librerie scelte e le motivazioni, la strategia di gestione degli errori e degli stati di caricamento, oltre ai mock necessari per i test.
Qui il prompting diventa vero e proprio prompt engineering: non chiedi più “fammi X”, ma guidi un agente AI con vincoli chiari e verificabili.
Nella fase di scomposizione in task l’AI prende il piano approvato e lo suddivide in attività atomiche, ordinate e indipendenti. Ogni task è progettato per essere piccolo, testabile in isolamento e associato a criteri di accettazione chiari, spesso collegati direttamente a uno o più esempi presenti nella specifica.
Questo passaggio rende il lavoro molto più vicino a un classico backlog agile, ma generato e mantenuto in coerenza con la spec.
Infine, c’è la fase di implementazione. L’AI genera il codice un task alla volta, sempre rispettando la specifica e il piano concordati. Lo sviluppatore legge e valida chunk di codice ridotti e mirati: verifica che il codice soddisfi i casi tipici e gli edge case previsti, esegue test locali o visualizza il risultato in anteprima, approva il risultato oppure richiede correzioni puntuali. Il ciclo è rapido, di solito 5-15 minuti per task.
In questo modo l’LLM per sviluppatori diventa un collaboratore sotto controllo, non un generatore di blocchi monolitici difficili da capire.
A questo punto hai un flusso completo: dalla specifica all’implementazione, con l’AI che segue regole chiare invece di improvvisare. Il passo successivo è scegliere gli strumenti giusti per supportare questo modo di lavorare.
Il panorama degli strumenti per lo Spec Driven Development si è evoluto rapidamente. Oggi esistono soluzioni che vanno da framework leggeri open source a piattaforme complete che integrano l’intero ciclo di sviluppo software con AI.
GitHub Spec Kit resta il punto di riferimento open source. È un toolkit modulare che permette di scrivere specifiche in markdown strutturato (con schema JSON, esempi GivenWhenThen e invarianti), di validarle automaticamente e di generare codice tramite prompt contestualizzati verso qualsiasi LLM.
La sua forza sta nella semplicità, nella trasparenza e nel fatto che non lega a un singolo provider: puoi usarlo con Claude, GPT, Gemini o modelli locali. È il punto di partenza ideale per team che vogliono sperimentare SDD senza lock-in.
OpenSpec è un framework open source per lo SDD di coding agents. Le particolarità di questo strumento è l’essere particolarmente adatto a contesti brownfield con codice legacy. Piuttosto che requirements di alto livello, la sua forza è la definizione di requirements operativi per singoli agents, partendo dal contesto della codebase esistente e “dandogli in pasto” una singola issue.
È facile da usare, basta un openspec init per integrarlo in una codebase e installa solo 3 comandi: proposal (propone un nuovo cambiamento), apply (lo implementa), archive (lo archivia e aggiorna le specifiche). Interessante è come vengano tenute separate le specifiche attuali (la “source of truth”) dalle proposte di modifiche, in due cartelle separate che vengono riconciliate quando archivi le modifiche.
In questo modo i diffs sono sempre gestibili e tracciati, un requisito importante in molti contesti. È anche molto leggero, usa solo file markdown, e supporta tutti i coding assistants principali che stai già usando (Claude Code, GitHub Copilot, OpenCode, Cursor, Windsurf...).
Naturalmente, ci sono anche numerosi altri framework di SDD, più di nicchia e con funzionalità particolari. Un esempio è Spec-Kitty, dedicato a chi cerca capacità di orchestrazione elevate (esecuzione parallela di Agenti multipli senza conflitti) unità ad elevata visibilità su cosa sta effettivamente succedendo e su cosa stanno lavorando gli aventi. La feature più evidente è una dashboard visuale che traccia automaticamente tutti i progressi, permettendo la rappresentazione in una kanban board delle lavorazioni pianificate, in corso da revisionare e completate, nonché vedere quali agenti stanno lavorando a quale task.
Nel video “So you think you know Copilot?” affrontiamo anche un approfondimento pratico che mostra l'interazione con l'agente AI, mettendo in evidenza come uno Spec Driven Development ben fatto cambi il modo di usare strumenti come GitHub Copilot.
Per chi cerca un’esperienza più integrata rispetto al classico Copilot, le alternative più interessanti sono Kiro e Tessl. Kiro punta su un workflow collaborativo con “costituzioni” (regole di stile e architettura imposte a livello di progetto) e checklist automatiche per ogni generazione. È particolarmente utile in team grandi dove serve uniformità.
Tessl, invece, rappresenta l’approccio più radicale: è il primo tool vero spec-as-source. La specifica è l’unico artefatto modificabile, il codice viene rigenerato da zero a ogni cambiamento, e la storia del progetto vive quasi interamente nella spec stessa. È la scelta per chi vuole spingere al massimo l’idea che il codice sia un output derivato e non la fonte di verità.
Se vuoi vedere come l’AI può supportare anche la parte di DevOps e delivery, puoi approfondire il tema in questo articolo su AI, DevOps e Platform Engineering.
Lo SDD non riduce lo sviluppatore a un semplice “revisore di codice generato dall’AI”. Al contrario, lo eleva a un ruolo strategico e di altissimo valore: da chi scriveva ogni riga a chi definisce, orchestra e garantisce la qualità dell’intero sistema.
Nel modello tradizionale lo sviluppatore era spesso esecutore di requisiti: traduceva in codice dettagli tecnici e logiche di business che arrivavano già parzialmente formalizzate. Con lo Spec Driven Development il focus si sposta decisamente verso l’alto:
In sostanza, si scrive molto meno codice boilerplate, ma si investe molto di più in pensiero critico, system design, comunicazione chiara dei requisiti e capacità di validazione profonda. Queste sono competenze rare, difficili da automatizzare e sempre più richieste dal mercato.
In SparkFabrik vediamo questo cambiamento come una grandissima opportunità. La nostra missione non è sostituire i team di sviluppo con l’intelligenza artificiale, ma aiutarti a far evolvere il tuo team verso ruoli di maggiore impatto e valore.
Lo Spec Driven Development porta in dote diversi vantaggi:
Naturalmente non tutti i contesti traggono lo stesso beneficio. Lo SDD esprime il massimo valore in tre scenari principali:
Per greenfield si intendono i progetti avviati da zero, in assenza di vincoli legacy, architetture preesistenti o debito tecnico accumulato. In questo contesto lo Spec-Driven Development esprime il massimo potenziale: le specifiche diventano il vero punto di origine del sistema e guidano l’intero processo fin dal primo commit.
L’architettura nasce già allineata ai requisiti funzionali e non funzionali, le decisioni tecniche sono tracciabili e motivate, e il rischio di divergenza tra visione progettuale e implementazione concreta si riduce drasticamente.
Le specifiche non sono solo documentazione iniziale, ma diventano una struttura portante che riduce le sorprese, previene incoerenze evolutive e limita la formazione di debito tecnico precoce, creando basi solide per la scalabilità futura del sistema.
Per brownfield si intendono invece i contesti in cui si interviene su sistemi esistenti: piattaforme legacy, architetture stratificate nel tempo, ecosistemi complessi già in produzione. In questi scenari lo Spec-Driven Development non serve a “costruire da zero”, ma a rendere esplicito ciò che spesso è solo implicito: vincoli architetturali, dipendenze, contratti di integrazione, comportamenti emergenti e limiti strutturali del sistema.
Le specifiche diventano uno strumento di formalizzazione del contesto reale, definendo con precisione punti di contatto, regole di compatibilità e confini funzionali. Questo consente all’AI di generare codice realmente contestualizzato, riducendo il rischio di regressioni, errori di integrazione e incoerenze sistemiche.
Il risultato è un aumento del throughput evolutivo, una maggiore sicurezza nei rilasci e una semplificazione concreta della manutenzione nel lungo periodo, anche in ecosistemi software altamente complessi.
In questo caso lo SDD rende la transizione graduale e controllata: si descrivono prima i comportamenti desiderati del nuovo codice, si affronta il reverse engineering in modo strutturato, si ridefiniscono o aggiornano le specifiche e si sostituiscono porzioni obsolete. Così si riducono regressioni, overhead manuale e rischi di rottura, pur richiedendo un investimento iniziale per contestualizzare il sistema esistente.
Come ogni paradigma emergente, lo Spec Driven Development porta benefici reali ma anche rischi concreti. Vediamo quali sono le trappole più frequenti.
Workflow elaborati con decine di file markdown, checklist e costituzioni possono creare un overhead maggiore del beneficio, trasformando un piccolo fix in un processo burocratico pesante. O peggio, il tentativo di miglioramento può invece finire per peggiorare la situazione iniziale (letteralmente “peggioramento-miglioramento”).
Le spec generate tendono a essere ridondanti, ripetitive e noiose da revisionare. Invece di chiarire, aumentano il carico cognitivo: più testo da leggere che codice da scrivere.
Occorre evitare di considerare lo SDD come scrittura esaustiva ma “vuota” di requisiti che nessuno legge, come creazione di burocrazia o come “waterfall planning”, ovvero un esercizio sterile di pianificazione estensiva nel tentativo di considerare tutte le eventualità e l’intero futuro di sviluppo.
Piuttosto, lo Spec-Driven Development riguarda il rendere le decisioni tecniche esplicite e revisionabili, nonché facilmente comprensibili (non solo da macchine, ma soprattutto da persone) ed agevolmente evolvibili.
Troppo vago, l’AI fraintende e genera codice sbagliato. Troppo rigido, il processo diventa inflessibile, impossibile da adattare a cambiamenti rapidi o contesti brownfield. Trovare il “giusto mezzo” richiede pratica e iterazioni.
Anche con spec dettagliate, checklist e large context, l’AI ignora spesso istruzioni, duplica codice esistente o esagera nell’applicare regole. Il nondeterminismo resta: la stessa spec può produrre output diversi a ogni rigenerazione.
Questo è il nodo centrale del nuovo paradigma della programmazione, non più deterministico, ma legato a strumenti AI di natura probabilistica. Questo shift di paradigma è esplorato in profondità nel talk di Enrico Zimuel durante il nostro evento GenAI x Business.
In codebase complesse o in sessioni di lavoro particolarmente lunghe, gli agenti possono perdere parte del contesto: relazioni implicite tra componenti, decisioni già prese o modifiche effettuate in precedenza. Senza un ancoraggio continuo alle specifiche, questo può portare a incoerenze, duplicazioni o regressioni non intenzionali.
Per fix banali l’overhead è sproporzionato, per feature molto complesse o ambigue spesso non basta, e introdurlo su codebase legacy richiede uno sforzo iniziale elevato. Inoltre, se la specifica non viene mantenuta aggiornata diventa una fonte di inganno più pericolosa del codice stesso, ripetendo errori storici del modeldriven development: rigidità unita a imprevedibilità.
Essere consapevole di questi limiti ti permette di applicare lo Spec Driven Development dove ha davvero senso, evitando di trasformarlo in un nuovo dogma.
Lo Spec Driven Development rappresenta una nuova frontiera dello sviluppo AI, una direzione in cui molti stanno sperimentando diversi approcci. In tale contesto, si inserisce un’evoluzione ancora più radicale: lo spec-as-source development.
Secondo questo approccio, la specifica diventa l’unico artefatto stabile e modificabile. Quando cambiano requisiti, stack tecnologico o modello LLM, aggiorni solo la spec → piano, task e codice si rigenerano di conseguenza, automaticamente. La storia del progetto vive nella spec stessa, compreso il “commit history”. Il codice perde centralità: diventa un output derivato, temporaneo e rigenerabile.
Strumenti come Tessl stanno già spingendo in questa direzione, sebbene siano in fase molto sperimentale (attualmente con il limite 1-a-1 di una specifica-un codice), mentre le Agent Skills (inizialmente di Claude e ora open source, donati alla Agentic AI Foundation) mostrano un trend parallelo: agent autonomi che eseguono task complessi sotto guardrail definiti dalle specifiche. Un esempio è Superpowers di Obra su GitHub per task di sviluppo, mentre Skills.sh raccoglie migliaia di Skills per gli ambiti più disparati, dal design frontend, al brainstorming, al copywriting.
Questo paradigma cambia profondamente il ruolo del developer. Una persona inesperta resta nel vibe-coding, affidandosi a prompt generici (ed ottenendo risultati generici). Un senior invece esplode di potenziale: fornisce specifiche precise, guardrail rigorosi e architettura solida, trasformando l’AI da generatore casuale a esecutore affidabile e instancabile.
Lo SDD in contesto AI è ancora giovane, con sfumature in evoluzione e best practice in fase di scoperta. La direzione però è chiara: non sarà più “ecco il mio prompt, eseguilo, io aspetto”, ma “ecco i task, le regole e la direzione, tu continua a lavorare”.
A tendere assisteremo ad un “cambio di workforce”, con le macchine e gli agent che opereranno 24/7, mentre gli umani supervisionano, definiscono intento, specifiche, architettura e altri aspetti a valore elevato. Scrivere codice diventerà meno centrale; scrivere specifiche chiare, verificabili e durature diventerà una skill core del developer moderno.