Il caso Grenbaud non è un incidente. È un segnale.
Nel marzo 2026, Grenbaud lancia in diretta un social network costruito quasi interamente con l’intelligenza artificiale. Costa circa 40 euro, viene sviluppato in pochi giorni e nel giro di poche ore è già online, con utenti reali, dati reali e interazioni reali. Poi succede quello che succede sempre quando qualcosa “sembra funzionare” ma non è stato davvero costruito per farlo: basta davvero poco per prendere il controllo della piattaforma.
Nessun attacco sofisticato, nessun hacker geniale, nessuna tecnica avanzata. Solo un sistema che non sapeva difendersi.
Il punto, però, non è quello che è successo. È perché è successo. Perché oggi costruire software è diventato incredibilmente facile, ma capire cosa stai costruendo non lo è affatto. Ed è proprio qui che sempre più spesso nasce il problema: quando velocità e semplicità vengono scambiate per controllo.
Cosa è successo davvero: la timeline di Baudr
Il 14 marzo 2026, Grenbaud lancia Baudr in diretta su Twitch davanti a migliaia di spettatori. L’idea è semplice: un social per connettere la sua community tramite profili, interessi e messaggi privati, presentato come un esperimento costruito quasi interamente con l’AI, senza un team tecnico strutturato e con un investimento minimo. Un caso che è stato analizzato anche da diversi approfondimenti tecnici sul tema (analisi del caso Baudr).
L’hype è immediato e gli utenti iniziano a registrarsi, creare profili e usare la piattaforma come se fosse già un prodotto reale. Ed è proprio qui che avviene il passaggio critico: da esperimento a produzione, senza che l’infrastruttura sia davvero pronta.
Nel giro di poche ore emerge una pagina accessibile pubblicamente: /admin. Non serve alcun exploit o tecnica avanzata, basta digitare un URL, causando un data breach che ha esposto i dati di migliaia di utenti, come documentato nelle prime analisi tecniche. Da lì, tutto accelera. Chiunque può accedere a funzionalità amministrative, cancellare account, leggere dati e inviare messaggi impersonando altri utenti. Questo perché i controlli erano solo frontend e quindi facilmente aggirabili da chiunque avesse un minimo di conoscenza per aprire i DevTools del browser. Parliamo di una delle vulnerabiltà più comuni nelle applicazioni web quando la sicurezza non viene gestita lato server.
Migliaia di profili vengono compromessi, incluso quello dello stesso Grenbaud.
Gli utenti iniziano a ricevere messaggi mai scritti e a vedere dati modificati o esposti, mentre la piattaforma resta online e le patch arrivano troppo tardi. Nei giorni successivi il sito viene aggiornato più volte e infine messo offline.
L'informazione importante da portarsi a casa è che non si è trattato di un attacco brillante ma che stiamo parlando di un prodotto lanciato senza le basi minime per reggere anche il test più semplice.
Non è stato un attacco sofisticato.
È stato un errore di base: un sistema messo online senza controlli lato server.
Il problema non è l’AI. È come la usi.
A questo punto è facile cadere nella lettura sbagliata e dare la colpa all’intelligenza artificiale. Dire che genera codice insicuro, che non è pronta, che non si può usare per costruire prodotti reali. Ma non è questo il punto. Sono convinto infatti, anche parlando contro i miei interessi da sviluppatore, che l’AI ha fatto qualcosa di straordinario: ha abbassato drasticamente la barriera all’ingresso. Oggi puoi passare da un’idea a un prototipo funzionante in ore, scrivere codice, costruire interfacce e collegare servizi senza avere anni di esperienza alle spalle. Ed è proprio questo che la rende così potente.
Il problema risiede nell’illusione che crea: l’illusione che “se gira, allora è pronto”.
Ma un prodotto reale non è solo codice che gira. È architettura, gestione dei permessi, controllo degli accessi, separazione tra frontend e backend, gestione dei dati, gestione degli errori, sicurezza. Tutte cose che non emergono finché non è troppo tardi, ma che determinano se un prodotto regge oppure no.
Nel caso di Baudr, il problema non è stato usare l’AI per costruire velocemente. È stato portare quel codice in produzione senza passare da quella fase invisibile ma fondamentale che è l’ingegnerizzazione. Perché tra “funziona sul mio browser” e “può essere usato da migliaia di persone” c’è un abisso.
Il vibe coding è uno strumento potentissimo per esplorare, prototipare e validare idee. Ma quando lo usi per costruire sistemi che gestiscono utenti e dati reali senza capire cosa sta succedendo sotto, stai delegando decisioni critiche a qualcosa che non è progettato per prendersi quella responsabilità. L’AI non commette errori: fa esattamente quello che le viene chiesto.
Il problema è che nessuno ha controllato davvero il risultato.
Guardare Baudr solo come un problema tecnico significa perdere il punto. La vulnerabilità è il sintomo, non la causa. L’errore è a monte.
Il primo errore è trattare un prodotto reale come un side project. Baudr era pubblico, con utenti e dati personali. Non era più un esperimento. Nel momento in cui qualcuno si registra, inserisce informazioni e interagisce con la piattaforma, non stai più “provando qualcosa” ma hai delle responsabilità verso gli utenti - in questo caso, addirittura con il tuo pubblico di sostenitori.
Il secondo errore è confondere MVP con prodotto fragile. Negli ultimi anni la parola MVP è stata semplificata fino a diventare quasi un alibi: lanciamo qualcosa di incompleto, tanto è solo una prima versione. Ma un MVP non è un prodotto rotto. È essenziale, ma deve essere solido nelle sue fondamenta. Autenticazione, gestione dei permessi e protezione dei dati non sono optional, ma fanno parte del pacchetto.
Il terzo errore è ignorare competenze critiche. Non serve un team enorme per costruire un MVP, ma ci sono aree che non puoi saltare: backend, sicurezza, gestione degli accessi, e in molti casi anche gli aspetti legali legati ai dati. Non vederle non le rende meno importanti, le rende solo più pericolose.
E questo non riguarda solo Baudr. Sempre più founder stanno costruendo prodotti con strumenti potentissimi, arrivando velocemente a qualcosa che “funziona”, ma saltando completamente la fase in cui capiscono se quel qualcosa è davvero pronto per essere usato da altri. Il problema non è la velocità. Il problema è non sapere cosa stai sacrificando mentre la insegui.
Il mito pericoloso: “gli sviluppatori non servono più”
Negli ultimi mesi sta emergendo una narrativa sempre più diffusa: con l’AI chiunque può costruire tutto. Non servono più sviluppatori, non servono più competenze profonde, basta avere un’idea e saper scrivere il prompt giusto.
È una narrativa affascinante, perché contiene una parte di verità. Oggi puoi davvero costruire molto più velocemente rispetto a prima, mettere online un prodotto, collegare servizi, creare interfacce e logiche senza partire da zero.
Il problema è quello che viene omesso.
Costruire qualcosa non significa capirlo. E soprattutto non significa saperlo gestire quando qualcosa va storto. L’AI ti aiuta a produrre output, ma non ti trasferisce automaticamente il modello mentale necessario per progettare sistemi complessi, anticipare i rischi e capire dove possono rompersi le cose. Ed è qui che nasce l’equivoco: si confonde la capacità di generare codice con la capacità di fare ingegneria.
Nel caso Baudr, lo stack era moderno e apparentemente funzionante. Quello che mancava era la comprensione necessaria per renderlo affidabile. Per far sì che ci fossero fondamenta di cemento e non di sabbia.
Dire che “gli sviluppatori non servono più” è come dire che, siccome costruire è diventato più facile, allora non servono più gli ingegneri. Puoi anche costruire qualcosa velocemente, ma non hai alcuna garanzia che regga quando arriva il primo stress reale.
L’AI non sostituisce i professionisti. Li amplifica. E rende ancora più evidente la differenza tra chi sa cosa sta facendo e chi no.
Vibe coding: quando ha senso (e quando no)
A questo punto è importante chiarire una cosa: il vibe coding non è il problema. Anzi, è uno degli strumenti più interessanti che abbiamo oggi. Ti permette di esplorare idee rapidamente, testare interfacce e mettere insieme prototipi in tempi che fino a poco tempo fa erano impensabili. Per un founder, soprattutto nelle fasi iniziali, è una leva enorme.
Se stai validando un’idea, costruendo una landing o testando un flusso, usare l’AI per generare codice è spesso la scelta giusta. Ti fa risparmiare tempo, riduce i costi e ti porta velocemente al punto che conta davvero: capire se quello che stai costruendo ha senso.
Il problema nasce quando cambia la scala. Quando passi da prototipo a prodotto, da test interno a utenti reali, da simulazione a dati veri. In quel momento, le regole cambiano completamente, anche se dall’esterno sembra lo stesso identico prodotto.
È qui che molti founder sbagliano. Perché quello che vedono è qualcosa che funziona, mentre quello che non vedono è tutto ciò che manca sotto: controlli lato server, gestione degli accessi, protezione dei dati, gestione degli errori, logiche di sicurezza. Tutte cose che non emergono finché nessuno prova davvero a rompere il sistema.
Il vibe coding funziona benissimo finché stai costruendo qualcosa che può permettersi di rompersi. Ma nel momento in cui quello che stai costruendo coinvolge altre persone, quel margine sparisce. Non stai più sperimentando da solo, stai prendendo decisioni che impattano altri.
Per questo la distinzione non è tra “AI sì” o “AI no”. La distinzione è tra contesti in cui puoi permetterti di essere approssimativo e contesti in cui non puoi. Capire quando avviene questo passaggio è probabilmente una delle competenze più importanti oggi.
L’AI non elimina la complessità.
La nasconde. E questa è la differenza tra prototipo e prodotto.
Cosa imparare davvero se stai costruendo un MVP oggi
Il caso Baudr è estremo, ma il pattern è molto più comune di quanto sembri. Se oggi stai costruendo un MVP, soprattutto usando AI o strumenti no-code, il punto non è rallentare o complicarti la vita, ma capire dove non puoi permetterti di semplificare.
La prima cosa da chiarire è semplice: se ci sono utenti, non è più un gioco. Nel momento in cui qualcuno si registra, inserisce dati e interagisce con il tuo prodotto, stai gestendo responsabilità reali. Non importa se lo chiami beta, esperimento o MVP, per chi lo usa è già un prodotto. Applicazioni simili senza controlli adeguati possono portare a diversi problemi, anche legali, come evidenziato da diverse analisi sul tema.
La seconda è capire che alcune cose non sono “feature”, ma fondamenta. Autenticazione, gestione dei permessi, protezione dei dati, controlli lato server: non sono miglioramenti da aggiungere dopo, sono ciò che permette al resto di esistere senza rompersi. Puoi avere meno funzionalità, ma quelle devono essere solide.
La terza è essere onesti su quello che non sai. L’AI ti permette di arrivare molto lontano da solo, ma non ti dice quando stai entrando in territori che richiedono competenze specifiche. Ed è proprio lì che serve fermarsi un attimo e capire se ha senso continuare da soli o se è il momento di coinvolgere qualcuno che sa cosa sta guardando.
Infine, forse la cosa più importante: velocità e qualità non sono in contraddizione, ma nemmeno indipendenti. Puoi andare veloce, ma ogni scelta ha un costo. Se non lo vedi subito, non significa che non esista ma solo che lo pagherai dopo.
Costruire oggi è facile. Costruire bene è un’altra cosa.
Il caso Grenbaud non è la storia di un errore individuale. È la fotografia di un cambiamento molto più ampio. Oggi chiunque può passare da un’idea a qualcosa di funzionante in pochissimo tempo, e questo è senza dubbio un enorme passo avanti.
Ma questa accessibilità ha un effetto collaterale: rende invisibile la complessità.
Più è facile iniziare, più è facile sottovalutare tutto quello che viene dopo. Più è veloce arrivare a qualcosa che funziona, più è facile confondere quel “funziona” con “è pronto”. E più gli strumenti diventano potenti, più diventano pericolosi se usati senza consapevolezza.
Non c’è nulla di sbagliato nel voler costruire da soli, nel usare l’AI, nel fare esperimenti o nel muoversi velocemente. Anzi, è esattamente quello che oggi permette a molte idee di esistere. Il punto è sapere dove finisce questa fase.
Perché arriva sempre un momento in cui smetti di esplorare e inizi a costruire davvero. Un momento in cui il tuo prodotto smette di essere solo tuo e inizia a coinvolgere altre persone. E in quel momento cambiano le regole, anche se dall’esterno sembra tutto uguale. L’AI ti permette di andare più veloce. I professionisti servono a evitare che tu cada quando inizi a correre davvero.
E la differenza tra le due cose, oggi, è tutto.