Sviluppo guidato dalle specifiche vs Vibe Coding: Waterfall?

Le specifiche come fonte di verità, o una procedura lenta?

Indice

Lo Spec-Driven Development è entrato nel 2026 come la risposta seria degli sviluppatori alla deriva del “vibe coding”.

L’argomento è semplice: gli agenti AI producono output migliori e più coerenti quando implementano in base a una specificazione revisionata piuttosto che a un prompt improvvisato. In teoria, è difficile contestare questa affermazione.

Nella pratica, su Hacker News l’hanno definito “Waterfall Strikes Back” (Il ritorno del modello a cascata).

Entrambe le parti hanno ragione.

Spec-Driven Development versus Vibe Coding

Il caso per lo SDD in un mondo di Vibe Coding

Vibe coding – la pratica di scrivere un prompt generico e iterare su qualsiasi cosa l’agente AI produca – funziona in modo straordinario per lavori piccoli, esplorativi e destinati a essere scartati. Per i primi sei mesi del 2025, è stato il pattern di coding con AI dominante. Gli sviluppatori hanno rilasciato script, prototipi e strumenti semplici più velocemente che mai.

Poi i progetti sono cresciuti. Le funzionalità che coinvolgevano più file hanno iniziato a deviare. I vincoli stabiliti nella prima sessione sono stati dimenticati nella terza. Le assunzioni di sicurezza sono state abbandonate. Le decisioni architetturali sono cambiate a metà funzionalità perché l’agente non aveva una memoria duratura dell’intento.

Lo Spec-Driven Development (SDD) è apparso come la risposta disciplinata. L’affermazione centrale: rendere la specificazione l’artefatto centrale, non il prompt. Scrivi prima i requisiti, il design e un piano delle attività. Lascia che l’agente implementi quegli artefatti una fetta alla volta. Mantieni la specifica versionata e aggiornata.

GitHub Spec Kit, Kiro, i flussi di lavoro SDD di Claude Code e BMAD, insieme ad altri scaffolding della comunità, sono tutte implementazioni di questa idea. Gli strumenti sono reali. L’interesse è reale. Ma anche l’opposizione è reale.

In cosa il Vibe Coding è bravo

Prima di liquidare il vibe coding, vale la pena essere precisi su ciò che fa bene.

Prototipi esplorativi. Quando non sei sicuro di cosa vuoi costruire, il percorso più veloce è costruire qualcosa di approssimativo e reagire ad esso. Lo SDD richiede di sapere cosa specificare. Se non lo sai ancora, le specifiche sono premature.

Esperimenti UI. Il layout visivo e la sensazione delle interazioni sono difficili da specificare in anticipo. Il vibe coding ti permette di vedere rapidamente le opzioni, scartare la maggior parte di esse e convergere su qualcosa che sembra davvero giusto. Un documento dei requisiti non ti aiuta qui.

Automazione da scartare. Script one-off, lavori di estrazione dati, helper per migrazioni – raramente hanno bisogno di un documento di design. Il costo di sbagliare leggermente è basso. Il costo di un processo lento e cerimoniale è reale.

Feedback rapido. Quando hai bisogno di imparare qualcosa rapidamente – questa API funziona come penso? – il vibe coding riduce il ciclo di apprendimento a minuti. Lo SDD rallenterebbe quel processo senza alcun vantaggio.

L’errore è prendere i pattern di successo da questi contesti e applicarli a funzionalità di produzione con vincoli reali, utenti reali e conseguenze reali in caso di errore.

Dove il Vibe Coding fallisce

Il vibe coding si degrada in modo prevedibile man mano che aumentano l’ambito e le posta in gioco.

Modifiche multi-file. Una volta che una funzionalità tocca cinque o più file, la finestra di contesto dell’agente inizia a perdere il controllo degli invarianti. Senza un documento di design, ogni prompt deve ristabilire il contesto che è stato stabilito e dimenticato in una sessione precedente.

Deriva architetturale. Senza obiettivi non espliciti (non-goals), gli agenti implementano cose. L’agente aggiunge un livello di caching perché sembra ragionevole. Tre sessioni dopo, l’assunzione sul caching è integrata nel modello dei dati e rimuoverla è costoso.

Vincoli dimenticati. “Solo gli utenti autenticati possono attivare questo” è una frase in un documento dei requisiti. In una sessione di vibe coding, è qualcosa che hai menzionato una volta nella sessione uno e l’agente non ricorda nella sessione quattro quando scrive il nuovo endpoint.

Assunzioni di sicurezza nascoste. Regole di autorizzazione, limiti di convalida degli input, gestione delle credenziali – queste sono esattamente il tipo di requisiti impliciti che vengono trascurati quando l’agente ottimizza per un codice funzionante plausibile piuttosto che per un codice corretto e vincolato.

Passaggio tra team. Se l’hai costruito attraverso prompting iterativo, l’artefatto che registra cosa è stato deciso e perché è… il log di git. Buona fortuna con quello.

Cosa cambia lo Spec-Driven Development

Lo SDD non pretende di eliminare l’iterazione. Le versioni valide di SDD sono esplicitamente iterative. Ciò che cambiano è il punto in cui avviene l’iterazione. Per la definizione completa – incluso come SDD differisce da TDD, BDD e metodi formali – vedi Cos’è lo Spec-Driven Development?

Invece di iterare sul codice e dedurre l’intento dalle differenze (diffs), iteri sulla specifica e poi implementi. La specifica diventa l’artefatto che registra cosa è stato deciso, perché e cosa è fuori portata – svolgendo una funzione simile alle Decision Records ma orientata verso l’intento della funzionalità piuttosto che verso le scelte a livello di sistema. Il codice implementa quell’intento.

Lo SDD passa attraverso cinque fasi – specificare, pianificare, attività, implementare, validare – con un gate di revisione umana a ogni passo. Vedi Flusso di lavoro Spec-Driven Development dai Requisiti al Codice per il processo completo, i template e i checkpoint. L’agente partecipa alla maggior parte delle fasi, ma gli umani revisionano gli artefatti prima che inizi l’implementazione. Questo step di revisione è la differenza centrale tra SDD e vibe coding.

Perché gli sviluppatori lo chiamano Waterfall

La critica al modello a cascata (waterfall) non è sbagliata. È solo rivolta contro un SDD mal eseguito, non contro l’SDD stesso.

Il modalità di fallimento specifica è la pianificazione anticipata prolungata. La caratteristica distintiva del waterfall è un ciclo di feedback che si estende per settimane o mesi: fase dei requisiti, fase del design, fase di build, fase di test, rilascio. Il feedback arriva tardi. Nel momento in cui scopri che l’assunzione progettuale era sbagliata, hai già costruito sopra di essa per settimane.

Quando uno sviluppatore usa Spec Kit e genera un elenco di attività di 200 righe prima di scrivere una singola riga di codice, e poi passa due giorni a rifinire il documento dei requisiti prima che l’agente tocchi qualcosa, quello è waterfall. È waterfall con markdown invece di UML, ma la modalità di fallimento è identica.

Un commentatore di HN ha descritto l’uso di Spec Kit per un piccolo strumento CLI trovandolo “troppo lento, troppo tweaking prima di vedere il codice”. Questa è la versione cattiva. quell’utente aveva ragione a rifiutarlo per quel compito.

La critica utile non è “le specifiche sono cattive”. È “una pianificazione anticipata lunga prima del feedback è cattiva”. Queste sono affermazioni diverse.

Il terreno intermedio utile

Un buon SDD evita la trappola del waterfall mantenendo la specifica piccola e iniziando l’implementazione presto.

Specifiche piccole. Un documento dei requisiti per una singola funzionalità dovrebbe stare in uno schermo. Se la specifica è di dieci pagine, è o un design di piattaforma o deve essere spezzata in funzionalità più piccole. Le specifiche troppo grandi richiedono troppo tempo per essere revisionate e diventano rapidamente obsolete.

Fette di task brevi. Ogni task dovrebbe essere implementabile in una singola sessione dell’agente, revisionabile come un diff piccolo e testabile in isolamento. Se i task sono troppo grandi, il ciclo di implementazione si allunga e il mapping tra specifica e codice diventa difficile da verificare.

Implementazione anticipata. Specifica il primo task, implementalo, validalo, poi passa al task successivo. Non specificare tutto prima di implementare qualcosa. La prima implementazione rivelerà cose che la tua specifica ha sbagliato. Aggiorna la specifica prima di continuare.

Specifica vivente. Quando la realtà differisce dal design – e lo farà – aggiorna la specifica, non solo il codice. La specifica è utile solo se riflette ciò che è stato effettivamente costruito.

Test come feedback eseguibile. Ogni criterio di accettazione dovrebbe mapparsi su almeno un test. La suite di test è la versione leggibile dalla macchina della specifica. Se la specifica dice “solo gli utenti autenticati possono attivare questo”, dovrebbe esserci un test che verifica che le richieste non autenticate siano rifiutate.

Questo ibrido – specifiche piccole, task brevi, implementazione anticipata, documenti viventi – è ciò che funziona davvero. Non è vibe coding e non è waterfall. È un’iterazione controllata con artefatti duraturi.

Quando lo SDD batte il Vibe Coding

Usa lo SDD – anche un SDD leggero – quando il costo di sbagliare è reale.

Logica di business rischiosa. Fatturazione, permessi, migrazioni dati, idempotenza – qualsiasi logica in cui un comportamento errato è costoso o difficile da invertire. Il vibe coding lascia questi tipi di requisiti impliciti. Lo SDD li rende espliciti e revisionabili prima dell’implementazione.

Modifiche alle API di produzione. Qualsiasi modifica a un contratto API pubblico o interno dovrebbe avere un documento di design. Il documento di design è ciò che revisioni prima che l’agente scriva codice che rompe i chiamanti.

Flussi di lavoro multi-agente. Quando più agenti stanno implementando parti diverse di una funzionalità, la specifica è la fonte di verità condivisa. Senza di essa, ogni agente ottimizza localmente e i pezzi potrebbero non combaciare.

Passaggio tra team. Se un altro sviluppatore o un altro agente continuerà questo lavoro, la specifica è l’artefatto di passaggio. Un log git e un README non sono sufficienti.

Refactoring significativi. I refactoring che toccano astrazioni di base necessitano di un’enunciazione esplicita di cosa deve rimanere invariato (comportamento) e cosa è consentito cambiare (struttura). Senza di essa, l’agente potrebbe rompere contratti che pensavi fossero preservati.

Quando il Vibe Coding è ancora migliore

Lo SDD è un sovraccarico. A volte il sovraccarico non ne vale la pena.

Script rapidi. Uno script di 50 righe per rinominare file o trasformare JSON non ha bisogno di un documento dei requisiti. Scrivi il prompt, controlla l’output, rilascialo.

Esperimenti. Se stai imparando se un approccio è fattibile – esplorando un’API, testando una libreria, validando un’ipotesi – hai bisogno di velocità, non di struttura. Sperimenta prima, specifica se l’esperimento ha successo.

Schizzi UI. Il design delle interazioni beneficia del vedere piuttosto che dello specificare. Costruisci rapidamente diverse variazioni approssimative, reagisci a ciò che vedi e specifica solo ciò che stai effettivamente per rilasciare.

Automazione monouso. Script one-time, importazioni dati, helper per migrazioni – il costo di un risultato leggermente errato è solitamente basso, e l’artefatto verrà comunque eliminato dopo l’uso.

Prototipi solisti. Se sei l’unica persona che vedrà mai questo codice e l’obiettivo è l’apprendimento piuttosto che la produzione, il vibe coding è più veloce e gli svantaggi sono contenuti.

Un semplice framework decisionale

La domanda pratica non è “SDD o vibe coding?”. È “quanta specifica ho bisogno per questo specifico compito?”

Usa il vibe coding quando:

  • Il compito richiede meno di un giorno
  • Stai esplorando o imparando
  • L’artefatto è da scartare o a bassa posta in gioco
  • Sei l’unica persona che toccherà questo
  • La velocità del feedback è più importante della correttezza

Usa lo SDD leggero quando:

  • Il compito richiede due o più giorni
  • Sono interessati più file
  • Ci sono requisiti espliciti di sicurezza o correttezza
  • Un’altra persona o agente continuerà il lavoro
  • Hai bisogno di scrivere test che mappino ai requisiti

Usa lo SDD completo quando:

  • La funzionalità tocca un’interfaccia pubblica o un contratto dati
  • Sono coinvolti più agenti o membri del team
  • L’organizzazione richiede una revisione del design prima dell’implementazione
  • Sono richiesti conformità o tracce di audit

L’errore più comune è applicare lo SDD completo a compiti che necessitano solo di un SDD leggero, e applicare nessuna specifica a compiti che necessitano almeno di una leggera. Qualunque livello tu scelga, la specifica rimane utile solo se qualcosa continua a controllarla rispetto al codice; Mantenere Specifiche, Test e Codice in Sync nello Sviluppo AI copre i controlli di tracciabilità che catturano una specifica che diventa silenziosamente obsoleta.

Un SDD cattivo è waterfall con markdown. Un SDD buono è un’iterazione controllata con artefatti duraturi. Il vibe coding è lo strumento giusto per i compiti giusti – e lo strumento sbagliato per quelli sbagliati. Conoscere la differenza è l’abilità.

Iscriviti

Ricevi nuovi articoli su sistemi, infrastruttura e ingegneria AI.