Vibe coding e AI: il software funzionante non è sempre software governabile

Uno dei cambiamenti più profondi portati dall'AI non riguarda soltanto la velocità con cui gli sviluppatori scrivono codice. Riguarda chi può arrivare a costruire qualcosa che funziona.

Oggi una persona con buona visione di prodotto, capacità di project management, sensibilità architetturale, competenza infrastrutturale o esperienza operativa può usare un assistente AI per trasformare un'idea in una piattaforma reale. Magari non sa scrivere codice nel senso classico. Magari non conosce ogni dettaglio di un framework. Ma sa descrivere un flusso, ragionare sui requisiti, chiedere iterazioni, valutare un'interfaccia, collegare API, immaginare un prodotto.

E con gli strumenti giusti può ottenere qualcosa che non solo si avvia, ma funziona anche molto bene. Almeno in apparenza.

Funzionante non significa production ready

Nel software abbiamo sempre avuto questa tensione. Una cosa può funzionare sul laptop, in staging o durante una demo commerciale, ma non essere ancora pronta per utenti reali, dati reali, traffico reale, incidenti reali e responsabilità reali.

L'AI amplifica questa tensione perché abbassa drasticamente il costo di arrivare alla prima versione funzionante. In poche ore si può generare un backend, una dashboard, un'integrazione, una pipeline, un sistema di autenticazione, una landing, un workflow di pagamento o un prototipo SaaS. Questo è potentissimo. Ma rende anche più facile saltare tutte le domande scomode.

Dove sono i test? Come vengono gestiti i segreti? Cosa succede se un servizio esterno non risponde? Come si fa rollback? Chi monitora gli errori? Il logging contiene dati sensibili? Le dipendenze sono aggiornate? Il modello dei permessi regge davvero? Il database può essere migrato senza perdere dati? Il sistema è comprensibile da una persona diversa da quella che lo ha generato?

Queste domande non spariscono perché il codice è stato scritto da un modello. Anzi, diventano più importanti, perché spesso chi ha guidato la generazione non conosce tutte le fragilità che un senior engineer imparerebbe a cercare.

Il nuovo creatore di software

La figura interessante non è solo lo sviluppatore che usa AI per essere più veloce. È anche il product manager tecnico, il founder, il designer con visione sistemica, il consulente infrastrutturale, l'architect che sa cosa vuole ottenere ma non vuole scrivere ogni riga di codice.

Queste persone possono avere una qualità preziosa: vedono il problema. Capiscono il flusso utente, il contesto aziendale, il valore del prodotto, i vincoli organizzativi, l'impatto operativo. Fino a ieri erano costrette a tradurre tutto in specifiche per un team di sviluppo. Oggi possono entrare direttamente nel ciclo di costruzione.

Questo è un cambiamento enorme. Può liberare creatività, ridurre attrito, permettere a più persone di prototipare soluzioni e portare sul mercato idee che prima sarebbero rimaste ferme. Sarebbe miope leggerlo solo come rischio.

Ma proprio perché è potente, richiede una nuova distinzione: saper guidare l'AI a produrre software non equivale automaticamente a saper governare quel software nel tempo.

Il vibe coding sta cambiando anche i senior

Il problema non riguarda solo chi non sa programmare. Anche molti sviluppatori esperti stanno cambiando il modo in cui lavorano. Con il vibe coding si descrive l'intenzione, si lascia al modello produrre blocchi significativi di codice, si revisiona a campione, si prova, si corregge, si rilancia.

In molti casi funziona benissimo. Un senior con buon giudizio può usare l'AI per accelerare refactoring, boilerplate, test, debugging, documentazione, migrazioni e analisi di codice legacy. Ma esiste una deriva sottile: più il modello sembra affidabile, meno controlliamo davvero. Più il codice "passa", più siamo tentati di fidarci.

La competenza senior rischia di spostarsi dal sapere scrivere codice al sapere riconoscere quando il codice generato è pericoloso. È un passaggio naturale, ma non gratuito. Se la review diventa superficiale, se i test sono generati dallo stesso modello che ha scritto il codice, se l'architettura cresce per inerzia, allora non stiamo accelerando ingegneria. Stiamo accelerando debito tecnico.

Il futuro del software potrebbe non essere fatto da persone che non sanno costruire. Potrebbe essere fatto da persone che costruiscono troppo facilmente e si accorgono troppo tardi di ciò che hanno costruito.

E se l'AI non ci fosse?

C'è poi un altro punto che l'industria tende a rimuovere: stiamo iniziando a costruire workflow assumendo che l'AI sia sempre disponibile, sempre accessibile, sempre economica, sempre allineata alle stesse policy e sempre abbastanza capace da mantenerci il sistema.

Ma cosa succede se il servizio non è disponibile per alcune ore? O per alcuni giorni? Cosa succede se un provider cambia modello, policy, pricing o limiti di utilizzo? Cosa succede se un account viene bloccato, se una funzionalità viene ritirata, se un modello viene reso meno permissivo, se una decisione commerciale o normativa cambia improvvisamente le condizioni?

Abbiamo già visto segnali di questa fragilità nell'ecosistema AI: modelli che cambiano comportamento, accessi che vengono limitati, utenti che si trovano improvvisamente senza lo strumento su cui avevano costruito parte del proprio workflow. Il caso di Claude Fable 5, discusso recentemente nell'industry, è un esempio di quanto un cambiamento di disponibilità o policy possa spostare abitudini e dipendenze operative.

Se un team non sa più leggere criticamente il proprio codice senza AI, se non sa più fare debugging senza assistente, se non sa più spiegare l'architettura che ha generato, allora non ha aumentato la propria autonomia. Ha soltanto spostato la dipendenza.

L'analogia con internet

In fondo abbiamo già vissuto una dinamica simile con internet. All'inizio era un'estensione. Poi è diventata infrastruttura invisibile. Oggi moltissimi oggetti quotidiani danno per scontato che la rete sia disponibile: smart home, sistemi di sicurezza, videocamere, termostati, serrature, assistenti vocali, luci, elettrodomestici.

In molti setup, se internet cade, la casa diventa meno intelligente o smette proprio di funzionare come previsto. Eppure continuiamo a comprare device che dipendono dal cloud. A volte eliminiamo perfino interruttori fisici, perché "ormai è tutto smart". Ci abituiamo così in fretta alla comodità che il piano B comincia a sembrare un residuo del passato.

La domanda è se stiamo facendo la stessa cosa con l'AI. Prima l'elettricità. Poi internet. Ora l'intelligenza assistita. Ogni nuova infrastruttura diventa così naturale che smettiamo di vederla. E quando smettiamo di vederla, smettiamo anche di chiederci cosa succede se manca.

Il piano B come forma di maturità

Nel mondo infrastrutturale, il piano B non è pessimismo. È ingegneria. Backup, disaster recovery, multi-region, rollback, procedure manuali, runbook, monitoraggio, test di ripristino: tutto nasce dalla consapevolezza che i sistemi falliscono.

Con l'AI dovremmo ragionare allo stesso modo. Non basta chiedersi "quanto mi fa risparmiare oggi?". Bisogna chiedersi anche "cosa succede se domani non c'è?". Possiamo mantenere il prodotto? Possiamo fare incident response? Possiamo correggere una vulnerabilità? Possiamo migrare? Possiamo spiegare a un cliente perché è successo qualcosa?

Una piattaforma generata con AI dovrebbe avere documentazione umana, test indipendenti, ownership chiara, architettura comprensibile, logging, sicurezza, gestione delle dipendenze e procedure operative. Non perché l'AI non sia utile. Ma perché proprio l'utilità dell'AI rischia di farci dimenticare la disciplina.

Tre anni per capire davvero

Probabilmente non possiamo rispondere oggi alla domanda più grande. Serviranno almeno alcuni anni. Forse tre, forse di più. Il tempo necessario perché sviluppatori, founder, aziende e intera industry si abituino abbastanza all'AI da considerarla parte naturale del lavoro quotidiano.

Solo allora vedremo gli effetti reali. Vedremo quanti prodotti nati con AI saranno ancora mantenibili. Quanti avranno retto crescita, incidenti, audit, cambi di provider, cambi di team. Vedremo se la generazione assistita avrà creato più software sostenibile o più software fragile ma convincente.

Oggi siamo ancora nella fase dell'entusiasmo produttivo. Le cose si costruiscono. Le demo funzionano. I founder consegnano più velocemente. I senior accelerano. Ma la qualità del software non si misura solo nel momento in cui nasce. Si misura quando deve sopravvivere.

La fortuna dei millennials

Da millennial, sento spesso di appartenere a una generazione strana e fortunata. Abbiamo vissuto abbastanza mondo analogico da ricordare cosa significasse aspettare, annoiarsi, uscire per strada, chiamare da casa, fare gli squilli, consumare gli SMS della Summer Card, comprare riviste di videogiochi, vedere il 3D diventare normale, poi internet, smartphone, cloud e ora AI.

In poco più di trent'anni abbiamo attraversato una quantità enorme di transizioni tecnologiche. Siamo forse una delle ultime generazioni che può ricordare il prima e costruire il dopo. Questo non ci rende migliori. Ma ci dà una responsabilità particolare: sappiamo che la tecnologia può essere meravigliosa e invasiva allo stesso tempo.

Abbiamo visto il bene tecnologico e il male tecnologico abbastanza da non poterci permettere ingenuità. Sappiamo che ogni comodità ha un costo, che ogni automatismo cambia abitudini, che ogni dipendenza sembra innocua finché non diventa infrastruttura.

La domanda per i nostri figli

Penso spesso a cosa troveranno mia figlia, i miei nipoti, i bambini che oggi crescono in un mondo dove parlare con una macchina sarà normale quanto per noi era accendere la televisione. Che cosa succederà alla loro capacità critica? Sapranno dire di no? Sapranno distinguere tra soluzione e scorciatoia? Sapranno pretendere un piano B?

La responsabilità non è solo della scuola, dei governi o delle aziende. È anche nostra. Genitori, tecnici, imprenditori, educatori, adulti che stanno costruendo il mondo in cui loro entreranno. Non possiamo limitarci a dare loro strumenti più potenti. Dobbiamo insegnare anche il dubbio, la manutenzione, il limite, la verifica, la pazienza.

Forse il problema non sarà che l'AI farà tutto al posto nostro. Forse il problema sarà che ci abitueremo così tanto a farci aiutare da non capire più quando l'aiuto diventa dipendenza.

Conclusione

Il futuro che abbiamo davanti può essere straordinario. Più persone potranno costruire, sperimentare, risolvere problemi, creare prodotti, automatizzare lavoro noioso e trasformare intuizioni in strumenti reali. Questo è un progresso enorme.

Ma esiste anche un'altra possibilità: un futuro in cui molte persone avranno l'illusione di aver risolto un problema perché il software si avvia, l'interfaccia è bella e la demo convince. Solo anni dopo scopriremo se quel software era davvero solido o se stavamo preparando il terreno per il disastro successivo.

La domanda quindi resta aperta: stiamo andando verso un mondo in cui chiunque può risolvere problemi reali, o verso un mondo in cui chiunque può generare sistemi abbastanza convincenti da nascondere problemi che non sa più vedere?