Nel teatro sempre più affollato dello sviluppo software assistito da intelligenza artificiale, la parola “produttività” viene pronunciata con la stessa leggerezza con cui negli anni Novanta si parlava di “internet per tutti”. Allora bastava aggiungere una homepage; oggi basta incollare un prompt. Il risultato, spesso, è lo stesso: molto entusiasmo, poca struttura, e un retrogusto persistente di caos non governato. In questo contesto, strumenti come Claude Code hanno creato un’illusione sofisticata: che programmare sia diventato un atto conversazionale, quasi artistico, una sorta di jam session tra umano e macchina. Il cosiddetto “vibe coding” è figlio diretto di questa narrativa. Piacevole, rapido, seducente; ma strutturalmente fragile.
La realtà operativa, quella che emerge dopo le prime settimane di entusiasmo, è meno poetica e molto più simile a un audit fallito. Il problema non è la capacità dei modelli, ma la loro memoria contestuale. Ogni interazione accumula rumore. Ogni prompt aggiunge ambiguità. Superata una certa soglia, il sistema degrada. Non collassa, sarebbe troppo onesto; semplicemente inizia a inventare. La “context rot” non è un bug, è una proprietà emergente. E come tutte le proprietà emergenti nei sistemi complessi, viene ignorata finché non diventa un problema economico.
Qui entra in scena un concetto che, per chi ha vissuto almeno una trasformazione digitale completa, suona familiare: lo Spec-Driven Development. Nulla di nuovo, in apparenza. Scrivere specifiche, definire vincoli, separare pianificazione ed esecuzione. L’industria lo conosce da decenni. Ciò che cambia oggi è il contesto: non si tratta più di disciplinare team umani, ma di incanalare modelli probabilistici che non comprendono, ma simulano comprensione. La differenza è sottile; l’impatto, devastante.
Progetti come GSD rappresentano un interessante punto di rottura. Non introducono nuove capacità nei modelli, ma ridefiniscono il modo in cui queste capacità vengono orchestrate. In altre parole, non rendono l’AI più intelligente; la rendono meno pericolosa. Che, in un contesto enterprise, è spesso un vantaggio competitivo sottovalutato.
Il cuore del sistema è brutalmente semplice: isolamento del contesto. Ogni task vive in una finestra pulita, priva di storia, priva di bias accumulati. Duecentomila token freschi, come se fosse sempre il primo giorno. Un’idea quasi banale, e proprio per questo rivoluzionaria. L’industria tecnologica ha una lunga tradizione di ignorare le soluzioni semplici finché non diventano inevitabili. La garbage collection, il versioning distribuito, i container. Tutte innovazioni che, a posteriori, sembrano ovvie. Prima, sembravano superflue.
La sequenza operativa che emerge da questo approccio è meno romantica del “parla con la macchina e lei costruirà il tuo prodotto”, ma infinitamente più efficace. Discussione, ricerca, pianificazione, esecuzione, verifica. Un ciclo che ricorda sospettosamente le migliori pratiche di ingegneria del software degli ultimi quarant’anni. La differenza è che ora ogni fase è mediata da agenti AI, orchestrati come una pipeline industriale. Non è creatività; è produzione.
Il passaggio più interessante, e forse meno compreso, è quello dalla continuità alla discontinuità. Il “vibe coding” si basa su una conversazione continua, dove ogni stato dipende dal precedente. È intuitivo, umano, ma fragile. Lo Spec-Driven Development, invece, frammenta. Spezza il flusso in unità atomiche. Ogni task è indipendente, verificabile, sostituibile. In termini economici, si passa da un sistema monolitico a uno modulare. In termini cognitivi, si passa dalla memoria alla struttura.
Questa distinzione ha implicazioni profonde. I modelli linguistici, per quanto sofisticati, non sono progettati per gestire dipendenze lunghe e complesse. La loro forza è nella località, non nella persistenza. Pretendere il contrario è come chiedere a un motore di ricerca di comportarsi come un database transazionale. Funziona, fino a quando non smette di funzionare. E quando smette, il costo di debugging esplode.
L’adozione di workflow come quello di GSD introduce una disciplina che molti team avevano progressivamente abbandonato. Non per ignoranza, ma per convenienza. Scrivere specifiche è noioso. Validare ogni step è lento. Separare pianificazione ed esecuzione richiede maturità organizzativa. L’AI sembrava offrire una scorciatoia. Non lo ha fatto. Ha semplicemente reso più visibili le conseguenze dell’assenza di struttura.
Una frase che circola nei corridoi delle aziende più avanzate suona più o meno così: “l’AI amplifica il tuo sistema operativo organizzativo”. Se il sistema è solido, l’output migliora. Se è fragile, collassa più velocemente. In questo senso, GSD non è uno strumento di sviluppo; è uno specchio. Riflette la qualità del processo sottostante, senza pietà.
Interessante osservare come questa evoluzione stia riportando in auge concetti che molti consideravano superati. Il design document, la definizione dei requisiti, la validazione incrementale. Elementi che, nel fervore agile degli ultimi anni, erano stati ridotti a rituali opzionali. L’ironia è evidente: per sfruttare modelli che rappresentano il culmine della modernità tecnologica, stiamo riscoprendo pratiche che risalgono agli anni Settanta.
Non si tratta di un ritorno al passato, ma di una convergenza. L’AI costringe a formalizzare ciò che prima poteva rimanere implicito. Costringe a esplicitare le intenzioni. Costringe, in ultima analisi, a pensare. E qui emerge una verità scomoda: gran parte del valore nello sviluppo software non è nella scrittura del codice, ma nella definizione del problema. Il “vibe coding” elimina questa fase. Lo Spec-Driven Development la rende centrale.
Dal punto di vista strategico, il cambiamento è significativo. Le aziende che adotteranno questi modelli operativi non saranno necessariamente quelle con i modelli più avanzati, ma quelle con i processi più disciplinati. La competizione si sposta dall’algoritmo all’orchestrazione. Dalla potenza computazionale alla qualità del workflow. Una dinamica che ricorda da vicino l’evoluzione del cloud computing: all’inizio contava l’infrastruttura, poi ha iniziato a contare l’architettura.
Il tema della “context rot” merita una riflessione più ampia. Non è solo un problema tecnico; è una metafora organizzativa. Anche le aziende accumulano contesto. Processi legacy, decisioni passate, documentazione obsoleta. A un certo punto, la complessità supera la capacità di gestione. Il sistema non fallisce immediatamente; degrada. Le decisioni diventano incoerenti, i progetti rallentano, il debugging organizzativo diventa permanente. L’isolamento del contesto, in questo senso, è una lezione che va oltre l’AI.
Si potrebbe obiettare che tutto questo introduce rigidità. Che limita la creatività. Che trasforma lo sviluppo in una catena di montaggio. È un’obiezione legittima, ma parziale. La creatività non scompare; si sposta. Non è più nell’improvvisazione continua, ma nella progettazione del sistema. Non è nel singolo prompt, ma nell’architettura del workflow. Una differenza sottile, ma decisiva.
La Silicon Valley, con la sua consueta inclinazione per l’iperbole, continuerà a vendere l’idea di un futuro in cui basta descrivere un’applicazione a parole per vederla materializzarsi. È una narrativa potente, e come tutte le narrative potenti contiene una parte di verità. Il problema è che ignora il costo della complessità. Ignora il fatto che ogni sistema reale vive in un ecosistema di vincoli, dipendenze e requisiti non funzionali.
In questo scenario, approcci come quello di GSD non sono sexy. Non producono demo spettacolari. Non generano video virali. Ma funzionano. E nel lungo periodo, come insegna la storia dell’ingegneria, ciò che funziona tende a vincere su ciò che impressiona.
Una nota quasi filosofica emerge osservando questa evoluzione. L’intelligenza artificiale, lungi dal sostituire il rigore umano, lo rende indispensabile. Più i modelli diventano potenti, più diventa evidente la necessità di incanalarli. È un paradosso solo apparente. Ogni tecnologia che amplifica le capacità umane amplifica anche le conseguenze degli errori umani.
In definitiva, il passaggio dal “vibe coding” allo Spec-Driven Development non è solo un cambiamento tecnico. È un cambio di mentalità. Richiede di abbandonare l’illusione del controllo totale e di accettare la necessità di strutture intermedie. Richiede di trattare l’AI non come un collaboratore creativo, ma come un sistema da orchestrare.
Una frase, volutamente provocatoria, sintetizza il punto: “l’AI non elimina l’ingegneria del software; elimina le scuse per farla male”. Chi continuerà a ignorare questa realtà produrrà codice, certo. Molto codice. Ma poco software. E ancora meno valore.
Repoitory: https://github.com/gsd-build/get-shit-done