Il modo in cui sviluppiamo software sta cambiando. Non gradualmente. Radicalmente.

Chi scrive codice riga per riga sta già perdendo terreno. Chi orchestra agenti AI con spec ben scritte consegna in settimane quello che prima richiedeva mesi.

Questo articolo spiega cos'è lo spec-driven development, come funziona nella pratica, e perché è destinato a diventare lo standard.

Cos'è lo spec-driven development

Lo spec-driven development è un metodo di sviluppo software in cui il codice viene generato a partire da specifiche scritte in linguaggio naturale.

Il flusso tradizionale funziona così:

Qualcuno descrive cosa serve (a voce, in un ticket, in una chat)
Lo sviluppatore interpreta la richiesta
Lo sviluppatore scrive il codice
Si testa, si corregge, si itera

Il flusso spec-driven funziona così:

Scrivi una spec che descrive esattamente cosa deve fare il software
Un agente AI legge la spec e genera il codice
Tu controlli il risultato e approvi (o chiedi modifiche)

La differenza fondamentale: nel metodo tradizionale, il codice è la fonte di verità. Nel metodo spec-driven, la spec è la fonte di verità.

Questo significa che per capire cosa fa un sistema, non devi leggere migliaia di righe di codice. Leggi la spec.

Per modificare un comportamento, non cerchi nel codice. Aggiorni la spec e l'agente implementa le modifiche.

Il workflow: Spec, Task, Implementer

Il processo spec-driven segue tre fasi distinte. Ogni fase ha un responsabile e un output chiaro.

Fase 1: Spec (tu)

Definisci cosa deve fare il software dal punto di vista dell'utente.

Scrivi in linguaggio naturale. Nessun dettaglio tecnico. Solo comportamenti, risultati attesi, edge case.

Output: Un documento che chiunque (anche non tecnico) può leggere e capire.

Fase 2: Task (tu o un agente AI)

Trasforma la spec in istruzioni tecniche concrete.

Ogni task è un'azione specifica che un agente AI può eseguire. Endpoint da creare, componenti da sviluppare, logiche da implementare.

Output: Una lista di task tecnici pronti per l'implementazione.

I task possono essere scritti da te, oppure generati da un agente AI a partire dalla spec. In entrambi i casi, tu li approvi prima dell'implementazione.

Fase 3: Implementer (agenti AI)

Gli agenti AI leggono i task e scrivono il codice.

Tu controlli il risultato. Se funziona, approvi. Se manca qualcosa, aggiorni i task (o la spec) e l'agente rigenera.

Output: Codice funzionante che implementa la spec.

Il ciclo completo

Il flusso è: Spec → Task → Implementazione → Review

Se qualcosa non funziona:

Problema di comportamento? Aggiorna la spec
Problema di implementazione? Aggiorna i task

Questo ciclo è veloce. Non stai debuggando codice scritto male. Stai affinando spec e task che producono codice corretto.

Come si scrive una spec

Ora che conosci il workflow, vediamo come scrivere una spec efficace.

Una spec non è un prompt generico. Non è "fammi un'app per gestire i clienti". E non è nemmeno una lista di istruzioni tecniche.

Una spec descrive cosa deve fare il software dal punto di vista dell'utente o del prodotto.

Cosa contiene una spec

La spec risponde a queste domande:

Cosa deve fare (il comportamento)

Descrivi le azioni che l'utente può compiere e i risultati attesi. Sii specifico, ma resta sul piano funzionale.

"L'utente vede una tabella con 3 piani: Basic, Pro, Enterprise. Ogni piano mostra nome, prezzo mensile, lista features, bottone per scegliere"

Come deve comportarsi (gli edge case)

Cosa succede quando qualcosa va storto? Quando i dati non ci sono? Quando la connessione cade?

Cosa vede l'utente mentre i dati si caricano?
Cosa vede se qualcosa non funziona?
Cosa succede se clicca due volte sul bottone?

Esempio pratico

Devi aggiungere una sezione prezzi alla tua app.

Questa è la spec:

Voglio mostrare all'utente i prezzi dei miei tre piani.
L'utente vede una tabella con 3 piani: Basic (9 euro/mese), Pro (29 euro/mese), Enterprise (99 euro/mese). Ogni piano mostra nome, prezzo, lista delle funzionalità incluse, e un bottone per sceglierlo.
Mentre i dati si caricano, l'utente vede un indicatore di caricamento. Se qualcosa va storto, vede un messaggio che spiega il problema.
Quando l'utente clicca su "Scegli piano", viene portato alla pagina di checkout con il piano selezionato.

Questi sono i task (generati dalla spec):

Crea un endpoint API `/api/prices` che ritorna la lista dei piani con nome, prezzo, features
Crea un componente React `PricingTable` che chiama l'API e mostra i piani in una griglia responsive
Mostra uno skeleton loader durante il caricamento, messaggio di errore se l'API fallisce
Aggiungi un bottone "Scegli piano" che porta a `/checkout?plan={planId}`

A questo punto gli agenti AI (implementer) prendono i task e scrivono il codice. Tu controlli il risultato e approvi.

Il grande shift: da developer ad architetto

Gli agenti AI di oggi non sono chatbot che scrivono snippet. Sono sistemi capaci di implementare funzionalità complete, gestire architetture complesse, scrivere test.

Il risultato: lo sviluppatore non scrive più codice riga per riga. Progetta sistemi, scrive spec, controlla output.

È la differenza tra suonare ogni strumento di un'orchestra e dirigere l'orchestra.

Il direttore non è meno importante dei musicisti. È più importante. Senza direzione, l'orchestra produce rumore. Con una buona direzione, produce musica.

Lo stesso vale per lo sviluppo software. Senza spec chiare, gli agenti AI producono codice mediocre. Con spec precise, producono sistemi funzionanti.

Perché funziona (e perché molti falliscono)

Chi usa lo spec-driven development correttamente diventa 100x più produttivo. Non è un'iperbole.

Ma molti developer rifiutano l'agentic coding. Dicono che "l'AI scrive codice spazzatura" o che "non funziona per progetti seri".

Il problema non è l'AI. È come la usano.

Gli agenti AI performano quando ricevono istruzioni chiare e non ambigue. Se scrivi "fammi una pagina prezzi" senza specificare nulla, l'agente fa assunzioni. Assunzioni statisticamente valide (basate su dati di training) ma potenzialmente sbagliate per il tuo caso specifico.

Se invece scrivi una spec dettagliata con comportamenti attesi, edge case, risultati per l'utente, e poi generi task tecnici precisi, l'agente implementa esattamente quello che hai chiesto.

La differenza tra "l'AI non funziona" e "l'AI mi ha fatto risparmiare una settimana" sta tutta nella qualità delle spec.

Il ribaltamento: prima documentazione, poi codice

Per decenni abbiamo seguito questo flusso:

Scrivi il codice
(Forse) scrivi la documentazione
Il codice cambia, la documentazione resta obsoleta
Nessuno si fida più della documentazione

Lo spec-driven development ribalta tutto:

Scrivi la spec (documentazione)
Gli agenti generano il codice dalla spec
Per modificare il comportamento, modifichi la spec
Gli agenti aggiornano il codice di conseguenza

La spec diventa la source of truth. Non il codice.

Questo risolve uno dei problemi più vecchi dello sviluppo software: la documentazione che mente. Se la spec è sbagliata, il codice è sbagliato. Quindi la spec viene mantenuta aggiornata per necessità, non per disciplina.

Tool e risorse

Lo spec-driven development è così recente che non esiste ancora un processo universale. Ma la direzione è chiara.

GitHub SpecKit è il toolkit open source rilasciato da GitHub per questo approccio. Un segnale forte: se GitHub investe in questo, non è un esperimento.

AgentOS è nato prima, dalla community. Oltre 3000 star su GitHub, sviluppato da chi ha capito dove stava andando il settore.

Entrambi seguono lo stesso pattern: spec, task, implementazione.

Chi adotta oggi, vince domani

Nel 2024 lo spec-driven development era un esperimento per early adopter. Nel 2026 è un vantaggio competitivo concreto. Nel 2028 sarà il minimo per restare sul mercato.

I team che adottano questo metodo oggi consegnano in settimane quello che prima richiedeva mesi. Non perché lavorano di più, ma perché lavorano in modo radicalmente diverso.

Se sei uno sviluppatore, questo non è il momento di resistere al cambiamento. È il momento di guidarlo.

Se gestisci un team di sviluppo, la domanda non è "se" adottare lo spec-driven development. È "quanto velocemente".

Risorse

Spec-Driven Development with AI: GitHub SpecKit - Il toolkit open source di GitHub
AgentOS - Tool community-driven con 3000+ star

Vuoi implementare lo spec-driven development nel tuo team?

Prenota una consulenza strategica gratuita di 30 minuti dove analizzeremo insieme il tuo caso specifico: workflow attuale, strumenti in uso, e roadmap personalizzata per adottare lo spec-driven development.

Con il Metodo Luca Di Domenico Studio, ho già aiutato team di sviluppo a moltiplicare la loro produttività con l'agentic coding, consegnando in settimane quello che prima richiedeva mesi.

Raccontaci il tuo progetto

Spec-Driven Development: Cos'è, Come Funziona, Perché Cambia Tutto