Sviluppo guidato dalle specifiche: la pratica su cui la categoria è convergita

Ogni strumento di IA per il codice degno di nota ha rilasciato la stessa funzione nell’arco di circa un anno, e non succede quasi mai per caso.

Nel 2025 la domanda interessante era quanto stessero diventando buoni i modelli. Nel 2026 la domanda interessante è cosa gli consegni.

GitHub ha rilasciato Spec Kit. AWS ha rilasciato Kiro, un ambiente di sviluppo costruito attorno all’idea. BMAD-METHOD, OpenSpec e Tessl hanno fatto ciascuno un tentativo. Cursor ci è arrivato tramite i file di regole. Martin Fowler ha pubblicato un confronto delle implementazioni. Quando sei squadre indipendenti convergono sulla stessa risposta in dodici mesi, non si stanno copiando. Stanno tutte sbattendo contro lo stesso muro.

Il muro ora ha un nome. Anche la soluzione.

Che cos’è davvero lo sviluppo guidato dalle specifiche

Scrivi i requisiti, i vincoli e i criteri di successo prima che venga generato qualsiasi codice. Tratta quel documento come la fonte della verità. Lascia che l’agente costruisca contro di esso.

È tutto. Non è un’idea nuova: è ingegneria dei requisiti, che il settore ha praticato male per trent’anni e poi ha in gran parte abbandonato come troppo lenta. Ciò che è cambiato non è il concetto. È l’economia.

Le specifiche erano costose da scrivere e costose da tenere aggiornate, il che significava che la maggior parte delle squadre scriveva le linee generali e scopriva tutto il resto in fase di revisione del codice. Era uno scambio razionale quando una persona ci metteva comunque tre settimane a costruire la funzione. Ha smesso di essere razionale quando la generazione è diventata rapida, perché ora la specifica è la parte lenta, e nella parte lenta abita tutto il giudizio.

Il modo di fallire contro cui è stato inventato

Gli strumenti che partono dal prompt saltano la specifica del tutto. Descrivi un risultato, lo strumento produce qualcosa che gli assomiglia, e ogni decisione che la descrizione non copriva viene presa in silenzio dal generatore.

Quali decisioni? Quelle che si rivelano importanti. Se un indirizzo di posta elettronica sia unico, e unico rispetto a cosa. Cosa possa ancora vedere un account disdetto. Cosa succeda quando due persone modificano lo stesso record. Se quell’elenco abbia bisogno della paginazione prima di contenere diecimila righe.

Nessuno ha posto quelle domande, quindi nessuno ha risposto, ma l’applicazione ha una risposta a ognuna, scelta per inferenza da un contesto che non comprendeva mai la tua attività.

La stessa dinamica compare in ogni strumento che salta il passo di definizione. È il meccanismo dietro il problema del 70%: il progresso si arresta non perché il lavoro che resta sia difficile, ma perché è bloccato da una decisione architetturale presa implicitamente, centinaia di generazioni prima, che non si può più cambiare senza smontare il sistema.

I dati su cosa succede senza

Il rapporto DORA del 2025 sullo stato dello sviluppo software assistito dall’IA è la lettura più chiara disponibile. Il 90% delle persone che lavorano nella tecnologia usa ora l’IA al lavoro e più dell’80% crede che abbia aumentato la propria produttività. E una maggiore adozione dell’IA è associata a un aumento della produttività di rilascio e a un aumento dell’instabilità dei rilasci, allo stesso tempo.

Più rapidi a rilasciare. Peggiori a tenere le cose in funzione. Entrambe, insieme.

L’analisi di GitClear del 2026 su 623 milioni di modifiche al codice mostra la forma del danno. Rispetto al riferimento del 2023: blocchi di codice duplicati in aumento dell’81%, copia e incolla dentro lo stesso invio salito dal 9,4% nel 2022 al 15,7% nella prima metà del 2026, costrutti che mascherano gli errori in aumento del 47%. Nel frattempo le chiamate di funzione tra file, il miglior indicatore disponibile del riuso del codice, in calo del 35%, e l’attività di rifattorizzazione crollata dal 21% delle modifiche nel 2022 al 3,8% nel 2026.

Chi sviluppa ha ora circa cinque volte più probabilità di copiare e incollare che di rifattorizzare. Nel 2022 quel rapporto andava nella direzione opposta.

Nulla di questo è un problema di qualità del modello. È ciò che accade quando la generazione è economica e la struttura non è il compito esplicito di nessuno.

I tre gradi di impegno

Non tutti intendono la stessa cosa con questa espressione, e le differenze contano in pratica. L’inquadratura di Martin Fowler è la più pulita che ho visto.

Specifica prima. Scrivi la specifica, generi da essa, poi mantieni il codice a mano. La specifica guida la costruzione iniziale e poi diventa gradualmente storica. La più facile da adottare, con le garanzie più deboli: sei mesi dopo il documento descrive un sistema che non esiste più.

Specifica come ancora. Specifica e codice evolvono insieme. Cambi la specifica, rigeneri le parti interessate, tieni aggiornati entrambi. Più disciplina, e il guadagno è che il documento resta affidabile.

Specifica come sorgente. La specifica è il solo artefatto che modifichi. Il codice è output, come è output un binario compilato: non lo rattoppi a mano. Le garanzie più forti e il salto più grande nel modo di lavorare di una squadra.

La maggior parte delle squadre che si definiscono guidate dalle specifiche pratica la specifica prima. È un miglioramento reale rispetto al promptare alla cieca, ed è anche la versione che decade in silenzio.

Cosa va nella specifica

La prova utile: se il generatore dovrebbe indovinare, va nel documento.

• Il modello dei dati. Entità, relazioni, cardinalità, cosa rende unico un record, cosa succede alla cancellazione. È la sezione di maggior valore e quella più spesso saltata.
• Tipi di utente e permessi. Chi esiste, cosa ciascuno può vedere e fare, cosa succede ai confini.
• Gli invarianti. Regole che non devono mai essere violate, dette in modo netto. Non «gestire gli errori con eleganza»: quello è un desiderio, non un vincolo.
• Criteri di successo. Come saprai che la cosa funziona, in termini abbastanza precisi perché un disaccordo sul fatto che funzioni sia risolvibile.

Cosa non va dentro: i dettagli di implementazione che il generatore sceglie meglio di te. Una specifica che nomina le variabili non è una specifica, è codice con strumenti peggiori.

La parte che tutti sbagliano

Una specifica aiuta solo se è imponibile in un posto diverso dalla prosa.

Se un vincolo vive solo nel documento, è un suggerimento. Il generatore l’ha letto una volta e può averlo rispettato o no nel quattordicesimo file che ha toccato. I vincoli devono finire dove il sistema controlla: «non nullo» e «unico» nel database anziché in un gestore di modulo, tipi ai confini anziché in un commento, autorizzazione come politica che il sistema valuta anziché come condizione che qualcuno si è ricordato di scrivere.

È la differenza tra lo sviluppo guidato dalle specifiche come pratica e lo sviluppo guidato dalle specifiche come genere di documento. Il documento è come decidi. L’imposizione è come mantieni la decisione.

Come capire se lo stai davvero praticando

Quattro domande, e sono scomode di proposito.

1. Quando qualcosa si rompe, correggi il codice o la specifica? Se la risposta è sempre il codice, stai praticando al massimo la specifica prima, e il documento è già vecchio.
2. Una persona nuova potrebbe leggere la specifica e prevedere come si comporta il sistema? Se dovesse leggere il codice per saperlo, la specifica è un riassunto anziché una sorgente.
3. C’è qualcosa nella specifica che il sistema non può violare? Se ogni regola è prosa, nessuna è garantita.
4. Rivedi la specifica o il diff? Rivedere migliaia di righe di codice generato è teatro. Discuti del documento mentre discutere costa ancora poco.

Dove questo lascia gli strumenti

La maggior parte delle implementazioni attuali è guidata dalle specifiche specificamente per la generazione del codice. Producono una specifica e generano un’implementazione contro di essa, e l’artefatto su cui operano è una base di codice.

La versione più difficile estende la stessa logica all’applicazione intera (il modello dei dati, la superficie di API, il confine dell’autenticazione, l’interfaccia) così che la specifica copra non solo ciò che il codice fa ma ciò che il sistema è. È esattamente la fase di blueprint di Archie, ed è per questo che la descrivo come sviluppo guidato dalle specifiche applicato alla pila intera anziché a un repository. Perimetro diverso, stesso principio: definire prima di generare.

Persone ragionevoli non sono d’accordo su quanto spingerlo. Nessuno che faccia sul serio sostiene di tornare indietro.

Quanto costa

Anticipare il giudizio è più lento per la prima settimana di un progetto e più rapido per ogni settimana successiva. Quel costo è reale e si paga esattamente nel momento in cui lo slancio sembra più prezioso, mentre un concorrente rilascia qualcosa di visibile. Ci saranno settimane in cui la squadra che ha saltato tutto questo sembrerà in vantaggio.

Anche la disciplina decade. Scrivere i vincoli è meno piacevole che guardare un’interfaccia apparire, e rivedere un documento è meno soddisfacente che rivedere codice. Queste abitudini si erodono sotto la pressione delle scadenze, che è la stessa pressione che le rende importanti.

E davvero non si applica a tutto. Se stai validando un’idea questo fine settimana e intendi buttare il risultato, buttalo. Nulla di tutto questo vale la pena per software con due giorni di vita.

La ragione per cui è rimasto

Ogni tentativo precedente di far scrivere prima le specifiche alle squadre è fallito, ed è fallito per una buona ragione: la specifica era peso in più sopra il lavoro vero. Scrivevi il documento e poi dovevi comunque costruire la cosa.

Non è più quello lo scambio. Ora il documento è la maggior parte del lavoro, e la costruzione è la parte economica. Sei squadre indipendenti lo hanno notato nell’arco di un anno perché era la conseguenza ovvia del fatto che il modello è diventato buono.

La pratica non ha vinto una discussione. L’economia si è spostata sotto di essa.

Letture collegate

La diagnosi originale: il vibe coding ha tradito la sua promessa. Dove è andata poi la categoria: cosa viene dopo il vibe coding. Lo stesso argomento applicato a sistemi interi: progettazione software AI-first dai primi principi. E la formulazione più vecchia della stessa idea: smettere di scrivere il software due volte.

Domande frequenti

Che cos’è lo sviluppo guidato dalle specifiche? Scrivere i requisiti, i vincoli e i criteri di successo prima che venga generato qualsiasi codice, e trattare quella specifica come la fonte della verità contro cui l’agente di IA costruisce. È emerso nel 2025 e 2026 come risposta diretta ai modi di lavorare che partono dal prompt e saltano il passo di definizione.

In cosa differisce da un documento di requisiti tradizionale? Il concetto è lo stesso; l’economia no. Le specifiche tradizionali erano abbastanza costose che le squadre scrivevano le linee generali e scoprivano il resto durante l’implementazione. Quando redigerne una richiede ore anziché mesi e si può rivedere a basso costo, diventa sensato finirla e tenerla aggiornata.

Quali strumenti supportano lo sviluppo guidato dalle specifiche? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec e Tessl sono le implementazioni con un nome, e Cursor supporta una versione più leggera tramite i file di regole. Differiscono soprattutto per quanto strettamente la specifica sia legata al codice: se guidi la generazione una volta, evolva accanto al codice o sia il solo artefatto che modifichi.

Quali sono i tre gradi dello sviluppo guidato dalle specifiche? Specifica prima, dove la specifica guida la costruzione iniziale e poi mantieni il codice a mano. Specifica come ancora, dove specifica e codice evolvono insieme. Specifica come sorgente, dove la specifica è la sola cosa che modifichi e il codice è trattato come output. La maggior parte delle squadre che la praticano fa la specifica prima.

Lo sviluppo guidato dalle specifiche rallenta le squadre? Sposta il lavoro anziché aggiungerlo. Le decisioni contenute in una specifica vengono prese comunque: o deliberatamente all’inizio o implicitamente da un generatore che indovina più tardi, e la seconda via è l’origine della rilavorazione. È più lento per la prima settimana e più rapido dopo.

Cosa dovrebbe entrare in una specifica? Tutto ciò che il generatore dovrebbe altrimenti indovinare: il modello dei dati con relazioni e regole di unicità, tipi di utente e permessi, invarianti che non devono mai essere violati e criteri di successo abbastanza precisi da risolvere un disaccordo. Lascia fuori i dettagli di implementazione che il generatore sceglie meglio di te.

Lo sviluppo guidato dalle specifiche è la stessa cosa del design AI-first? Lo sviluppo guidato dalle specifiche è la pratica di definire prima di generare. Il design AI-first è l’insieme più ampio di conseguenze architetturali, che copre anche dove i vincoli vengono imposti, in quale ordine prendi le decisioni e come progettare per consumatori agentici accanto a quelli umani.