Lascio il lavoro per colpa del vibe coding: lo sfogo che fa discutere

In molte aziende tecnologiche la spinta verso strumenti di sviluppo sempre più accessibili e “immediati” ha prodotto effetti collaterali inattesi. In un thread pubblicato nella community r/sysadmin di Reddit, frequentata da centinaia di migliaia di amministratori di sistema, un professionista IT racconta di aver deciso di lasciare il proprio lavoro dopo mesi di frustrazione. Il motivo non riguarda un singolo bug o un incidente di sicurezza, ma un fenomeno emergente: la proliferazione di applicazioni interne create da cosiddetti vibe coders, sviluppatori improvvisati o utenti aziendali che costruiscono software seguendo l’intuizione e avvalendosi di strumenti automatizzati senza un reale processo ingegneristico.

Prima non sapevano mettere in fila 10 righe di codice: oggi “sanno fare tutto”

Il racconto riflette una tensione concreta tra due mondi: da un lato la crescente democratizzazione dello sviluppo software grazie a strumenti low-code, generatori basati su modelli linguistici e ambienti di prototipazione rapida; dall’altro le responsabilità operative dei team infrastrutturali, chiamati a mantenere sistemi sicuri, monitorabili e conformi alle politiche aziendali.

Nel suo intervento, l’autore descrive una situazione in cui la direzione aziendale ha promosso iniziative interne per incentivare la creazione rapida di nuove applicazioni. L’obiettivo dichiarato consisteva nel trasformare idee in prototipi funzionanti con grande velocità, spesso attraverso strumenti automatici o ambienti di sviluppo semplificati. La promessa di premi o bonus per i progetti più efficaci ha innescato un afflusso massiccio di richieste verso il reparto IT. Il risultato è stato un aumento improvviso di applicazioni interne da valutare, integrare e mantenere.

Gli amministratori di sistema hanno dovuto analizzare, autorizzare e in alcuni casi distribuire software sviluppato rapidamente da personale non specializzato.

All’emergere di problemi evidenti – credenziali inserite nel codice, assenza di controlli di autenticazione o integrazioni con servizi esterni non verificati – il team infrastrutturale interviene, segnala i rischi e coinvolge il reparto sicurezza. Le segnalazioni innescano riunioni, discussioni e lunghe catene di messaggi.

Il problema, a nostro avviso, è tangibile: anche noi ci siamo trovati a interagire sempre più spesso con persone che fino a ieri non avevano la minima idea di come approcciare la programmazione e che oggi sbandierano le loro articolate creazioni.

Cosa si intende davvero per “vibe coding”

Il termine non nasce in contesti accademici o industriali, ma nelle comunità online di sviluppatori. Con vibe coding si indica una modalità di sviluppo guidata più dall’intuizione che da metodologie strutturate: si scrive codice rapidamente affidandosi a generatori AI, senza seguire pratiche consolidate di progettazione software.

Molti sviluppatori descrivono il fenomeno come una forma di programmazione “per sensazione”: il codice cresce per tentativi, adattamenti e copiature successive. Standard architetturali, convenzioni di sicurezza o test sistematici diventano elementi secondari.

In contesti informali – prototipi personali, piccoli tool interni, hackathon – si tratta di uno schema che può effettivamente accelerare la sperimentazione. Il problema emerge quando progetti nati in modo spontaneo entrano nel ciclo operativo di un’impresa.

Qui è sempre bene muoversi con i proverbiali piedi di piombo. Il motivo è semplice: un’applicazione distribuita in un ambiente aziendale non è più solo codice che “funziona”, ma diventa parte di un’infrastruttura complessa fatta di identità digitali, servizi condivisi, dati sensibili e sistemi critici. Anche un piccolo tool interno può interagire con database aziendali, directory di autenticazione, API di terze parti o servizi cloud. Se la progettazione non considera questi aspetti fin dall’inizio, il rischio non riguarda solo bug funzionali ma veri e propri problemi di sicurezza e affidabilità.

Gestione delle credenziali, dipendenze software e complessità

Uno degli errori più frequenti riguarda la gestione delle credenziali. Nei prototipi sviluppati rapidamente capita spesso di trovare password, token API o stringhe di connessione inserite direttamente nel codice sorgente. In ambienti professionali tali informazioni dovrebbero invece essere gestite tramite sistemi di secret management, come vault centralizzati o variabili d’ambiente protette. Un repository condiviso o un sistema di versionamento può trasformare in pochi minuti una credenziale hardcoded in un problema di sicurezza esteso.

Un secondo aspetto critico riguarda le dipendenze software. Molti strumenti creati velocemente incorporano librerie prese da repository pubblici senza verifiche approfondite. Framework JavaScript, moduli Python o componenti backend possono includere vulnerabilità note oppure dipendere da pacchetti non più mantenuti. Senza un controllo delle versioni e senza scansioni di sicurezza automatiche, il rischio di introdurre codice vulnerabile aumenta sensibilmente.

Infine entra in gioco la questione della manutenzione nel tempo. Il codice scritto rapidamente per risolvere un problema immediato può diventare, nel giro di pochi mesi, un servizio critico da cui dipendono processi aziendali. Se l’autore originale cambia ruolo o lascia l’azienda, il team IT si ritrova a gestire applicazioni poco documentate e difficili da aggiornare. Il debito tecnico accumulato durante la fase sperimentale si palesa proprio in quel momento.

Perché gli amministratori di sistema vedono un rischio

Un’infrastruttura IT moderna include numerosi livelli di controllo. Ogni applicazione deve integrarsi con sistemi di autenticazione centralizzati, registrare log affidabili, rispettare politiche di rete e seguire procedure di gestione delle patch. Quando un nuovo software compare all’improvviso, scritto senza documentazione o revisioni formali, il team operativo deve ricostruire a posteriori ciò che normalmente verrebbe definito durante la progettazione.

Ha ragione l’autore del post su Reddit a lamentarsi se la sua (ex?) azienda aveva aperto le porte all’utilizzo del vibe coding senza alcun tipo di regolamentazione. “Quando il team infrastrutturale segnalava i problemi e coinvolgeva il reparto sicurezza, il risultato erano lunghe discussioni interne che raramente portavano al blocco definitivo dei progetti“, si legge.

Nel racconto dell’autore la situazione è diventata progressivamente insostenibile: revisioni tecniche ignorate, applicazioni distribuite nonostante vulnerabilità evidenti e un crescente carico operativo per gestire software difficile da mantenere. Alla fine la decisione di cambiare lavoro è arrivata come conseguenza diretta di questo conflitto tra sviluppo improvvisato e responsabilità infrastrutturali.

Non trattare il software come esperimento

Un approccio di questo tipo solleva interrogativi più ampi sulla governance tecnica. Il problema non è l’esistenza del vibe coding in sé, ma l’assenza di regole quando viene introdotto all’interno di contesti aziendali complessi. Sperimentare con strumenti che generano codice rapidamente può risultare utile per testare idee, validare prototipi o creare soluzioni temporanee. Tuttavia un’impresa che gestisce dati, servizi digitali e infrastrutture critiche non può permettersi di trattare il software come un semplice esperimento.

Un’organizzazione strutturata deve definire salvaguardie chiare prima di consentire l’adozione di nuovi strumenti di sviluppo. Ogni applicazione, anche se nasce da un progetto interno informale, dovrebbe passare attraverso un processo di verifica: revisione del codice, controllo delle dipendenze, integrazione con sistemi di autenticazione aziendali e analisi delle vulnerabilità.

Senza queste barriere, l’entusiasmo per la rapidità di sviluppo rischia di trasformarsi in un accumulo di debito tecnico e in un aumento della superficie di attacco.

Vibe coding in azienda?

A nostro avviso il vibe coding in azienda dovrebbe essere eventualmente utilizzato solo da sviluppatori che possiedono già una solida esperienza tecnica. Chi conosce architetture software, modelli di sicurezza applicativa e gestione delle infrastrutture può sfruttare generatori di codice e assistenti AI per accelerare il lavoro senza rinunciare alla qualità.

In questo caso il vibe coding diventa un acceleratore di produttività: automatizza attività ripetitive, suggerisce implementazioni di base e permette di concentrarsi su problemi architetturali più complessi.

La differenza sta nella consapevolezza con cui questi strumenti sono impiegati. Un professionista esperto riconosce immediatamente i limiti del codice generato automaticamente: controlla la gestione delle sessioni, verifica l’uso corretto delle librerie crittografiche, analizza il modo in cui sono trattati input e dati personali. Un utente inesperto tende invece a considerare il risultato finale come una soluzione completa, ignorando i dettagli tecnici che determinano sicurezza e affidabilità.

Come le imprese possono evitare problemi con il vibe coding

Il racconto dell’amministratore di sistema su Reddit evidenzia un problema organizzativo prima ancora che tecnico.

L’innovazione rapida non è incompatibile con la sicurezza, ma richiede regole chiare. Alcune aziende hanno introdotto programmi di platform engineering che forniscono ambienti standardizzati per lo sviluppo interno: template applicativi preconfigurati, autenticazione integrata e strumenti di logging già predisposti.

In questo modo i prototipi nascono all’interno di una struttura controllata. Chi sviluppa nuove applicazioni utilizza modelli già conformi con le politiche di sicurezza, mentre il reparto infrastrutturale mantiene visibilità su ogni progetto. In assenza di questi strumenti, ogni nuova applicazione diventa un caso isolato da analizzare manualmente.

Senza una governance tecnica adeguata, l’entusiasmo per la creazione rapida di applicazioni può tradursi in debito tecnico, attriti organizzativi e rischi di sicurezza difficili da controllare. I vertici aziendali che non capiscono questo non stanno innovando, stanno preparando il terreno per i problemi che si manifesteranno in futuro.

Non bisogna essere una Cassandra per sostenerlo: basta osservare cosa accade ogni volta che sistemi costruiti senza criteri ingegneristici entrano in produzione. Prima o poi si scoprono gravi vulnerabilità, si presentano guasti operativi, applicazioni impossibili da mantenere o dipendenze da codice che nessuno conosce davvero. A quel punto il prezzo dell’improvvisazione diventa evidente, spesso quando correggere gli errori è diventato ormai costosissimo.