Vibe coding: i rischi oltre il prototipo

Descrivere un’applicazione a un assistente, vederla comparire in poche ore e correggerla conversando è un acceleratore reale. Per un founder o una PMI significa verificare un’idea senza finanziare subito mesi di sviluppo. Il problema nasce quando la velocità del prototipo viene scambiata per maturità del prodotto.

Il vibe coding riduce il tempo necessario a produrre codice; non trasferisce automaticamente a chi lo commissiona la comprensione del sistema, la responsabilità delle decisioni o il controllo operativo. Il codice che “sembra funzionare” resta software: tratta dati, eredita dipendenze, espone superfici di attacco e dovrà essere mantenuto quando il contesto della conversazione non esisterà più.

Demo, MVP e produzione non sono sinonimi

Una demo deve rendere visibile un’idea in un percorso controllato. Può usare dati fittizi e tollerare passaggi manuali. Un MVP deve invece verificare un’ipotesi con utenti reali: richiede già una gestione consapevole dei dati, degli accessi e degli errori, anche se ambito e volumi sono limitati. Un sistema di produzione sostiene un processo aziendale: deve funzionare anche quando una dipendenza è lenta, un utente compie un’azione inattesa, una persona del team è assente o serve ripristinare dati.

Portare lo stesso repository da una fase all’altra senza una revisione esplicita lascia invisibili le assunzioni fatte per accelerare. La domanda utile non è «l’app gira?», ma «sappiamo perché gira, come può fallire e chi interviene?».

Codice prodotto non significa codice compreso

Un assistente può generare rapidamente componenti, query e configurazioni in linguaggi che il team conosce poco. Il risultato può essere plausibile e superare il percorso felice, ma nessuno sa spiegare i confini delle autorizzazioni, la strategia delle transazioni o perché sia stata scelta una libreria. In quel momento l’azienda possiede dei file, non ancora il controllo del sistema.

L’ownership richiede almeno una persona capace di leggere il diff, ricostruire le decisioni e assumersi la responsabilità del rilascio. La documentazione ufficiale di GitHub sull’uso responsabile degli agenti ricorda che il codice generato può essere inesatto o insicuro e deve essere revisionato e testato. Una seconda AI può aiutare nella review, ma non sostituisce un responsabile competente né rende indipendente una verifica costruita dallo stesso meccanismo che ha prodotto il codice.

Dipendenze e API plausibili, ma inesistenti

I modelli possono proporre pacchetti sbagliati, versioni incompatibili, metodi rimossi o parametri che appartengono a un’altra API. Installare alla cieca un nome suggerito aggiunge anche un rischio di supply chain: un pacchetto omonimo o poco mantenuto può diventare parte della produzione senza una valutazione.

Ogni nuova dipendenza dovrebbe avere un’origine verificata, una licenza compatibile, una versione bloccata e un motivo per esistere. Le integrazioni vanno confrontate con la documentazione ufficiale ed eseguite in test contro una sandbox quando disponibile. Il NIST SSDF tratta inventario dei componenti, provenienza, protezione del codice e risposta alle vulnerabilità come parti del ciclo di sviluppo, non come pulizia successiva.

Segreti, permessi e autorizzazioni fragili

Per “far funzionare” una demo è facile inserire una chiave nel codice, dare a un servizio privilegi amministrativi o controllare un ruolo soltanto nell’interfaccia. Una chiave finita nella cronologia Git non è protetta perché il file viene poi aggiunto a .gitignore; va revocata e sostituita. Un pulsante nascosto non impedisce a un utente di chiamare direttamente un endpoint.

OWASP raccomanda di separare i segreti dal repository, limitare il contesto inviato agli assistenti e verificare manualmente i test critici per autenticazione, autorizzazione e validazione degli input. In produzione ogni operazione deve essere autorizzata lato server, con privilegi minimi e separazione tra ambienti. Anche l’agente di coding deve operare con accessi limitati: terminale, rete e credenziali ampliano ciò che un errore può modificare o divulgare.

I test non sono una formalità da generare alla fine

Un assistente sa produrre test che confermano la propria implementazione. Questo non dimostra che siano stati coperti i requisiti reali, le condizioni di concorrenza, i permessi o il recupero dopo un errore. Servono test definiti a partire dal comportamento atteso, inclusi casi negativi e regressioni, più controlli statici e scansione delle dipendenze.

La review deve chiedere che cosa manca, non solo se la suite è verde. Per flussi che muovono denaro, dati personali o modificano stati irreversibili occorrono verifiche indipendenti e, quando opportuno, test end-to-end in un ambiente simile alla produzione.

Il debito architetturale arriva insieme alla velocità

Prompt successivi tendono a risolvere il problema locale. Senza una mappa del dominio possono duplicare logica, accoppiare interfaccia e database, creare più fonti della verità o aggiungere eccezioni finché nessuno riconosce il flusso principale. Il costo emerge alla prima modifica trasversale, quando una correzione rompe tre parti apparentemente scollegate.

Non tutto il codice generato va riscritto. Prima del go-live va però ricostruita l’architettura effettiva: dati e loro proprietari, confini dei moduli, dipendenze esterne, percorsi di autenticazione, operazioni asincrone e punti di fallimento. Dove una scorciatoia è accettata, deve avere un rischio esplicito e una decisione su quando rimuoverla.

Manutenzione e costi sono requisiti di prodotto

Il costo del prototipo può essere quasi nullo perché traffico, dati e incidenti sono quasi nulli. In produzione entrano ambienti separati, database, backup, email, storage, monitoraggio, API a consumo e tempo umano. Una query inefficiente o una funzione richiamata in loop può trasformare un errore logico in una spesa ricorrente.

Bisogna poter aggiornare dipendenze, ruotare segreti, migrare lo schema e diagnosticare un problema senza ricostruire una vecchia chat. Repository, istruzioni di deploy, decisioni architetturali e runbook devono appartenere all’azienda ed essere comprensibili a chi manterrà il sistema.

Checklist prima del go-live

• Ownership: una persona nominata comprende il sistema, possiede repository, account e documentazione e può autorizzare un rilascio.
• Review: codice, dipendenze, licenze, configurazioni, segreti e permessi sono stati verificati da qualcuno competente.
• Test: requisiti, casi negativi, autorizzazioni, migrazioni e percorsi critici hanno verifiche ripetibili.
• Backup: dati e configurazioni inclusi nel perimetro sono definiti; un ripristino è stato provato con tempi e perdita accettabile misurati.
• Rollback: esiste una procedura testata per tornare alla versione precedente senza corrompere dati o sessioni.
• Logging: gli eventi necessari a diagnosticare errori e abusi sono disponibili, protetti e conservati per un tempo definito.
• Costi: metriche di consumo, budget, avvisi e responsabile della fattura sono configurati.
• Incidente: è scritto chi riceve l’allarme, come limita il danno, comunica e ripristina il servizio.

Il vibe coding rimane utile quando abbrevia il percorso tra ipotesi e apprendimento. Diventa rischioso quando nasconde il lavoro necessario per assumere il controllo. Se hai costruito un prototipo che ora deve sostenere clienti e operatività, IA senza controllo descrive come valutarlo e renderlo governabile prima che la velocità iniziale diventi dipendenza.