Come usare il vibe coding nei team aziendali senza perdere il controllo del codice e della sicurezza

Il Vibe Coding in azienda si scopre durante la revisione del codice.

Pull request da quattrocento righe, un senior che la apre e sente che qualcosa non torna: i nomi delle variabili sono in inglese mentre il resto del progetto è in italiano, vede la stessa cosa fatta in tre modi diversi, lo stile non è quello del team.

Chiede al collega come l'ha scritto.

Risposta: "l'ho descritto a Claude e me l'ha generato".

Il codice funziona.

L'architettura, intanto, ha già iniziato a divergere.

Il termine Vibe Coding lo ha coniato Andrej Karpathy nel febbraio 2025 per descrivere la pratica di generare software in linguaggio naturale affidandosi completamente agli LLM.

Nel 2026 è arrivato nelle aziende italiane come fatto compiuto, prima che i CTO avessero il tempo di decidere cosa farne.

La domanda, quindi, non è se adottarlo, perché è già in produzione.

È se iniziare a controllarlo adesso o lasciarlo proliferare, accumulando vulnerabilità, debito tecnico e rischi di conformità che si presentano tra dodici e diciotto mesi con un conto molto più alto di qualunque investimento in regole e controlli fatto oggi.

Il Vibe Coding senza regole non è una questione di preferenze stilistiche: è un rischio di business quantificabile che cresce ogni giorno in cui non si interviene.

Qui dentro troverai raccontato cosa sta succedendo nel tuo team, i quattro rischi con i meccanismi che li generano e il framework a tre zone per separare l'uso sicuro da quello pericoloso.

Poi la policy in cinque sezioni che gli sviluppatori leggono davvero, i controlli automatici da mettere in pipeline, le metriche per capire se sta funzionando e il conto della governance con i numeri di un team da otto persone.

Cos'è il Vibe Coding e perché sta cambiando lo sviluppo aziendale nel 2026

Un tweet, febbraio 2025.

Andrej Karpathy, ex ricercatore di OpenAI e fondatore di Eureka Labs, racconta di avere smesso di scrivere codice: descrive il comportamento che vuole e lascia che sia il modello a produrre l'implementazione, test ed errori compresi.

Gli dà un nome, Vibe Coding, e il nome resta.

Il Vibe Coding è la generazione di software in linguaggio naturale in cui lo sviluppatore descrive il risultato e accetta l'implementazione senza necessariamente capire ogni riga, iterando con altri prompt se qualcosa non funziona.

È una cosa diversa dall'uso normale di GitHub Copilot, ed è la differenza che decide tutto il resto.

Nel completamento assistito lo sviluppatore scrive e il modello suggerisce: la mano resta sua, il codice nasce dalla sua testa e l'AI accorcia i tempi.

Nel Vibe Coding la mano cambia proprietario.

Lui descrive il problema, il modello consegna la soluzione, e il confine tra "ho letto tutto" e "ho letto abbastanza" si sposta ogni volta un po' più in là, sotto la pressione della scadenza.

Sul prototipo personale il guadagno è impressionante: una funzionalità che chiedeva una giornata si chiude in due ore.

È da lì che la pratica è partita, prima tra gli sviluppatori più curiosi, poi ovunque.

Il problema nasce quando quel codice smette di essere un prototipo personale ed entra in una base di codice condivisa, con requisiti di sicurezza, standard architetturali e vincoli normativi che il modello non conosce e che nessun prompt gli ha raccontato.

I modelli più usati per il Vibe Coding aziendale

L'ecosistema si è consolidato su pochi nomi.

I modelli Claude di fascia Sonnet si sono affermati come riferimento per il ragionamento complesso su sistemi enterprise, con una tenuta del contesto su basi di codice grandi che supera la concorrenza diretta.

GPT-4o resta molto usato per abitudine all'interfaccia di ChatGPT.

Cursor, l'ambiente di sviluppo costruito attorno all'AI sulla base di VS Code, si è preso una quota importante tra chi lavora su rifattorizzazioni e migrazioni di codice legacy.

Nei team .NET la combinazione più diffusa nel 2026 è GitHub Copilot Enterprise per il completamento dentro Visual Studio, più sessioni intensive su Claude o ChatGPT Enterprise quando serve generare un modulo intero.

Sono due strati distinti, con due profili di rischio distinti, e quasi nessuno li ha ancora separati nella propria testa.

È da questa sovrapposizione che nascono i quattro problemi che ti costeranno di più, e nessuno dei quattro è quello di cui si parla in conferenza.

I quattro rischi reali del Vibe Coding aziendale che nessuno quantifica

"Qualità del codice" e "sicurezza" sono le due parole con cui si liquida di solito questa conversazione.

Sono così generiche che nessuno, uscendo dalla riunione, sa cosa fare lunedì mattina.

I rischi del Vibe Coding in azienda sono quattro, e ciascuno nasce da un problema preciso.

Il codice generato può contenere vulnerabilità perché il modello non conosce davvero il contesto dell’azienda e del progetto.

La proprietà intellettuale può uscire dai confini aziendali quando codice, documenti o informazioni vengono inseriti in strumenti AI senza aver verificato termini di servizio e modalità di trattamento dei dati.

L’architettura può diventare incoerente perché ogni sessione genera soluzioni valide nel breve periodo, ma non necessariamente allineate alle scelte fatte in precedenza.

Infine, il processo diventa difficile da dimostrare e controllare perché, se non viene tracciato, non resta una registrazione chiara di cosa è stato chiesto all’AI, cosa ha prodotto e quali modifiche sono state poi accettate.

Il rischio che si vede subito: codice funzionante e insicuro

Un modello linguistico produce il codice statisticamente più probabile dato il prompt, non quello sicuro per la tua applicazione.

Chiedigli "un sistema di login con ASP.NET Core Identity" e otterrai qualcosa che funziona al primo colpo, che magari non protegge dall'enumerazione degli account, non implementa bene il blocco dopo i tentativi falliti e genera token JWT con scadenze lunghissime.

Il punto non è che i modelli non sappiano di sicurezza: Claude e GPT-4 conoscono le OWASP Top 10 meglio di parecchi junior.

Il punto è che nessuno ha detto loro che quella applicazione tratta dati sanitari soggetti a requisiti HIPAA, che il vostro sistema di autorizzazioni ha una gerarchia non standard, che nella vostra pipeline non c'è ancora un'analisi statica del codice.

Il modello non sbaglia il codice: sbaglia il contesto, perché il contesto non ce l'ha.

Uno studio del 2021 dei ricercatori di cybersecurity della NYU Tandon ha messo un numero su questa intuizione: il codice generato da GitHub Copilot senza revisione conteneva vulnerabilità sfruttabili nel 40% dei casi, e studi successivi su altri modelli hanno confermato tassi comparabili.

Non perché sia sbagliato, ma perché gli mancano i controlli che un esperto applica in automatico, senza nemmeno accorgersi di farli.

Il rischio che non si vede: la proprietà intellettuale che esce

Questo è il più sottovalutato nelle aziende italiane di media dimensione, e succede in tre secondi.

Uno sviluppatore apre Claude.ai in versione gratuita o ChatGPT senza abbonamento aziendale, incolla un servizio proprietario e chiede come ottimizzarlo.

Non è uno scenario di fantasia: Anthropic e OpenAI dichiarano entrambe che le conversazioni degli utenti non enterprise possono essere usate per migliorare i modelli.

Fatti una domanda sola, e rispondi onestamente: quale sviluppatore, alle sette di sera di un giovedì, con il rilascio venerdì, va a rileggere i termini di servizio prima di incollare trecento righe per capire un bug?

La risposta non è vietare, è decidere quale piano contrattuale è obbligatorio per quale categoria di codice.

GitHub Copilot Enterprise, ChatGPT Enterprise e Claude for Enterprise garantiscono contrattualmente zero uso dei dati per l'addestramento.

La differenza di prezzo tra piano base ed enterprise è tipicamente di 15-20 euro al mese per utente: per un'azienda che ha nel codice algoritmi di pricing, logica di business esclusiva o dati dei clienti, è la spesa di sicurezza con il miglior rapporto tra costo e risultato che esista sul mercato.

Il rischio che arriva tardi: l'architettura che diverge

Si manifesta lentamente ed è quello che fa più male alla manutenibilità.

Quando persone diverse generano moduli diversi della stessa applicazione, ogni sessione produce scelte ragionevoli in locale e incoerenti nel complesso.

Prendi un'applicazione .NET vera: il modulo A, generato con Claude, usa Repository con Unit of Work.

Il modulo B, generato con GPT-4, va dritto sul DbContext passando per Mediator.

Il modulo C, uscito da Cursor, adotta CQRS con handler separati.

Tutti e tre i pattern sono corretti.

In una base di codice condivisa che cinque persone dovranno mantenere per tre anni, avere tre approcci diversi per la stessa responsabilità triplica lo sforzo mentale di ogni modifica e alza la probabilità di regressioni.

La ricerca di McKinsey del 2025 sull'impatto degli LLM nello sviluppo software stima che il codice prodotto senza governance architetturale accumuli entropia strutturale a un ritmo da 3 a 5 volte superiore rispetto al codice con revisione architetturale standard.

Tradotto nel calendario: una base di codice che avrebbe chiesto una rifattorizzazione seria dopo 24 mesi ci arriva in 6-8 mesi.

Il rischio che nessuno mette in conto: il processo non è dimostrabile

GDPR e la direttiva NIS2, in vigore dal 2024, chiedono alle organizzazioni di dimostrare di avere il controllo sui processi che trattano dati personali.

Il processo di sviluppo software è uno di quelli, e qui la parola chiave non è "conforme": è "dimostrabile".

Se il Garante Privacy o l'autorità NIS2 ti chiede come è stato progettato il modulo di gestione dei consensi o il registro degli accessi ai dati personali, "l'ha generato Claude su mia richiesta" non è una risposta che soddisfa i requisiti di responsabilità.

Non perché il codice sia sbagliato, ma perché non esiste da nessuna parte la traccia di una decisione umana.

Quattro rischi, quattro meccanismi, nessuno dei quali si attiva il primo giorno.

Ed è esattamente questo il problema: quando li vedi, sono già maturi.

Li hai riconosciuti tutti e quattro mentre leggevi, vero?

Almeno due li hai già visti passare in una code review del mese scorso.

La differenza tra chi li vede e chi li nomina in riunione con i numeri in mano è una competenza precisa, e non si impara guardando la pipeline.

È la competenza su cui è costruito il Corso Architetto Software Ai: leggere un sistema, dire dove cederà e portare il dato a chi decide il budget.

Il Vibe Coding senza regole: cosa succede davvero nelle aziende italiane

Il copione lo conosco a memoria, perché in cinque aziende diverse è stato lo stesso, con nomi diversi e la stessa faccia del tech lead al mese quattordici.

Il Vibe Coding senza regole segue un ciclo prevedibile di ventiquattro mesi: adozione silenziosa di uno o due sviluppatori, diffusione informale al resto del team, comparsa dei primi sintomi in code review, incidente che costringe a costruire in emergenza le regole che sarebbero costate un decimo diciotto mesi prima.

Nei primi tre mesi succede la cosa più innocua del mondo.

Uno o due sviluppatori, i più curiosi, cominciano a generare funzionalità intere.

Producono di più e più in fretta.

Non lo raccontano in giro, un po' per timore del giudizio dei colleghi e un po' perché quel vantaggio, dentro il team, è un vantaggio personale.

Il management non sa niente, e non c'è ancora niente da sapere.

Tra il quarto e l'ottavo mese la voce gira.

Altri adottano la pratica, ognuno con il suo flusso di lavoro e i suoi strumenti: chi Claude gratuito, chi ChatGPT, chi Copilot, chi tutti e tre nella stessa giornata.

Nessuno standard, nessuna regola, e soprattutto nessuna visibilità: il tech lead non ha modo di sapere quanto codice del suo prodotto sia stato generato.

Dal nono al quattordicesimo mese arrivano i sintomi, e nessuno li collega alla causa.

Le revisioni rallentano perché il codice è meno omogeneo.

Le segnalazioni di difetti crescono sui moduli nuovi.

Qualcuno trova una SQL injection in un servizio scritto da un collega, generato con un prompt che non nominava la parametrizzazione delle query.

Il tech lead sospetta, ma non ha uno straccio di dato per dimostrare niente in una riunione.

Tra il quindicesimo e il ventiquattresimo mese arriva il fatto.

Un audit di sicurezza che trova vulnerabilità sistematiche sui moduli recenti, oppure la scoperta che il sorgente del modulo di pricing è finito su ChatGPT gratuito, oppure una funzionalità richiesta dal business che non si riesce ad aggiungere senza tre settimane di rifattorizzazione.

A quel punto la governance si scrive di corsa, con il consiglio di amministrazione che guarda.

Nei casi che ho seguito, la governance del Vibe Coding costruita oggi costa circa un quinto di quella costruita dopo il primo incidente di sicurezza.

La reazione istintiva, a questo punto, è vietare tutto.

È anche il modo più veloce per perdere il pezzo di valore che il Vibe Coding porta davvero, e che nel frattempo il tuo concorrente si sta tenendo.

Come distinguere uso legittimo da uso pericoloso: il criterio

C'è un modo semplice per capire se un pezzo di codice si può generare a occhi chiusi, e non riguarda la difficoltà tecnica.

Riguarda una domanda sola: quanto costa scoprire l'errore tardi?

Il Vibe Coding è sicuro dove l'errore si vede subito e costa poco, ed è pericoloso dove l'errore resta invisibile per mesi e ha un prezzo diretto in denaro, in dati personali o in accessi non autorizzati.

Non è la complessità a spostare l'ago, è la reversibilità.

Dove conviene incoraggiarlo

La prototipazione rapida di funzionalità non critiche è il caso ideale.

Quando devi esplorare un approccio architetturale, montare una prova di fattibilità o mostrare qualcosa al business prima di investire nella versione vera, il Vibe Coding accorcia il ciclo in modo brutale.

Quel codice non va in produzione: è un veicolo per capire, e si butta.

La generazione dei test unitari è l'altro caso ad alto valore e rischio quasi nullo.

Chiedere cinquanta casi di test per un metodo che esiste già, coprendo i limiti che hai identificato tu, non introduce nessun rischio architetturale: il codice da testare c'è, la correttezza è verificabile subito, e se il test è sbagliato lo vedi in trenta secondi.

Poi c'è tutto quello che non è eseguibile: documentazione tecnica, commenti XML sulle API, file README dei moduli, descrizione dei flussi.

Uno sviluppatore .NET che genera la documentazione di un'API ASP.NET Core complessa si risparmia ore senza esporsi a niente.

E infine lo scaffolding: la generazione automatica delle parti più standard del progetto, come le operazioni CRUD, le migrazioni di Entity Framework per creare o modificare il database e i controller di base.

Pattern ripetitivi e prevedibili, che una revisione veloce valida senza fatica.

Dove serve una revisione obbligatoria, o un divieto

Il codice di autenticazione e autorizzazione non va in produzione senza la lettura di qualcuno che di sicurezza se ne intende.

Non perché il modello non sappia generare un login funzionante, ma perché i dettagli che rendono sicura un'implementazione, gestione delle sessioni, protezione CSRF, validazione e revoca dei token, dipendono da un contesto applicativo che un prompt generico non trasmette.

Stesso discorso per il codice che tratta dati personali ai sensi del GDPR, che implementa le logiche di consenso o interroga tabelle con dati sensibili: lì non serve una revisione stilistica, serve una revisione di conformità, e la fa solo chi sa cosa sta cercando.

Poi c'è la logica di business con impatto economico diretto, cioè calcoli di prezzo, regole di sconto, fatturazione, algoritmi che influenzano le conversioni.

Questi moduli si scrivono capendo, non delegando, perché il modello non conosce le regole di business che ci stanno sotto e non ha modo di sapere quando il risultato è plausibile ma sbagliato.

E chiudono la lista le integrazioni verso l'esterno, le API dei partner, i webhook che ricevono eventi dai sistemi di pagamento: ogni integrazione apre una superficie di attacco che richiede di conoscere protocollo, gestione degli errori e politiche di sicurezza dell'altro sistema.

Sapere dove sta il confine, però, non basta a farlo rispettare.

Serve qualcosa che uno sviluppatore possa applicare da solo, alle sette di sera, senza chiamare il tech lead.

Il framework operativo: come si applicano le tre zone di rischio

"Usate il Vibe Coding con giudizio" è la regola che ho letto più spesso, ed è anche quella che non ha mai fermato niente.

Il giudizio di chi, misurato su cosa, alle sette di sera di un giovedì?

Il framework a tre zone traduce il confine in una regola applicabile da solo: verde dove si genera liberamente, giallo dove si genera ma la revisione di un senior è obbligatoria, rosso dove il modello si consulta ma l'implementazione la scrivi tu.

Il colore lo decide il modulo, non lo strumento.

Zona verde: Vibe Coding incoraggiato

Prototipi e verifiche tecniche, test unitari e dati di prova, documentazione e commenti sulle API, scaffolding CRUD e codice ripetitivo standard, script di migrazione su dati non sensibili, componenti di interfaccia senza stato e senza logica di business.

Qui lo sviluppatore genera liberamente, con qualunque strumento approvato dalla policy, senza revisioni aggiuntive rispetto alla normale code review.

La zona verde non è una concessione: è la parte che ti ripaga l'investimento, ed è il motivo per cui il divieto totale è una scelta cara.

Zona gialla: Vibe Coding con revisione obbligatoria

Servizi di dominio non critici, moduli di integrazione con sistemi interni, componenti di reportistica e analisi, algoritmi di elaborazione non finanziari, moduli di notifica e comunicazione.

È la zona più abitata e la più fraintesa.

Qui il Vibe Coding è permesso, ma ogni pull request che contiene codice generato su questi moduli richiede la revisione di un senior con attenzione esplicita agli aspetti architetturali, non solo alla correttezza funzionale.

La differenza tra le due letture è tutta qui: la prima chiede "funziona?", la seconda chiede "assomiglia al resto del sistema?".

Zona rossa: divieto senza supervisione diretta

Moduli di autenticazione e autorizzazione, codice che tratta dati personali soggetti a GDPR, logiche di business con impatto economico diretto, integrazioni con sistemi di pagamento, moduli di sicurezza e crittografia.

Qui la generazione autonoma è vietata.

Il modello resta uno strumento di consultazione, e la domanda giusta somiglia a "come si implementa correttamente il flusso PKCE in ASP.NET Core Identity?": la risposta la leggi, la capisci, e l'implementazione la scrivi tu riga per riga.

Non è diffidenza verso la tecnologia, è la stessa regola che applichi da vent'anni al codice che tocca i soldi.

Le tre zone, messe una accanto all'altra, si riconoscono da tre domande:

Tre zone su una lavagna, però, restano tre zone su una lavagna.

Il passaggio che quasi tutte le aziende sbagliano è il documento che le rende operative, e si sbaglia sul formato prima ancora che sul contenuto.

Come scrivere una Vibe Coding policy aziendale concreta in cinque sezioni

Quasi tutte le policy sull'AI che girano nel 2026 hanno lo stesso difetto: sono scritte da avvocati per avvocati.

Troppo generiche per essere operative, troppo lunghe per essere lette, troppo legali per essere rispettate spontaneamente.

Una policy che funziona per un team di sviluppo ha cinque sezioni, entra in due pagine A4 ed è scritta in un linguaggio tecnico diretto che uno sviluppatore legge in dieci minuti senza ambiguità.

Le cinque sezioni sono, in ordine: strumenti, dati, revisione, formazione, misura.

Sezione 1: strumenti approvati e livelli di utilizzo

L’elenco degli strumenti consentiti deve essere esplicito e aggiornato periodicamente, per esempio ogni sei mesi.

Per un team .NET nel 2026, una classificazione realistica potrebbe essere questa:

• Approvati per lo sviluppo su codice aziendale: GitHub Copilot Business o Enterprise per il lavoro quotidiano direttamente in Visual Studio, VS Code e GitHub; Claude Code per analizzare repository, effettuare refactoring e lavorare su attività che coinvolgono molti file; OpenAI Codex per delegare modifiche più articolate al codice, eseguire test e preparare modifiche da sottoporre a revisione; Cursor Enterprise per i team che adottano un ambiente di sviluppo fortemente orientato all’AI.
• Approvati per attività generali: ChatGPT Enterprise e Claude nelle rispettive configurazioni aziendali possono essere utilizzati per documentazione, analisi tecnica, progettazione, revisione di specifiche e attività che non richiedono necessariamente un agente direttamente collegato al repository.
• Approvati con restrizioni: account individuali come ChatGPT Plus, Claude Pro, Cursor individuale o altri servizi AI non gestiti centralmente dall’azienda. Possono essere usati per esempi generici, codice pubblico e problemi tecnici che non contengono informazioni riservate.
• Non approvati: versioni gratuite o account personali non autorizzati quando comportano l’invio di codice aziendale, modelli locali installati senza approvazione dell’IT e, più in generale, qualsiasi strumento non presente nell’elenco aziendale.

La distinzione non dipende soltanto dalla qualità del modello.

Conta soprattutto ciò che l’azienda può controllare: trattamento e conservazione dei dati, accesso ai repository, autenticazione, amministrazione centralizzata, audit e possibilità di stabilire quali modelli, agenti e funzionalità siano consentiti.

Gli strumenti della fascia intermedia possono quindi essere usati per codice generico, esempi pubblici o problemi tecnici non proprietari, ma non devono ricevere il sorgente dell’applicazione, dati dei clienti, credenziali, documentazione interna o logica di business riservata.

Sezione 2: classificazione dei dati condivisibili

Questa sezione risponde alla domanda che uno sviluppatore si fa davanti al prompt vuoto: questo posso incollarlo o no?

Con qualunque strumento approvato si condivide codice open source o basato su librerie pubbliche senza personalizzazioni, frammenti tecnici generici senza riferimenti al dominio aziendale, domande architetturali astratte e documentazione già pubblica.

Solo con strumenti enterprise si condivide il sorgente dei moduli applicativi standard, le strutture di database anonimizzate, le specifiche interne non competitive.

Non si condivide mai, con nessuno strumento in cloud, l'algoritmo di pricing e le logiche di sconto, il codice che contiene o richiama dati dei clienti, credenziali, chiavi API, segreti di configurazione, e qualsiasi file marcato come confidenziale o proprietario nei commenti.

Sezione 3: il processo di revisione per il codice generato

Tutto il codice prodotto con Vibe Coding che entra in una pull request passa da una revisione umana prima del merge, senza eccezioni.

La regola non è negoziabile per un motivo che è bene ripetere ad alta voce in riunione: la responsabilità del codice è sempre di chi fa il commit, mai del modello che l'ha scritto.

Sopra il 30% di codice generato, su moduli in zona gialla o rossa, la revisione di un senior formato sulla sicurezza del codice AI diventa obbligatoria.

E chi apre la pull request dichiara nella descrizione quale percentuale è stata generata e con quale strumento.

Non è un cartellino da timbrare: è l'informazione che permette al revisore di calibrare l'attenzione invece di leggere tutto allo stesso modo.

Sezione 4: formazione obbligatoria

L'adozione senza formazione produce il risultato peggiore possibile: persone con uno strumento potente in mano, senza gli anticorpi per valutare cosa gli sta restituendo.

Il minimo è un laboratorio pratico di quattro ore entro trenta giorni dall'adozione, con dentro i rischi specifici del codice generato mostrati su esempi veri e non in teoria, la dimostrazione di come si riconoscono i problemi più comuni, l'esercizio sui casi ad alto valore dove il Vibe Coding accelera senza rischi, e la discussione delle regole con spazio per le domande tecniche.

Quattro ore, una volta, per tutti.

Sezione 5: metriche di audit e revisione periodica

Una policy senza misurazione è una dichiarazione d'intenti.

Ogni mese il tech lead guarda quattro numeri: la percentuale di pull request con codice generato, il tasso di richieste di revisione significativa su quelle pull request, l'andamento della densità di difetti sui moduli nuovi rispetto al periodo precedente l'adozione, e i risultati dell'analisi statica sul codice generato rispetto a quello scritto a mano.

La policy stessa si rivede ogni sei mesi, perché gli strumenti cambiano, i piani contrattuali cambiano e i rischi si spostano.

Una policy ferma al giorno dell'adozione è inapplicabile entro un anno.

Restano da scegliere gli strumenti da mettere nella prima sezione.

Ed è qui che quasi tutti scelgono con il criterio sbagliato, cioè il più famoso invece del più adatto al lavoro.

La policy che hai appena letto la copi in due pagine A4 entro stasera.

Il problema arriva lunedì, quando uno sviluppatore ti chiede se il suo modulo è zona gialla o rossa e la risposta dipende da una valutazione architetturale che il documento non contiene.

Scrivere le regole è la parte facile.

Applicarle è un mestiere.

Quel mestiere è il contenuto del Corso Architetto Software Ai: classificare i moduli per rischio reale, difendere la scelta davanti al team e davanti a chi firma il budget.

Quattro strumenti, quattro mestieri: il criterio di scelta per un team .NET

Un CTO mi ha detto che avevano standardizzato su un unico strumento "per semplicità".

Sei mesi dopo pagavano l'abbonamento più caro del mercato per farci scrivere i test, e le decisioni architetturali continuavano a prenderle a occhio.

Per un team .NET non esiste lo strumento migliore: esistono quattro strumenti che fanno mestieri diversi, e la scelta si fa incrociando il tipo di lavoro con la zona di rischio in cui quel lavoro cade.

GitHub Copilot Business ed Enterprise

È il punto di partenza per chi lavora in Visual Studio o VS Code, e il motivo è l'integrazione: Copilot vive nel contesto esatto in cui lavori, vede i file aperti, conosce le dipendenze del progetto, propone codice coerente con i namespace e i tipi che hai già.

Il piano Business, a 19 euro per sviluppatore al mese, garantisce la privacy.

Il piano Enterprise, a 39 euro, aggiunge la base di conoscenza aziendale e i modelli specializzati sulla vostra base di codice.

Sul Vibe Coding in senso stretto, però, è lo strumento meno adatto: lavora soprattutto sul completamento e non regge bene le sessioni di generazione di moduli interi.

Il suo mestiere è accelerare chi sa già cosa scrivere, non progettare al posto tuo.

Claude for Enterprise

Nelle versioni 3.5 e 3.7 è diventato il riferimento per le sessioni di Vibe Coding più ambiziose: generazione di moduli completi, revisioni architetturali, analisi di problemi di design complessi.

Ragiona su sistemi distribuiti, individua dipendenze circolari, propone pattern adatti a scenari .NET specifici, e su questo tipo di compito la distanza dalla concorrenza si sente.

Claude for Enterprise garantisce zero addestramento sui dati e zero condivisione delle conversazioni, ed è una garanzia che qui non è un dettaglio contrattuale: in queste sessioni devi passare contesto applicativo vero per ottenere qualcosa di utile.

Il costo è paragonabile agli altri piani enterprise dei fornitori principali.

Cursor come ambiente di sviluppo costruito attorno all'AI

Ha guadagnato terreno tra chi lavora su VS Code e non su Visual Studio 2022.

Il vantaggio rispetto a Copilot è la profondità del contesto: mentre Copilot vede i file aperti, Cursor può indicizzare l'intero progetto e rispondere a domande come "trova tutti i punti dove stiamo scavalcando il middleware di autenticazione" oppure "genera un modulo che segue lo stesso pattern del servizio X".

Su rifattorizzazione di codice legacy .NET l'esperienza è superiore.

E su generazione di funzionalità nuove dentro un sistema già definito c'è un effetto collaterale prezioso: rispettando i pattern esistenti, Cursor riduce in modo sensibile proprio il problema dell'incoerenza architetturale, che è il terzo dei quattro rischi.

ChatGPT Enterprise

Resta il più usato per familiarità, non per superiorità tecnica, e il piano Enterprise offre garanzie di privacy adeguate.

Funziona bene per generare documentazione tecnica, spiegare pattern architetturali complessi e fare da consulente su problemi di design.

Sulla generazione di codice .NET complesso in sistemi enterprise, Claude è in genere più capace sui compiti di alta complessità.

Quattro strumenti scelti bene riducono il rischio.

Nessuno dei quattro, però, ti dice se il codice che è appena entrato nella pull request contiene una vulnerabilità: per quello serve qualcosa che non si stanca e non ha fretta.

Come integrare il SAST nel processo CI/CD per il codice generato dall'AI

Venerdì pomeriggio, quattro pull request aperte, il senior che dovrebbe leggerle è in trasferta dal cliente.

La governance basata sulla vigilanza umana funziona benissimo finché la giornata è normale, e le giornate normali sono poche.

L'analisi statica del codice integrata nella pipeline, il SAST, è la difesa tecnica più importante contro le vulnerabilità introdotte dal Vibe Coding: non sostituisce la revisione umana, ma intercetta in modo sistematico i problemi più comuni prima che arrivino a un revisore stanco.

SonarQube per team .NET enterprise

Nel piano Developer Edition ha il supporto più maturo per C# e per l'ecosistema .NET.

Le regole specifiche per ASP.NET Core riconoscono le query costruite per concatenazione, le credenziali scritte nel codice, l'uso insicuro della reflection, la validazione mancante negli input dei controller.

L'integrazione con Azure DevOps e GitHub Actions è consolidata e chiede una configurazione minima a chi è già su quegli strumenti.

Il pezzo che conta per la governance è il Quality Gate: puoi bloccare automaticamente il merge quando il codice introdotto contiene vulnerabilità di gravità alta, senza distinguere se lo ha scritto una persona o un modello.

Il vantaggio politico è enorme, perché toglie la decisione dalle spalle del revisore: non è più lui che dice di no al collega, è la pipeline.

Snyk per la sicurezza delle dipendenze

C'è un rischio secondario che quasi nessuno mette in conto: i modelli tendono a suggerire versioni di pacchetti NuGet che non sono le più recenti e a volte hanno vulnerabilità note, perché statisticamente sono le più citate.

Snyk, inserito nella pipeline, scansiona le dipendenze introdotte in ogni pull request, segnala i pacchetti con CVE note e propone la versione sicura.

Per un team .NET su Azure DevOps l'integrazione chiede circa mezza giornata di configurazione e produce valore da subito: ogni pull request che introduce una dipendenza vulnerabile viene bloccata prima ancora della revisione umana.

Configurazione minima consigliata per la pipeline

Chi parte da zero non deve fare tutto insieme, e la sequenza conta:

1. Settimana 1: SonarQube in modalità informativa, per fotografare le vulnerabilità già presenti.
2. Settimana 2: Quality Gate attivo sulle severità Critical e Blocker, ma solo sul codice nuovo.
3. Mese 2: Snyk in pipeline sulle dipendenze.
4. Mese 3: lettura dei report per capire quali vulnerabilità ricorrono nel codice generato dal tuo team, e formazione ritarata su quelle.

Per un team da cinque a dieci persone il costo di questo insieme di strumenti sta tipicamente tra 200 e 400 euro al mese.

Rientra al primo incidente evitato, e nel frattempo produce un effetto collaterale che vale ancora di più: i primi numeri veri su cui costruire una discussione con il management.

Come misurare l'impatto del Vibe Coding nel team: le metriche operative

"Secondo me stiamo andando più veloci."

È la frase che ho sentito in ogni azienda che ha adottato l'AI senza misurare niente.

Ed è anche la frase che, in consiglio di amministrazione, non regge trenta secondi.

Le metriche che servono per governare il Vibe Coding sono quattro, e vanno lette insieme: la velocità segmentata per tipo di lavoro, la densità di difetti, il tempo di revisione e le vulnerabilità trovate.

Una sola di queste quattro, letta da sola, mente.

Velocità reale, segmentata per complessità

È la metrica più attesa dal business e la più facile da truccare senza volerlo.

Misura i punti storia completati per sprint prima e dopo l'adozione, ma solo se li separi per tipo di lavoro: l'aumento sul codice ripetitivo e sui CRUD può nascondere un peggioramento sui compiti complessi, dove il Vibe Coding non aiuta e a volte rallenta per il tempo di validazione che aggiunge.

Segmentando per complessità e tipo, cioè funzionalità nuove, manutenzione, rifattorizzazione e test, l'aspettativa realistica sui dati disponibili nel 2026 è un aumento tra il 30% e il 50% sui compiti a bassa complessità, tra il 10% e il 20% su quelli intermedi, e un impatto neutro o leggermente negativo su quelli complessi.

Densità di difetti sul codice generato

Misura il numero di difetti per unità di codice, tipicamente mille righe o una funzionalità completata.

Per essere utile va segmentata in tre: codice scritto interamente a mano, codice prevalentemente generato, codice ibrido con revisione significativa.

Raccogliere questo dato chiede che ogni pull request dichiari il metodo di produzione, il che aggiunge un piccolo attrito di processo e restituisce l'unica informazione che permette di capire se la policy sta funzionando.

La lettura è semplice: se dopo tre mesi di governance la densità di difetti sul codice generato si avvicina a quella del codice manuale, la policy funziona.

Se resta molto più alta, il problema è nel processo di revisione, non negli strumenti.

Tempo di revisione, il costo che nessuno mette a budget

Il Vibe Coding non elimina il tempo di code review: spesso lo aumenta.

Chi rivede si trova davanti codice che non conosce il contesto architetturale, che può usare pattern diversi da quelli concordati e nomi che non seguono le convenzioni.

Il tempo medio di revisione su pull request ad alta densità di codice generato è tipicamente dal 20% al 40% superiore rispetto a pull request equivalenti scritte da un senior del team.

Misurarlo serve a fare il conto vero: se il team produce il doppio del codice ma il tempo di revisione triplica, il ritorno netto può essere negativo.

La governance esiste per ottimizzare questo scambio, non per far finta che non ci sia.

Vulnerabilità trovate, la metrica che decide

Le vulnerabilità rilevate dall'analisi statica e dai test di penetrazione, separate tra codice generato e codice manuale, sono il dato più critico.

Se il codice generato è il 30% del totale ma produce il 60% delle vulnerabilità, la policy va rafforzata prima che il problema arrivi in produzione, non dopo.

Al management questo numero va portato per quello che è: non la prova che il Vibe Coding sia pericoloso, ma il dato operativo che dice dove intervenire su revisione e formazione.

Ed è anche il numero che, letto per tre trimestri di fila, comincia a raccontare una storia diversa: non su quanto codice produce il team, ma su chi in quel team sta diventando insostituibile.

Il Vibe Coding cambierà i profili degli sviluppatori .NET richiesti in azienda

C'è un colloquio che nel 2024 sarebbe finito con un'offerta e oggi finisce con un "la ricontattiamo".

Persona brava, veloce, precisa nell'implementare le specifiche.

Nessuna domanda posta sull'architettura, in un'ora e mezza.

Il Vibe Coding sposta il valore dalla velocità di scrittura alla capacità di giudizio: perde terreno chi produce codice meccanico su specifiche chiare, guadagna terreno chi sa definire il problema, valutare criticamente il risultato e progettare prima di delegare.

Il profilo che perde valore relativo

Chi genera valore soprattutto attraverso la velocità di scrittura di codice meccanico, l'implementazione fedele di specifiche chiare, la produzione di codice ripetitivo e CRUD, vede la propria utilità marginale ridursi.

Non perché non sappia programmare, ma perché la parte che fa meglio è esattamente quella che il Vibe Coding automatizza a costo quasi zero.

Il junior assunto per "scrivere codice" scopre che quella parte viene fatta meglio e più in fretta.

Il profilo intermedio che si distingueva per la rapidità sulle funzionalità standard perde il vantaggio su quella dimensione.

E chi non ha mai costruito capacità di ragionamento architetturale o di valutazione critica si ritrova in una posizione scomoda, senza che nessuno gliel'abbia detto in tempo.

Il profilo che aumenta di valore

Chi sa definire con precisione i requisiti per guidare il modello, chi sa leggere il codice generato e vedere in trenta secondi dove si romperà, chi progetta a livello di sistema prima di delegare l'implementazione: questo profilo diventa raro e caro, e lo diventa in fretta.

Il Vibe Coding premia le persone che ragionano come architetti anche senza averne il titolo.

Le domande che contano sono diventate "qual è il pattern giusto per questo scenario?", "dove sono i rischi di sicurezza in questa architettura?", "come evolvono questi moduli nei prossimi diciotto mesi?".

Non sono domande che i modelli attuali chiudono da soli, e sono esattamente quelle che separano un senior da qualcuno che ha semplicemente sette anni di anzianità.

Implicazioni per la formazione del team

Le aziende che investono adesso nella formazione architetturale delle proprie persone, prima che sia il mercato a costringerle, si costruiscono un vantaggio che si consolida ogni trimestre.

Una persona formata a valutare criticamente il codice generato, a riconoscere i rischi di sicurezza nei risultati e a guidare la generazione con consapevolezza architetturale è più produttiva e più sicura di una che usa gli stessi strumenti senza quella formazione.

La formazione che fa la differenza non è "come usare Claude" e non è "come scrivere prompt migliori": quella scade in sei mesi.

È formazione su architettura software, pattern di sicurezza e principi di design, cioè esattamente la formazione che un architetto software riceve e che nell'era del Vibe Coding serve a tutti i senior.

La differenza tra le due cose, sul curriculum di una persona, si vede a distanza di due anni.

Sul bilancio dell'azienda si vede prima.

Rileggi le tre domande di poche righe fa: qual è il pattern giusto, dove sono i rischi di sicurezza, come evolvono questi moduli in diciotto mesi.

Se oggi ne sai rispondere due su tre, sei già più avanti del tuo team.

Se le tre risposte le sai difendere davanti a un CTO, sei nel profilo che le aziende cercano e non trovano.

Il Corso Architetto Software Ai nasce per portarti da due su tre a tre su tre, con il metodo e non con l'intuito.

Il ROI della governance del Vibe Coding: i numeri reali

Il momento in cui questa conversazione si decide non è tecnico.

È la riunione in cui qualcuno chiede quanto costa mettere ordine, e la risposta deve stare su una slide.

La governance strutturata del Vibe Coding costa tra 8.000 e 10.000 euro l'anno per un team di otto sviluppatori .NET, contro benefici di produttività quantificabili intorno ai 48.000 euro l'anno.

Il ritorno è tra 5 e 6 volte, senza contare la prevenzione degli incidenti.

Il costo si compone di quattro voci, tutte verificabili.

GitHub Copilot Enterprise per otto persone fa 39 euro per otto per dodici mesi, cioè 3.744 euro l'anno.

SonarQube Developer Edition costa intorno ai 3.000 euro l'anno per team fino a dieci persone.

La formazione iniziale, quattro ore per tutto il team condotte internamente con materiali già pronti, vale tra 800 e 1.200 euro di costo opportunità.

L'attrito di processo, cioè revisioni più strutturate e metriche mensili, pesa due ore al mese sul tech lead e mezz'ora al mese a testa.

Il beneficio si calcola in modo volutamente conservativo: un aumento del 20% di produttività sulle sole attività in zona verde, per otto sviluppatori a un costo pieno di 50 euro l'ora, vale 20 ore recuperate a settimana, che per 48 settimane e 50 euro l'ora fanno 48.000 euro l'anno.

Poi c'è la parte che non entra nel calcolo ma pesa di più: un singolo incidente di sicurezza di dimensioni medie costa tra 85.000 e 250.000 euro secondo la stima SANS del 2025, tra indagine, rimedio, eventuale notifica al Garante e danno reputazionale.

E il debito tecnico evitato vale a sua volta da 3 a 5 volte il costo di non averlo generato, perché una rifattorizzazione non pianificata si paga sempre al prezzo di listino.

Una precisazione, perché quel 5x va difeso davanti a un CFO che fa domande.

Il 20% di produttività in più non arriva dallo strumento: arriva dallo strumento più le regole più le persone formate a usarlo.

Togli uno dei tre pezzi e il numero non regge.

Il costo vero della governance del Vibe Coding non è la governance: è la sua assenza nel giorno esatto in cui si verifica l'incidente che l'avrebbe giustificata.

il Vibe Coding è già in produzione nel tuo team: come governarlo

Nella maggior parte dei team italiani il dibattito sul "se adottarlo" si è chiuso da solo, con una risposta di fatto: gli sviluppatori lo usano già, tutti i giorni.

Quello che resta da decidere non è il permesso, è la struttura.

I rischi sono quattro e sono quantificabili: vulnerabilità nel codice generato, proprietà intellettuale che esce verso modelli non enterprise, debito tecnico accelerato dall'incoerenza architetturale, processi non dimostrabili davanti a GDPR e NIS2.

Non sono ipotesi da conferenza: sono meccanismi che si attivano in modo prevedibile in ogni azienda senza regole, con un calendario che ormai conosciamo mese per mese.

I benefici sono altrettanto reali, ma vivono solo dentro una struttura: la produttività cresce sulle zone giuste, il tempo di rilascio si accorcia sulle funzionalità non critiche, il team può esplorare tre approcci architetturali prima di sceglierne uno.

Serve però una policy che dica dove si può generare, con quali strumenti, chi rivede e come si misura.

È il primo mattone di un lavoro più largo, l'adozione strutturata dell'AI nei team di sviluppo, perché le stesse quattro domande tornano identiche il giorno in cui l'AI arriva sui test, sul rilascio e sul supporto.

Le aziende che costruiscono la governance del Vibe Coding oggi, prima che un incidente le obblighi a farlo in emergenza, ottengono un vantaggio competitivo strutturale sui concorrenti che arriveranno alla governance 18 mesi dopo e con costi tripli.

Il Vibe Coding senza governance è una fabbrica di debito tecnico con le vulnerabilità incluse nel prezzo.

Con la governance è un moltiplicatore che cambia il passo del tuo team.

La differenza non sta nella tecnologia, che è la stessa per tutti: sta nel processo che ci costruisci attorno, e nelle persone che sanno leggere il codice che quella tecnologia produce.

Non è un caso che la figura dell'architetto software stia tornando centrale proprio adesso, dopo anni in cui in parecchie aziende italiane era rimasta un titolo sul biglietto da visita.

Ed è il punto in cui la decisione smette di riguardare gli strumenti e comincia a riguardare te.

C'è chi passerà i prossimi due anni a governare un fenomeno che ha capito, e c'è chi li passerà a rincorrere pull request che non sa più leggere.

Torna alla pull request da quattrocento righe dell'inizio, quella con i nomi in inglese e la stessa cosa fatta in tre modi.

Tra sei mesi la riapre qualcuno del tuo team, e la differenza tra una revisione da dieci minuti e tre settimane di rifattorizzazione non la fa il modello che l'ha generata: la fa chi la legge.

Le regole che hai letto qui le scrivi in due pagine entro venerdì.

Il giudizio per applicarle, quello si costruisce, ed è il lavoro che facciamo nel Corso Architetto Software Ai.

Il codice generato sta già entrando nella tua base di codice, oggi, mentre leggi questa riga.

L'unica cosa ancora da decidere è se tra due anni sarai la persona che quel codice lo governa, o quella che lo rincorre.