2026-06-05

Il vibe coding è morto, meglio scrivere specifiche? Per i PM esiste una terza via: dillo e l'IA lo costruisce

Nel mondo della metodologia è in corso una rissa, con titoli che fanno paura: «il vibe coding è morto, passate subito allo spec-driven development.»

Il vento sta davvero cambiando. Spec Kit di GitHub ha già superato novantamila stelle, AWS ha lanciato Kiro costruito attorno al principio «prima le specifiche, poi il codice», Thoughtworks l’ha inserito nel Technology Radar. La narrativa dominante è: le specifiche sono l’unica fonte di verità, il codice è solo il loro prodotto; se c’è conflitto, si corregge il codice, mai le specifiche.

Sembra ragionevole. Ma se sei un product manager, prima di correre a imparare «come si scrivono le specifiche», fermati un momento.

Il pendolo ha oscillato troppo

La storia va così:

Prima è esploso il vibe coding — una frase buttata all’IA e lei ti costruisce tutto. Magnifico, ma il crollo è arrivato in fretta: nessuna struttura, impossibile modificare, nessuno riesce a spiegare cosa è stato fatto. Allora si è oscillato all’estremo opposto: scriviamo tutto in specifiche, più sono dettagliate meglio è, e poi l’IA le segue punto per punto.

Il problema, per un PM, è che «produrre un documento di specifiche preliminare e dettagliato» è una cosa che conosci benissimo — si chiama PRD. Quel documento da decine di pagine che invecchia prima ancora di essere letto, che nessuno finisce mai. Una delle liberazioni più grandi portate dall’IA era proprio toglierti quella servitù documentale; ora lo spec-driven te la restituisce tale e quale, con un nome più alla moda.

Dal «buttare tutto» al «scrivere tutto» è passare da un estremo all’altro. Nessuno dei due è il posto giusto per un product manager.

La terza via: la specifica non si scrive, si dice chiaramente — e poi si costruisce

Il vibe coding è troppo fragile, scrivere le specifiche è troppo pesante. In mezzo c’è una strada, quella che doaipm percorre da sempre — 言出法随: dillo e l’IA lo costruisce.

Il cuore è questo: non hai bisogno di una specifica scritta in un documento; hai bisogno di saper dire chiaramente cosa vuoi fare. E «saper dire le cose chiaramente» è esattamente la competenza base di qualsiasi product manager — non è una skill nuova.

In concreto, si tratta di due cose:

Primo, la specifica vive nella conversazione, non nel documento. Non serve produrre una spec completa prima di iniziare. Esprimi l’intenzione — chi ha il problema, quale problema, quali sono i vincoli fondamentali, cosa significa avere successo — e poi lascia che l’IA trasformi tutto questo in qualcosa che funziona sul momento. Dove non è chiaro, l’IA ti fa domande (un buon agente dovrebbe porre 3–5 domande precise prima di muoversi), e tu chiarisci nella conversazione. Il chiarimento avviene nell’interazione, non in un documento che nessuno vuole leggere.

Secondo, un prototipo ad alta fedeltà che funziona è già la specifica migliore che esiste. Un documento di testo viene letto in dieci modi diversi da dieci persone diverse; un prototipo su cui si può cliccare, che gira, con stati reali (caricamento / vuoto / errore / successo), viene capito da tutti al primo sguardo. Un prototipo ad alta fedeltà è una specifica che parla da sola — non va interpretata, va vissuta. È anche per questo che doaipm sconsiglia i wireframe a bassa fedeltà: nell’era dell’IA, costruire direttamente la cosa vera è più veloce e genera meno fraintendimenti.

La struttura da dove arriva? — Passi piccoli e rete di sicurezza

Qualcuno chiederà: senza specifiche pesanti, come si evita di ricadere nel caos del vibe coding?

Con due cose, non con documenti spessi:

Chi dice che la specifica è l’unica fonte di verità ha dimenticato una frase: nell’era dell’IA, la «fonte di verità» ad alta fedeltà non è il documento — è il prodotto che sta girando davanti ai tuoi occhi.

Allora, cosa vale la pena credere oggi

Non scegliere tra «vibe coding» e «spec-driven» — è un falso dilemma.

Non è l’ennesimo framework da imparare — di framework ce ne sono già abbastanza. È tornare al gesto più semplice del product manager: capire cosa si vuole, dirlo chiaramente, e farlo partire.

言出,法随。

Letture di approfondimento

Discussione

Nessun login, anonimo possibile. Sii gentile.
Caricamento…