Il vibe coding promette di democratizzare lo sviluppo software. Ma quando programmatori e knowledge worker possono creare applicazioni con l’AI, diventano centrali governance, verifica e controllo del rischio.
Indice degli argomenti
Che cos’è il vibe coding e perché cambia lo sviluppo software
Il termine vibe coding è entrato nel dibattito pubblico nel febbraio 2025 grazie ad Andrej Karpathy, che in un post su X lo ha usato per descrivere un modo di sviluppare software dialogando con un modello linguistico. In questo approccio si procede per iterazioni successive, senza leggere né comprendere direttamente il codice sorgente generato (Karpathy, 2025). L’espressione descrive un cambiamento già in atto: il focus si sposta dalla scrittura del codice alla definizione dell’obiettivo e alla correzione progressiva del comportamento del sistema, attraverso il confronto continuo con l’agente.
Il vibe coding non coincide con il semplice uso dell’intelligenza artificiale da parte dei programmatori. Una cosa è chiedere a un assistente di generare una funzione per poi leggerla, modificarla, testarla e integrarla consapevolmente nella codebase. Un’altra è descrivere il risultato atteso, lasciare che il modello costruisca la soluzione, valutarne solo l’output visibile e continuare a intervenire con nuovi prompt finché l’esito non appare soddisfacente.
Nel paradigma tradizionale, programmare significa tradurre intenzioni umane in istruzioni formali, mantenendo un controllo diretto sul codice. Nel vibe coding, invece, l’utente definisce obiettivi, vincoli e correzioni, mentre l’AI si occupa interamente della scrittura del codice.
In Europa il vibe coding si diffonde in un quadro normativo (AI Act, GDPR, NIS2, DORA) che impone accountability, auditabilità e controllo sul trattamento dei dati. La questione, quindi, non riguarda solo come si programmerà, ma anche chi potrà sviluppare software nelle organizzazioni e con quali responsabilità.
Il vibe coding tra low-code, no-code e shadow IT
Il vibe coding può essere visto come l’ultima evoluzione di una lunga serie di tentativi di ridurre o aggirare la programmazione specialistica. I fogli di calcolo hanno permesso a milioni di persone di creare modelli computazionali senza percepirli come veri e propri programmi. Macro, linguaggi visuali, robotic process automation (RPA), piattaforme low-code e no-code hanno cercato per decenni di avvicinare la costruzione del software agli utenti di business. In parte ci sono riusciti: una quota significativa di software operativo nasce oggi fuori dai team professionali.
Il vibe coding si colloca quindi nella tradizione dell’end-user development, del citizen development, del low/no-code e, quando sfugge al controllo, dello shadow IT: l’uso di strumenti che possono aggirare i presidi di sicurezza, creare rischi di compliance e rendere meno chiara la destinazione dei dati aziendali.
La novità introdotta dagli LLM è la generalizzazione dell’interfaccia. Non serve più imparare una grammatica visuale, un linguaggio semplificato o un ambiente proprietario: basta descrivere il risultato in linguaggio naturale e lasciare che il modello generi il codice necessario. Questo abbassa ulteriormente la soglia d’ingresso, ma rende anche più importante distinguere un prototipo da un sistema affidabile.
È però utile distinguere due fenomeni che spesso vengono confusi. Da un lato c’è il vibe coding praticato dai professionisti del software. Dall’altro quello dei knowledge worker: esperti di dominio in aree come finance, operations, marketing, HR, logistica o amministrazione, ma senza formazione da sviluppatori. Gli strumenti possono essere gli stessi, ma i rischi prodotti e le misure organizzative e metodologiche richieste sono diversi.
Professionisti del software: dal codice all’orchestrazione
Oggi una quota crescente di programmatori usa strumenti di AI per scrivere, spiegare, modificare, testare o documentare codice. La differenza non sta più nell’adozione di questi strumenti, ma nel modo in cui vengono integrati nel lavoro quotidiano. Gli approcci possono essere disposti lungo un continuum che va da un estremo “artigiano” a un estremo “direttore d’orchestra”.
Pregi e rischi del modello artigiano
L’artigiano usa l’AI come acceleratore, non come delegato. Chiede suggerimenti, test, refactoring mirati, traduzioni tra linguaggi, spiegazioni o supporto nel debugging; ma continua a leggere tutto, a controllare le astrazioni, a verificare i casi limite e a mantenere una mappa mentale della codebase. Non si fida del codice generato solo perché appare plausibile: i modelli possono produrre soluzioni fragili, introdurre dipendenze superflue, ignorare vincoli architetturali, duplicare logica o trascurare sicurezza e performance. L’artigiano difende la qualità con prudenza epistemica: approva il codice solo quando lo ha compreso.
Il pregio di questo approccio è la continuità con le buone pratiche ingegneristiche sviluppate in oltre ottant’anni di programmazione. La manutenibilità resta sotto controllo, la responsabilità è chiara e il debito tecnico si riconosce più facilmente. Inoltre, l’artigiano conserva competenze profonde: sa scrivere codice, capirlo e fare debugging. Il limite, però, è economico. Se gli agenti AI sono in grado di generare quantità crescenti di codice corretto, testato e leggibile, verificare manualmente ogni riga rischia di diventare un collo di bottiglia insostenibile.
Pregi e rischi del modello direttore d’orchestra
All’estremo opposto c’è il direttore d’orchestra. In questo modello il programmatore non scrive più codice, né lo rilegge. Definisce obiettivi, vincoli, criteri di accettazione, interfacce, standard architetturali, policy di sicurezza e test. Scompone il lavoro in task, lo assegna agli agenti, fa generare implementazioni, test e pipeline automatiche, usa analisi statica, strumenti di osservabilità e review automatica. Poi decide se accettare il software, non il codice.
Il vantaggio di questo approccio è la scalabilità. Un solo professionista può esplorare alternative, creare prototipi e produrre test, documentazione e migrazioni con una velocità prima impensabile.
Il limite è evidente: più ci si allontana dal codice, più si rischia di perdere contatto con la realtà del sistema. Il direttore d’orchestra può diventare un gestore di output opachi. Può approvare codice che funziona in demo ma fallisce in produzione, non vedere il debito tecnico accumulato, scambiare test generati dallo stesso modello per verifiche indipendenti e delegare non solo l’esecuzione, ma anche il giudizio. In questo scenario emerge un nuovo debito: il debito di verifica.
Il debito di verifica emerge quando la capacità di generare software cresce più in fretta della possibilità di validarlo.
Perché le software house si spostano verso l’orchestrazione
Nel rapporto When AI builds itself, Anthropic delinea un’evoluzione in cui gli agenti passano dal supporto su singoli frammenti di codice alla modifica autonoma di file, all’esecuzione del codice, alla delega di compiti ad altri agenti (Anthropic, 2026). Pur essendo una fonte interessata, Anthropic descrive un fenomeno che molti professionisti dello sviluppo hanno osservato direttamente negli ultimi tre anni. Per le software house il punto centrale è il cambiamento del ruolo umano nella programmazione: definire obiettivi, esercitare giudizio, dare direzione e validare i risultati, mentre l’operatività viene sempre più delegata all’AI.
La conseguenza pratica è che i professionisti del software dovrebbero spostarsi verso il ruolo di direttori d’orchestra. Questo significa investire in specifiche eseguibili, code review automatizzate, test automatici e guardrail. Più codice viene generato dagli agenti, meno la qualità può dipendere dalla lettura umana. Deve invece essere incorporata nel sistema di produzione del software.
La via matura al vibe coding professionale, quindi, non è “fidarsi dell’AI”, ma progettare un ambiente in cui la fiducia cieca non sia necessaria. L’artigiano controlla perché non si fida. Il direttore d’orchestra maturo, invece, costruisce processi che rendono controllabile anche ciò che non può leggere. Si passa così dalla revisione manuale del codice alla validazione sistemica del comportamento.
Vibe coding per knowledge worker e non professionisti
Il secondo fenomeno, quello dei non professionisti, è ancora più dirompente sul piano organizzativo. Grazie al vibe coding, un esperto di dominio può creare software utile al proprio lavoro senza dover attendere un team IT. Un controller può generare uno script per riconciliare file; un HR può costruire un flusso di onboarding; un project manager può automatizzare report; un marketer può creare un tool per generare contenuti; un responsabile operations può sviluppare un pianificatore. Queste soluzioni nascono perché le persone devono risolvere problemi operativi e gli strumenti ufficiali sono assenti o inadeguati.
Qui il vibe coding eredita la funzione storica dell’end-user development: ridurre il tempo tra bisogno e soluzione. In un’organizzazione tradizionale, anche una piccola automazione può richiedere ticket, priorità, backlog, analisi, sviluppo, rilascio o outsourcing. Per molti bisogni limitati, questo ciclo è sproporzionato. Se invece chi conosce il processo può costruire una soluzione in poche ore o pochi giorni, il valore è immediato. La qualità non va misurata in astratto rispetto a un sistema enterprise, ma rispetto all’alternativa concreta: lavoro manuale, copia-incolla, file non controllati ed errori ripetitivi.
Benefici e rischi nelle organizzazioni
I benefici sono rilevanti: velocità, autonomia, sperimentazione, aderenza al contesto e apprendimento pratico. I casi enterprise mostrano anche che il fenomeno può scalare. Microsoft ha descritto l’uso interno della Power Platform da parte di dipendenti non tecnici all’interno di un quadro di governance e guardrail (Microsoft, 2023). Deutsche Bahn ha documentato una comunità di migliaia di citizen developer e centinaia di applicazioni in produzione, sostenute da Center of Excellence centrali e locali (Microsoft, 2025).
Proprio perché l’utilità è elevata, il rischio non può essere trascurato. Un non professionista può generare codice funzionante senza considerare autorizzazioni, sicurezza, gestione degli errori, versionamento, logging, privacy, dipendenze, scalabilità, test, licenze, segreti, credenziali o limiti API. Nel caso del vibe coding, questi rischi possono essere persino maggiori rispetto allo sviluppo low/no-code. Quando un citizen developer crea un prototipo utile che, poco alla volta, diventa infrastruttura critica, oppure costruisce un database ombra, un’automazione che sposta dati sensibili in chiaro, uno script con permessi troppo ampi, o una applicazione web con autenticazione improvvisata, il problema non è più la democratizzazione dello sviluppo, ma lo shadow IT.
Queste pratiche nascono da bisogni reali non coperti dai sistemi ufficiali. Per questo un’organizzazione non dovrebbe vietarle: il divieto rischia soprattutto di renderle invisibili. L’obiettivo dovrebbe essere un altro: renderle visibili, censite, proporzionate al rischio e, quando serve, integrate nei processi IT.
Quando il vibe coding dei non professionisti è sensato
La domanda pratica è quindi questa: quando il vibe coding dei non professionisti ha senso, e quando invece serve coinvolgere professionisti?
Ha senso quando il problema è locale, reversibile, a basso impatto, ben compreso dall’esperto di dominio e non coinvolge dati sensibili o processi critici. Rientrano in questo perimetro automazioni personali, script di pulizia dati, trasformazioni ripetitive, bozze di dashboard, prototipi interni, strumenti temporanei, generatori di report non regolamentati e piccole utility per ridurre il lavoro manuale. In questi casi, chiedere sempre l’intervento dell’IT sarebbe inefficiente. La condizione, però, è che esistano confini chiari: owner, scopo, dati trattati, data di revisione, istruzioni minime, possibilità di spegnimento, assenza di credenziali personali e nessuna dipendenza nascosta da servizi esterni non autorizzati.
Quando servono i professionisti
Serve coinvolgere professionisti quando la soluzione supera alcune soglie: multiutenza, dati personali o regolati, impatto su paghe, compliance, reporting ufficiale, clienti, sicurezza, identità, autorizzazioni, database condivisi, integrazioni esterne, disponibilità 24/7, pagamenti, sistemi core o decisioni operative rilevanti. In questi casi non basta che “funzioni”: la soluzione deve essere mantenibile, osservabile, sicura, documentata, testata, integrata e supportata. Il non professionista può restare co-autore funzionale, product owner o domain expert, ma la responsabilità ingegneristica deve passare a un percorso IT o ibrido.
Diversi studi mostrano che gli utenti non tecnici fanno fatica a comprendere gli errori, interpretare i messaggi tecnici e stabilire se un output sia davvero affidabile (Feldman & Anderson, 2024). I professionisti di business possono usare strumenti AI per analisi e decisioni, ma restano spesso in difficoltà nell’individuare errori critici nei risultati generati (Virk & Liu, 2025). Il rischio centrale, quindi, non è che un non tecnico generi qualcosa, ma che non riesca a capire con sufficiente affidabilità quando ciò che ha prodotto è abbastanza corretto da guidare decisioni o processi.
Governance del vibe coding: guardrail, soglie e responsabilità
La soluzione è una governance per livelli: una zona verde per automazioni personali e reversibili; una zona gialla per strumenti di team, da registrare con owner, log, test minimi e revisione periodica; una zona rossa per ciò che coinvolge dati sensibili, processi core, identità, integrazioni esterne o obblighi normativi, dove serve un percorso di sviluppo presidiato da professionisti.
Un possibile albero decisionale per applicare questo criterio è il seguente:
Figure 1 Albero decisionale per capire quando è possibile procedere col vibe coding da parte dei non professionisti
Questo modello richiede anche un nuovo ruolo per l’IT: custode dei guardrail, abilitatore, revisore dei casi critici, formatore e osservatore del portafoglio applicativo informale. Deve offrire ambienti autorizzati, policy sui connettori, data loss prevention, audit log, template, cataloghi, percorsi di escalation, componenti riusabili, linee guida per l’uso dell’AI e strumenti di verifica. L’obiettivo è permettere ai business users di costruire entro un perimetro visibile e sicuro.
Anche la formazione va ripensata. Ai citizen developer non serve diventare software engineer, ma acquisire un’alfabetizzazione minima su concetti finora riservati all’IT: autorizzazioni, test, gestione degli errori, versioni, documentazione, dipendenze, credenziali, logging, limiti dei modelli, allucinazioni, sicurezza ed esposizione dei dati aziendali. La competenza chiave è capire quando una soluzione può restare locale e quando deve “salire di classe”.
Conclusioni: il vantaggio è governare il software generato
Il vibe coding è una nuova interfaccia produttiva, non un gioco e nemmeno una rivoluzione anarchica. Per i professionisti accelera il passaggio dal coding manuale all’orchestrazione di agenti e sistemi di verifica; per i knowledge worker trasforma bisogni locali in software d’uso personale. In entrambi i casi il punto decisivo è la validazione, non la generazione.
Una parte via via crescente dei programmatori si sposterà, verosimilmente, verso il vibe coding, perché i coding agent migliorano rapidamente e la verifica manuale rischia di diventare un collo di bottiglia. Devono però accompagnare questo passaggio con verifiche non manuali: test e analisi statica, benchmark e security scanning, osservabilità e review automatiche, e specifiche formali dove servono. Il programmatore del futuro non sarà meno tecnico, ma tecnico a un livello più sistemico.
Anche i knowledge worker non programmatori possono sviluppare il software che serve loro, finché affidabilità, sicurezza e compliance non richiedono un team professionale. È una forma di efficienza organizzativa, ma deve restare entro soglie esplicite.
Usare tempo umano qualificato per digitare istruzioni che una macchina può generare, testare e riscrivere più rapidamente non appare più razionale.
Nel mondo del vibe coding il vantaggio competitivo non nasce dalla capacità di generare software, ma dalla capacità di governarlo.
Riferimenti sul vibe coding
Anthropic. (2026). When AI builds itself: Our progress toward recursive self-improvement, and its implications. Anthropic Institute. https://www.anthropic.com/institute/recursive-self-improvement
Feldman, M., & Anderson, F. (2024). Non-Expert Programmers in the Generative AI Future. CHIWORK. https://www.feldmanmolly.com/chiwork2024-author-version.pdf
Karpathy, A. (2025). There’s a new kind of coding I call “vibe coding”. https://x.com/karpathy/status/1886192184808149383
Microsoft. (2023). Empowerment with good governance: How our citizen developers get the most out of the Microsoft Power Platform. Microsoft Inside Track. https://www.microsoft.com/insidetrack/blog/empowerment-with-good-governance-how-our-citizen-developers-get-the-most-out-of-the-microsoft-power-platform/
Microsoft. (2025). Deutsche Bahn empowers citizen developers with Microsoft Power Platform. Microsoft Learn. https://learn.microsoft.com/en-us/power-platform/guidance/case-studies/db-empowers-citizen-devs
Virk, H., & Liu, Y. (2025). Non-programmers Assessing AI-Generated Code: A Case Study of Business Users Analyzing Data. arXiv. https://arxiv.org/pdf/2508.06484
Partecipa alla community