Smettere di scrivere il software due volte: sviluppo guidato dalle specifiche e la fine delle riscritture

Perché il software è sempre stato scritto due volte, una nelle specifiche e un’altra come codice, e perché quella seconda scrittura sta finalmente scomparendo.

Nello sviluppo software, quando è fatto bene, dobbiamo scrivere il software due volte: prima in specifiche dettagliate che spiegano esattamente cosa il software deve fare, e poi di nuovo come codice che dà vita a quelle specifiche. Ma ecco una verità dura: raramente viene fatto bene la prima volta.

Il processo spesso si sfalda perché creare specifiche esaustive richiede tempo, e le squadre raramente catturano in anticipo tutti i dettagli necessari. Questo porta a lacune, assunzioni e rilavorazioni costose. Il risultato è che i progetti software spesso sforano il budget, mancano le scadenze e lasciano tutti frustrati.

I costi nascosti dello scrivere il software due volte

Per capire perché scrivere il software due volte è necessario ma raramente fatto bene, scomponiamo le due fasi.

1. La prima scrittura: specifiche in linguaggio naturale

La prima volta che il software viene scritto non stiamo scrivendo codice affatto. Si creano requisiti, storie utente e documenti di progetto, redatti in linguaggio naturale. È qui che le squadre descrivono come il software dovrebbe funzionare, cosa gli utenti possono fare e come dovrebbe essere l’esperienza.

Ma ecco il problema: nessuna squadra ha mai il lusso di scrivere tutti i dettagli. Chi si occupa di prodotto spesso deve correre per rispettare tempi aggressivi, e in alcuni progetti non c’è nemmeno una figura professionale di prodotto. Si tracciano le linee generali, ma funzioni e interazioni chiave sfuggono. Come disse Steve Jobs, «i grandi prodotti nascono da 5.000 piccole decisioni», ma nella maggior parte dei progetti quelle decisioni non le prendiamo in anticipo. Restano all’interpretazione successiva di chi sviluppa, che porta al secondo passo.

2. La seconda scrittura: tradurre le specifiche in codice

Una volta consegnate le specifiche, lo sviluppo è responsabile di trasformare quelle descrizioni in codice funzionante. Ma quando la prima scrittura è incompleta, chi sviluppa è costretto a usare l’immaginazione per riempire i vuoti. Si fanno assunzioni e, anche se le persone in ingegneria possono padroneggiare bene la tecnologia, possono non avere il quadro completo della visione di prodotto.

È qui che i problemi vengono a galla:

• I dettagli mancanti creano attrito: quando le squadre di prodotto non specificano una funzione o un caso d’uso importante, lo sviluppo deve indovinare o improvvisare. Spesso ne risulta funzionalità che non soddisfa le aspettative.
• Le assunzioni portano a rilavorazioni: quando lo sviluppo riempie i vuoti, può costruire funzioni in modi che non si allineano alla visione di prodotto, causando rilavorazioni massicce più avanti nel progetto.
• Lo scaricabarile diventa inevitabile: quando le scadenze slittano e i budget sforano, le squadre si rimbalzano la colpa. Le squadre di prodotto rimproverano all’ingegneria di «non aver capito», mentre l’ingegneria punta il dito sulle specifiche poco chiare.

Il risultato è una cascata di problemi che porta a tempi mancati, budget superati ed esiti insoddisfacenti. La ricerca CHAOS dello Standish Group traccia da anni che la maggior parte dei progetti software sfora il budget e manca le date di consegna. Uno studio di McKinsey con l’Università di Oxford ha trovato che i grandi progetti informatici sforano in media del 45% il budget e del 7% i tempi, consegnando il 56% di valore in meno del previsto, e che il 17% dei grandi progetti informatici va così male da minacciare l’esistenza stessa dell’azienda.

Chiaramente qualcosa in questo processo è rotto.

La pratica ora ha un nome

Il settore si è accordato su un termine per questo mentre la maggior parte delle persone discuteva di prompt: sviluppo guidato dalle specifiche. Scrivi prima i requisiti, i vincoli e i criteri di successo. Tratta quella specifica come la fonte della verità. Lascia che l’agente costruisca contro di essa.

GitHub ha rilasciato Spec Kit. AWS ha rilasciato Kiro. BMAD-METHOD, OpenSpec e Tessl hanno fatto ciascuno un tentativo. Martin Fowler ne ha scritto. La convergenza non è un caso: è ciò che accade quando un’intera categoria scopre lo stesso modo di fallire nello stesso momento.

E il modo di fallire è quello descritto sopra. Gli strumenti che partono dal prompt saltano la prima scrittura del tutto. Vanno direttamente alla seconda, indovinando ogni decisione che la specifica non ha mai preso. Che va bene per una dimostrazione ed è rovinoso per un prodotto.

Lo sviluppo guidato dalle specifiche non elimina la prima scrittura. La rende la sola che richiede giudizio umano.

La nuova prima scrittura: specifiche che si possono davvero finire

Ecco cosa cambia. La ragione per cui nessuno scriveva specifiche complete non è mai stata la mancanza di volontà: era che il lavoro era troppo lento per giustificarsi. Settimane di esplorazione per produrre un documento che invecchiava al primo contatto con il primo ciclo di lavoro. Così le squadre scrivevano le linee generali e lasciavano le 5.000 piccole decisioni da scoprire più tardi, una interpretazione alla volta.

Quando redigere una specifica richiede ore anziché mesi, l’aritmetica si inverte. Puoi permetterti di essere esaustivo. Requisiti funzionali, progetto visivo, modello dei dati, casi limite, catturati prima che qualcuno apra un editor, e abbastanza economici da rivedere quando impari qualcosa.

Quest’ultima parte conta. Una specifica che non si può rivedere a basso costo diventa una bugia nel momento in cui arriva la realtà. È lo stesso istinto che sta dietro al costruire API-first: prendere bene le decisioni portanti prima che qualcuno scriva una schermata, e il resto segue.

La nuova seconda scrittura: generazione di codice, non traduzione

Una volta che la specifica è completa, la seconda scrittura smette di essere un problema di traduzione. Diventa un problema di generazione. Linguaggi standard: JavaScript, TypeScript, Python. Framework standard: React, Next.js. Codice vero, nelle forme che l’ingegneria già conosce, derivato da un documento che ha già preso ogni decisione.

La differenza non è che chi sviluppa lavori più in fretta. È che smette di fare la parte che non è mai stata ingegneria: la riesposizione meccanica di decisioni che qualcun altro ha già preso.

Cosa cambia a valle

Tre cose cambiano insieme:

1. La prima scrittura viene finita: quando il lavoro di specifica costa ore anziché mesi, le squadre possono permettersi di prendere le piccole decisioni in anticipo anziché scoprirle in revisione.
2. Nessuno riempie i vuoti: il codice generato da una specifica completa non richiede a nessuno di indovinare cosa intendesse la squadra di prodotto. Indovinare è sempre stato l’origine dei difetti.
3. Le rilavorazioni smettono di comporsi: intenzione e implementazione partono allineate. Ciò che prima era una riscrittura diventa una modifica alla specifica.

Il futuro dello scrivere software: linguaggio naturale

Da quando esiste il software rilasciato, il lavoro ha richiesto di scriverlo due volte: una in linguaggio naturale, un’altra come codice. Quella seconda scrittura non è mai stata la parte di valore. Era il pedaggio che pagavamo perché non c’era un’altra strada.

È la mossa attorno a cui si organizza la prossima generazione di costruttori di app con IA: chiarezza prima del codice. Descrivere l’applicazione come blueprint, prendere bene l’architettura, lasciare che il codice venga generato contro di essa. Non una scorciatoia che salta il lavoro di definizione, ma una ragione per farlo finalmente come si deve.

Ora c’è un’altra strada. Il software è sempre stato pensato per essere scritto una volta sola.

Letture collegate

La guida completa alla pratica: sviluppo guidato dalle specifiche. Perché la generazione che parte dal prompt ha saltato questo passo è trattato in il vibe coding ha tradito la sua promessa, e cosa lo sostituisce in cosa viene dopo il vibe coding.

Domande frequenti

Che cos’è lo sviluppo guidato dalle specifiche? Sviluppo guidato dalle specifiche significa 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 come risposta diretta ai modi di lavorare che partono dal prompt e saltano del tutto il passo di definizione.

In cosa lo sviluppo guidato dalle specifiche differisce dallo scrivere un documento di requisiti tradizionale? Il documento è la stessa idea; l’economia no. Le specifiche tradizionali erano abbastanza costose che le squadre scrivevano le linee generali e scoprivano il resto in revisione del codice. Quando una specifica richiede ore anziché mesi e si può rivedere a basso costo, diventa sensato finirla, e sensato 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.

Lo sviluppo guidato dalle specifiche rallenta le squadre? Sposta il lavoro, non lo aggiunge. Le decisioni catturate in una specifica vengono prese comunque da qualcuno: o deliberatamente in anticipo o implicitamente da chi sviluppa o da un modello che indovina più tardi. La seconda via è l’origine delle rilavorazioni.

Che cosa succede a chi sviluppa se il codice viene generato dalle specifiche? Sparisce la riesposizione meccanica delle decisioni di qualcun altro. Non sparisce il giudizio su architettura, compromessi, correttezza e su cosa non costruire. Quelle sono sempre state le parti che richiedevano una persona in ingegneria.