Il risultato ricorda una celebre battuta di Nanni Moretti in “Ecce Bombo”: “faccio cose, vedo gente”<\/em>. Sembra tutto molto produttivo, finch\u00e9 qualcuno non ti chiede cosa tu abbia effettivamente costruito.<\/p>\n\n\n\n C’\u00e8 poi quella che potremmo definire come “pigrizia da Avanti, Avanti, Avanti”: quanto piacere provate quando installate un software cliccando su “Avanti” a ripetizione, senza dover rispondere a nessuna domanda? Nel vibe coding accade la stessa cosa: scriviamo un prompt sgrammaticato, di quelli che la nostra maestra delle elementari ci avrebbe stracciato davanti alla classe, ma il modello, allenato su trilioni di parametri, capisce e interpreta tutto nel modo corretto.<\/p>\n\n\n\n Il vibe coding funziona benissimo nelle demo online, dove l’AI si comporta come uno sviluppatore senior fullstack capace di risolvere tutto in cinque minuti. Il problema sorge quando lo si applica al gestionale legacy di un’azienda reale: centomila righe di codice scritte da persone che nel frattempo hanno cambiato lavoro. La ragione \u00e8 tecnica e ha un nome preciso: context rot. Pi\u00f9 token entrano nella finestra di contesto, meno affidabile diventa la risposta del modello. Con l’allungarsi della chat, il sistema dimentica le decisioni prese all’inizio e ignora i vincoli stabiliti dieci messaggi prima. Quante volte avreste voluto tirare un pugno al monitor quando il modello, per l’ennesima volta, ha iniziato a includere quella libreria che avevate detto in modo esplicito di non includere, o si \u00e8 fissato a creare variabili in camelCase quando tutto il programma \u00e8 impostato in snake_case? Senza una specifica che ancori la conversazione, non si ottimizza nulla: si perde semplicemente contesto a ogni scambio.<\/p>\n\n\n\n L’effetto pratico \u00e8 uno “spaghetti code<\/em>” nato da sessioni di chat differenti: tre conversazioni distinte producono tre modalit\u00e0 diverse per gestire gli errori all’interno dello stesso progetto, e nessuno ricorda pi\u00f9 quale sia quella “giusta”.<\/p>\n\n\n\n Il pericolo maggiore, tuttavia, non \u00e8 l’errore evidente che salta subito all’occhio, ma l’allucinazione verosimile<\/strong><\/em>: codice che appare corretto, supera una review superficiale e nasconde un bug insidioso. L’esempio che propongo pi\u00f9 spesso \u00e8 il fantomatico La tesi che ho sostenuto sul palco non \u00e8 che il vibe coding sia superato in assoluto, ma che sia ormai impraticabile come approccio unico. Esiste una via per trasformare l’AI da assistente imprevedibile a esecutore governabile, e prende il nome di Spec-Driven Development (SDD).<\/p>\n\n\n\n La metafora dell’harness engineering rende l’idea meglio di qualsiasi definizione formale: i progetti basati sull’AI falliscono in produzione per mancanza di un’infrastruttura di supporto attorno al modello, e non per via delle sue capacit\u00e0 intrinseche.<\/p>\n\n\n\n Il modello linguistico \u00e8 come un cavallo potente e veloce che non sa dove andare da solo. L’imbracatura rappresenta l’insieme di vincoli, guardrail e cicli di feedback che indirizzano questa energia in modo controllato. In questo scenario, chi scrive codice \u00e8 il cavaliere: indica la direzione e convalida il percorso, senza dover tenere le mani sulle redini a ogni singolo passo.<\/p>\n\n\n\n Lo Spec-Driven Development \u00e8 una metodologia in cui le specifiche assumono il ruolo di artefatti eseguibili di prima classe. Il flusso si inverte: si redige prima il contratto e poi si lascia che l’AI generi il codice rispettandolo. La sintesi pi\u00f9 efficace \u00e8 racchiusa in questo principio:<\/p>\n\n\n L’istruzione “Voglio un login sicuro” pu\u00f2 essere sufficiente per uno sviluppatore esperto che ha gi\u00e0 affrontato il problema e conosce gli standard aziendali in materia. Non occorrono strumenti proprietari: il formato Markdown \u00e8 facilmente leggibile dal team e rappresenta, al contempo, la lingua madre dei Large Language Model. Se si desidera azzerare le ambiguit\u00e0 del linguaggio naturale, si pu\u00f2 ricorrere a EARS (Easy Approach to Requirements Syntax), una notazione rigorosa creata da Alistair Mavin in Rolls-Royce nel 2009 per i requisiti dei motori aeronautici. Strutture come “QUANDO [evento] IL sistema dovr\u00e0 [azione]” associano ogni decisione a un vincolo logico testabile in modo automatico.<\/p>\n\n\n\n Pur non essendo nata per l’intelligenza artificiale, questa sintassi neutralizza il principale punto debole degli agenti autonomi. Una soluzione ideata per prevenire le incomprensioni tra esseri umani si \u00e8 rivelata ideale per regolare la comunicazione tra sviluppatore e macchina.<\/p>\n\n\n\n La differenza emerge chiaramente analizzando un caso reale.<\/p>\n\n\n\n Un’API in PHP che smette di funzionare in seguito al passaggio a PHP 8.1. Con l’approccio vibe coding, il flusso di lavoro degenera rapidamente: si scrive “non funziona pi\u00f9”, il modello propone una patch, si risponde “non funziona ancora”, il sistema genera una seconda versione che rompe un altro componente, e infine una terza che ripristina la prima introducendo un nuovo bug. Il bilancio? Due ore perse, risorse sprecate e nessuna traccia delle modifiche effettuate.<\/p>\n\n\n\n Con una specifica minima, lo stesso problema si risolve in una frazione del tempo:<\/p>\n\n\n Se un test evidenzia un dettaglio mancante, come la serializzazione delle date nel fuso orario del server anzich\u00e9 in UTC, la soluzione non consiste nel discutere in chat. Si aggiorna la specifica inserendo il vincolo sul fuso orario e si riesegue il task. In questo modo, la conoscenza rimane formalizzata e tracciata su Git, a disposizione di chiunque debba rimettere mano al codice, anzich\u00e9 finire dimenticata nella cronologia di una chat.<\/p>\n\n\n\n Lo scollamento tra documentazione e codice sorgente rappresenta da sempre una delle cause principali di bug e regressioni. Lo Spec-Driven Development risolve questa criticit\u00e0 alla radice, trasformando la specifica in un contratto indissolubile che guida l’evoluzione del codice.<\/p>\n\n\n\n Sarebbe ingenuo presentare SDD come una soluzione priva di costi. Scrivere quindici minuti di specifica per un bug risolvibile in due minuti \u00e8 burocrazia, non ingegneria: per gli interventi elementari, il vibe coding rimane l’opzione pi\u00f9 logica. Inoltre, le specifiche sono codice a tutti gli effetti e richiedono manutenzione. Se il software evolve tramite hotfix manuali mentre il contratto rimane obsoleto, la specifica si trasforma da fonte di verit\u00e0 in fonte di bugie. \u00c8 necessario un processo costante di allineamento: non basta redigere il documento una volta e scordarsene.<\/p>\n\n\n\n Esiste poi un rischio pi\u00f9 subdolo: una specifica estremamente precisa ma errata produrr\u00e0, con rigore deterministico, il software sbagliato. Il documento di requisiti va convalidato con la stessa cura riservata al codice, poich\u00e9 non costituisce un salvacondotto automatico.<\/p>\n\n\n\n Il vero valore dello Spec-Driven Development emerge nei progetti a medio-lungo termine o sviluppati in team: in questi scenari, i vantaggi si concretizzano gi\u00e0 dopo pochi giorni, con una drastica riduzione delle iterazioni e degli imprevisti.<\/p>\n\n\n\n Si tratta di una rivoluzione culturale: il codice sorgente passa dall’essere il prodotto principale del lavoro al ruolo di semplice artefatto di compilazione.<\/p>\n\n\n\n La specifica diventa il vero asset. Oggi, saperla redigere in modo chiaro, verificabile e privo di ambiguit\u00e0 rappresenta il vero vantaggio competitivo per chi vuole governare l’AI invece di subirla.<\/p>\n\n\n\n Se anche tu hai premuto pi\u00f9 volte “Accetta” dopo milioni di domande che ti avevano ormai fuso la corteccia cerebrale e, pur di finire il lavoro e andare a casa, hai accettato una PR con la promessa “lo riguardo luned\u00ec”; se anche tu fai parte di questo gruppo, lo SDD non risolver\u00e0 tutti i tuoi problemi, ma ridurr\u00e0 il numero di caff\u00e8 che dovrai offrire ai tuoi colleghi per aver perso la gara del codice con meno errori.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":"![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/24-SpecDrivenDevelopment-articolo-2-1024x572.jpg\")
<\/figure>\n\n\n\nIl mito dello zero-to-prod<\/h2>\n\n\n\n
In quel contesto, l’AI smette di sembrare senior e comincia a somigliare a uno stagista iperattivo al suo primo giorno di caff\u00e8 gratis: quello che, preso dal panico, prova a risolvere i bug commentando linee di codice a caso pur di farti vedere che “compila”. E tu rimani l\u00ec a fissare lo schermo, chiedendoti perch\u00e9 hai accettato quella pull request.<\/p>\n\n\n\nArray.shuffle()<\/code> nativo in JavaScript, che in realt\u00e0 non esiste. Il codice generato lo invoca con tale naturalezza da spingerci ad annuire, pensare “ah, finalmente l’hanno standardizzato” e lasciar correre perch\u00e9 “tanto si tratta di un caso limite”. Poi, il sistema in produzione va gi\u00f9.<\/p>\n\n\n\nCavallo, cavaliere e imbracatura<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/24-SpecDrivenDevelopment-articolo-3-1024x572.jpg\")
<\/figure>\n\n\n\nIl prompt non deve far indovinare all'AI cosa vuoi. La specifica deve dirle esattamente cosa eseguire.<\/code><\/span><\/pre>\n\n\nScrivere un contratto che l’AI non possa fraintendere<\/h2>\n\n\n\n
Per un agente AI, invece, non basta. Senza dettagli precisi, riempir\u00e0 i vuoti con supposizioni, e le ipotesi di un modello linguistico sono statisticamente plausibili, ma non necessariamente corrette. Lo schema di specifica che adotto per ogni attivit\u00e0 complessa \u00e8 essenziale, occupa poche righe in Markdown ed \u00e8 sufficiente per eliminare gran parte delle ambiguit\u00e0:<\/p>\n\n\n## OBIETTIVO<\/span>\nCosa deve fare il sistema: una riga chiara\n\n## NON-GOAL<\/span>\nCosa NON deve fare (refresh token, OAuth, librerie non approvate...)\n\n## VINCOLI<\/span>\nStack, librerie ammesse, performance attese\n\n## OUTPUT ATTESO<\/span>\n- [ ] Criterio di successo verificabile 1<\/span>\n- [ ] Criterio di successo verificabile 2<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\nUn caso vero: da due ore di caos a mezz’ora<\/h2>\n\n\n\n
## PROBLEMA<\/span>\nAPI \/v2\/orders ritorna 500<\/span> dopo upgrade a PHP 8.1<\/span>\n\n## CONTESTO<\/span>\nErrore: [log specifico] | File: OrderController.php:45<\/span>-67<\/span>\n\n## OBIETTIVO<\/span>\nFix mantenendo la retrocompatibilit\u00e0 con il client v1\n\n## NON TOCCARE<\/span>\nsrc\/Models\/* | file di migration\n\n## VALIDAZIONE\n- [ ] La suite di test passa\n- [ ] L'API v1 continua a funzionare<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/24-SpecDrivenDevelopment-infografica-1024x572.jpg\")
<\/figure>\n\n\n\nQuando l’approccio non serve<\/h2>\n\n\n\n
Il codice \u00e8 un effetto collaterale<\/h2>\n\n\n\n