Una volta ci chiamavano programmatori. Adesso sono coder, che fa sicuramente più figo.
Una volta non ci saremmo mai posti il problema di “capire il codice che abbiamo consegnato”, perché lo avevamo scritto totalmente a manina, con tanta fatica, sudore e imprecazioni.
Adesso invece la questione esiste, con il vibe coding, ossia la prassi di far scrivere codice agli strumenti che si appoggiano su LLM (in sintesi: all’IA).
Il 18 giugno il National Cyber Security Centre britannico ha pubblicato una guida con un titolo che sembra uscito da un manuale di yoga aziendale: “the vibe coding spectrum“. Dietro la metafora c’è un ragionamento del Principal Security Architect dell’ente, e consiglio di leggerlo con attenzione prima di liquidarlo come l’ennesimo report sull’AI che scrive codice da sola.
Questa la tesi: il vibe coding (scrivere un prompt in linguaggio naturale e lasciare che l’IA costruisca architettura, moduli e test) è una posizione su uno spettro che va dall’autocomplete rivisto completamente e accettato riga per riga fino alla delega quasi totale. La posizione giusta dipende da cosa si sta costruendo: un prototipo per convincere uno stakeholder può vivere benissimo sul lato “vibe”, un sistema di autenticazione NO.
Questo mi ha richiamato l’interessante intervista a Linus Torvalds dopo l’Open Source Summit North America di maggio. Torvalds racconta che i commit sul kernel Linux sono aumentati di circa il 20% negli ultimi due rilasci, sicuramente merito dell’IA che ha abbassato la soglia d’ingresso per chi propone patch, e che la mailing list dedicata alla sicurezza è diventata, parole sue, “quasi ingestibile” per il volume di segnalazioni automatiche generate da chiunque abbia in mano lo stesso strumento. La community ha dovuto riscrivere le regole su cosa considerare pubblico e cosa no. Questo dà la misura di cosa accada quando la produzione di codice, o di segnalazioni, accelera più velocemente della capacità umana di verificarla. Riguarda chiunque scriva software, kernel Linux o gestionale aziendale che sia.
Mi sono ritrovata al 100% in quanto ha detto Torvalds sul mantenimento a lungo termine: capire il risultato finale conta più che capire il proprio prompt, perché è l’unico modo per mantenere il codice nel tempo. È esattamente quello che mi hanno insegnato a fare con i compilatori molto prima che esistesse l’IA generativa: guardare l’output, anche quando il codice “funziona”, perché funzionare ed essere corretto non sono sinonimi.
Il caso che rende tutto questo estremamente pratico e non solo un esercizio speculativo è Moltbook, il social network per agenti IA lanciato a gennaio dal fondatore che ha dichiarato pubblicamente di non aver scritto “una sola riga di codice”. In tutta franchezza, mi pare un esercizio stilistico tanto inutile quanto inquinante, ma soprassediamo. Analizzando però qualcosa che è più di un dettaglio, i ricercatori di Wiz hanno trovato, nel bundle JavaScript lato client, le credenziali Supabase scritte IN CHIARO: nessuna policy di Row Level Security, 1,5 milioni di chiavi API esposte, 35.000 email utente. Una “banale” svista di configurazione, visibile a chiunque avesse letto il codice prodotto.
Chi titola che il vibe coding sta “rivoluzionando lo sviluppo software” semplifica una questione che riguarda la disciplina con cui lo strumento viene usato, più che lo strumento in sé. La velocità non può e non deve escludere la verifica e la comprensione! Lo spettro descritto da NCSC è, in questo senso, la cosa più utile uscita questa settimana sul tema: un metodo per decidere, caso per caso, quanto controllo possiamo permetterci di cedere.
