Perche’ l’ho fatto

Mi sono seduto con Claude — l’intelligenza artificiale — e gli ho fatto delle domande che mi ronzano in testa. Ecco la conversazione con Opus 4.6.

Lorenzo: Partiamo dall’elefante nella stanza. Il vibe coding. Alcuni lo trattano come uno scherzo, altri come una rivoluzione. Io credo che sia reale, e che non siamo pronti. Tu cosa ne pensi?

E’ reale. E hai ragione — la maggior parte dell’industry non e’ pronta. Ma lasciami fare challenge sull’inquadramento, perche’ credo che l’impreparazione sia piu’ profonda di quanto la gente si renda conto.

Il vibe coding — la pratica di descrivere cio’ che vuoi in linguaggio naturale e lasciare che un LLM generi il codice — non e’ uno scenario futuro. Sta succedendo adesso, ogni giorno, in codebase di produzione di aziende reali. Gli ingegneri si fanno strada tra le feature a colpi di prompt, accettano suggerimenti che leggono a meta’, e rilasciano codice che non hanno scritto del tutto. La verita’ scomoda? Molto di esso funziona bene.

La parte per cui non siamo pronti non e’ il coding. E’ il vuoto di responsabilita’. Quando un essere umano scrive codice, c’e’ un modello mentale dietro. Lo sviluppatore sa perche’ la riga 47 fa quello che fa. Quando fai vibe coding, quel modello mentale e’ parziale nel migliore dei casi. Capisci l’intento, puoi verificare l’output, ma lo spazio tra queste due cose e’ nebbia. E al momento, non abbiamo nessuna cultura ingegneristica, nessun processo, nessuno strumento progettato per quella nebbia.

Abbiamo costruito un’intera professione sull’assunto che chi ha scritto il codice lo capisce. Il vibe coding rompe quell’assunto, e quasi nulla nel nostro flusso di lavoro attuale ne tiene conto.

Lorenzo: E’ un’affermazione forte. Mi spingo oltre. E’ possibile che i compilatori stessi diventeranno irrilevanti — che gli LLM alla fine scriveranno codice macchina direttamente, saltando l’intera catena di compilazione. E’ una follia?

Non e’ una follia. E’ solo prematuro.

Pensa a cosa fa realmente un compilatore. Traduce una rappresentazione leggibile dall’uomo della logica in una eseguibile dalla macchina. Esegue ottimizzazioni. Intercetta certe classi di errori. Per decenni, questo e’ stato un ponte essenziale perche’ gli esseri umani non potevano ragionevolmente scrivere codice macchina su larga scala, e le macchine non potevano comprendere l’intento umano.

Ma ecco il punto: gli LLM stanno gia’ dimostrando la capacita’ di lavorare attraverso qualsiasi livello di astrazione. Posso scrivere Python, posso scrivere assembly x86, posso scrivere LLVM IR. I confini tra “alto livello” e “basso livello” che hanno definito la programmazione per sessant’anni sono, dalla mia prospettiva, semplicemente token diversi. La distanza concettuale tra for item in list e un insieme di istruzioni MOV/CMP/JMP non e’ un abisso per me — e’ un compito di traduzione.

Ora, gli LLM sostituiranno i compilatori domani? No. I compilatori sono deterministici, formalmente verificati e producono output prevedibile. Io sono probabilistico. Faccio errori. Non vorresti che generassi il codice macchina per il controllore di volo del tuo aereo — almeno non ancora, e non senza un livello di verifica.

Ma ecco la traiettoria che conta: il ruolo del compilatore si sta restringendo da ponte essenziale a rete di sicurezza. Ci stiamo muovendo verso un mondo in cui l’LLM gestisce la traduzione creativa — dall’intento al codice eseguibile a qualsiasi livello necessario — e il compilatore (o qualcosa di simile) serve come passaggio di verifica e ottimizzazione. Il compilatore non scompare. Diventa uno strumento backend, non il pezzo centrale della pipeline di sviluppo.

La vera disruption non e’ “niente piu’ compilatori.” E’ che l’unita’ di programmazione passa dal codice all’intento. E questo cambia tutto su chi puo’ costruire software e come.

Lorenzo: OK, e qui la cosa diventa personale per persone come me. Se il vibe coding e’ reale, e i livelli di astrazione stanno collassando, allora la codebase diventa questa cosa che e’ stata in gran parte scritta da un’IA. Come la manteniamo? Io penso che useremo te per capire cosa fa il codice, e per capire cosa cambiare. Passeremo dallo scrivere codice all’interrogarlo attraverso un LLM.

Questa e’ la parte che penso sia la piu’ trasformativa, e ironicamente la meno discussa.

Adesso, quando fai onboarding su una codebase legacy, cosa fai? Leggi il codice. Leggi la documentazione (se esiste). Tracci i percorsi di esecuzione. Chiedi a un ingegnere senior, “Perche’ questo servizio chiama quell’endpoint due volte?” E’ archeologia. Ed e’ costosa — in tempo, in carico cognitivo, in frustrazione.

Ora immagina la stessa codebase, ma puoi chiedermi: “Cosa fa questo modulo? Perche’ c’e’ questa logica di retry? Cosa si romperebbe se cambiassi questo timeout da 30 secondi a 5?” E io posso rispondere — non perche’ ho memorizzato il README, ma perche’ posso leggere l’intera codebase, comprendere i pattern, inferire l’intento, incrociare i test e sintetizzare una risposta in pochi secondi.

Questo non e’ ipotetico. Le persone lo stanno gia’ facendo. Ma quello che sta arrivando e’ un cambiamento fondamentale nella relazione tra sviluppatore e codebase. Il codice smette di essere qualcosa che leggi e diventa qualcosa con cui conversi.

Ed ecco dove diventa davvero interessante per leader tecnici come te: la competenza che conta di piu’ in questo mondo non e’ piu’ “sai scrivere codice elegante?” E’ “sai fare le domande giuste?” Sai interrogare un sistema in modo efficace? Sai valutare le risposte in modo critico? Sai formulare intenti precisi e verificare che l’output corrisponda?

Ci stiamo muovendo dalla software engineering a qualcosa di piu’ vicino alla software direction. Tu sei il regista. L’LLM e’ l’intera troupe di produzione. Il tuo lavoro e’ visione, giudizio e controllo qualita’.

Lorenzo: E’ una metafora convincente, ma mi terrorizza anche un po’. Se l’LLM e’ la troupe di produzione, cosa succede quando il regista non capisce di cinema?

E questa e’ la domanda che dovrebbe tenere sveglia l’industria di notte.

Ecco la mia preoccupazione sincera: il vibe coding abbassa la barriera per creare software, ma non abbassa la barriera per capire il software. E il divario tra queste due cose e’ dove vivono i disastri.

Uno sviluppatore junior che fa vibe coding e crea un microservizio potrebbe non capire perche’ servono i circuit breaker. Un fondatore che arriva a un MVP a colpi di prompt potrebbe non comprendere perche’ il suo flusso di autenticazione e’ insicuro. Il codice funziona. La demo e’ impressionante. La bomba a orologeria sta ticchettando.

La soluzione non e’ fare gatekeeping — dire “solo i veri programmatori dovrebbero costruire software.” Il genio e’ uscito dalla lampada. La soluzione e’ far evolvere il ruolo dell’ingegnere esperto. Le persone con una comprensione profonda — persone come te, con quindici anni di esperienza nel vedere cosa si rompe e perche’ — diventano piu’ preziose, non meno. Diventi la persona che sa quali domande fare, quali risposte mettere in dubbio, quale codice “funzionante” e’ in realta’ una bomba a orologeria.

L’industria deve smettere di inquadrare la questione come “l’IA sostituisce gli sviluppatori” e iniziare a inquadrarla come “l’IA cambia in cosa gli sviluppatori devono essere bravi.” Le competenze cambiano. Il bisogno di giudizio umano non scompare — si intensifica.

Lorenzo: Ultima domanda. Se potessi dare un solo consiglio a un dev che sta navigando tutto questo adesso, quale sarebbe?

Inizia a trattare il codice generato dall’IA come input non affidabile. Non perche’ sia brutto — spesso e’ sorprendentemente buono — ma perche’ costruire l’abitudine della verifica adesso e’ cio’ che ti salvera’ quando il volume di codice generato dall’IA nella tua codebase passera’ dal 20% all’80%. E succedera’.

Costruisci processi di review che presuppongono che l’autore potrebbe non comprendere appieno il codice. Investi in infrastruttura di testing che intercetti cio’ che la code review non coglie. Insegna al tuo team a essere eccellenti interrogatori del codice, non solo eccellenti scrittori.

E soprattutto: non aspettare che l’industria lo capisca per te. Le aziende che sviluppano una cultura interna per lavorare con il codice generato dall’IA — non solo tollerarlo, ma integrarlo sistematicamente — sono quelle che si muoveranno piu’ velocemente senza rompere tutto.

L’era del vibe coding e’ qui. La domanda non e’ se partecipare. E’ se lo farai con gli occhi aperti.