Vibe coding best practices: quando passare all’agentic coding

Cos’è il vibe coding e in cosa è diverso dall’agentic coding?

Negli articoli precedenti abbiamo spiegato uno alla volta i pezzi di un agente di programmazione: gli hook, i subagent, le skill, i worktree, l’auto mode e la sandbox. Questo articolo li riunisce in un’unica domanda: cosa serve per fare bene vibe coding, e dove si cade in trappola? Descriviamo ogni abitudine in breve e rimandiamo all’articolo che la tratta nel dettaglio.

Il termine l’ha coniato Andrej Karpathy su X il 2 febbraio 2025. Nel suo post, come lo cita Wikipedia, descriveva il suo modo di lavorare: accettava ogni modifica con «Accept All», non leggeva più i diff e incollava i messaggi di errore all’agente senza aggiungere nulla. Con parole sue, per progetti del fine settimana da buttare via non era poi così male. In breve, il vibe coding è far scrivere codice all’IA senza leggerlo e guardare solo il risultato.

Il post di Simon Willison del 6 maggio 2026 traccia il confine con chiarezza. Per lui il vibe coding è lavorare senza guardare affatto il codice: magari non sai nemmeno programmare, dici cosa vuoi e, se funziona, va bene così. In uno strumento che usi solo tu e i cui bug colpiscono solo te non c’è problema. Se invece fai software per altri, il vibe coding è «grossly irresponsible», perché dei tuoi bug pagano gli altri. L’agentic engineering è l’estremo opposto: un ingegnere del software che conosce sicurezza, manutenibilità, operatività e prestazioni usa questi strumenti. Gli strumenti stessi si chiamano strumenti di agentic coding: secondo la definizione di Anthropic, un agente che legge il codice, modifica i file ed esegue comandi. L’agentic coding è quindi il modo di lavorare in cui l’agente scrive ed esegue il codice da solo; la differenza tra vibe coding e agentic engineering sta nel fatto che tu legga il risultato e te ne prenda la responsabilità oppure no.

Anche i consigli di questo articolo poggiano su questo confine. In uno strumento per te, in un prototipo o mentre impari qualcosa, il vibe coding va bene. Il codice che usano altri, che conserva dati degli utenti o che gestisce accessi o pagamenti, invece, non va pubblicato senza averlo letto. Le abitudini che seguono avvicinano il vibe coding a un agentic coding di cui qualcuno si è preso la responsabilità.

Anche in italiano si usa per lo più il termine inglese. Se cerchi il nome generale del programmare con l’IA, è programmazione assistita dall’IA (AI-assisted coding); il vibe coding ne è l’estremo in cui nessuno legge il codice. Ci sono altri due termini che vengono spesso confusi con il vibe coding. Lo spec-driven development è quasi l’opposto: l’agente scrive una spec, un piano e un elenco di compiti prima del codice. L’harness engineering è un altro tema: descrive la struttura che costruisci attorno al modello.

Cosa è cambiato quest’autunno negli strumenti di programmazione?

A settembre e ottobre tutti e cinque gli strumenti sono cambiati nella stessa direzione: l’agente ti chiede meno, lavora da solo più a lungo e più in parallelo. Dalle note di rilascio:

Fonte: note di rilascio degli strumenti, 21 ottobre 2026. Versioni: Claude Code 2.1.284 e 2.1.286, Codex CLI 0.162.0, Antigravity CLI 1.3.5; la riga di Copilot viene dalle versioni di settembre di VS Code. Il 18 giugno 2026 Google ha chiuso Gemini CLI agli abbonati Google AI Pro e Ultra e agli utenti gratuiti e l’ha sostituito con Antigravity CLI; le aziende e chi usa una chiave API a pagamento possono continuare a usare Gemini CLI.

La direzione comune è chiara: l’agente porta avanti un lavoro più a lungo senza chiederti nulla. Alle richieste di approvazione si rispondeva comunque quasi sempre sì senza leggerle; le misurazioni dei fornitori su questo le abbiamo raccontate nell’articolo su auto mode e sandbox. Il controllo vero deve stare nel ciclo dell’agente e funzionare anche quando non stai guardando: un test, un hook, la CI. La modifica verify di Claude Code fa proprio questo: prima del commit fa eseguire il controllo che hai scritto tu.

Cosa dicono le ricerche sulle app fatte in vibe coding?

Ad agosto e settembre sono usciti o sono stati aggiornati tre studi; tutti e tre sono su arXiv, come preprint non ancora sottoposti a revisione paritaria. Il più ampio è lo studio di Deng, Fan e Meng; la sua ultima versione è del 14 settembre 2026. I ricercatori hanno raccolto 9.041 app open source scritte con Claude Code e Lovable, hanno verificato le 200 che erano pubblicate e hanno trovato 1.186 vulnerabilità. Le possibili vulnerabilità le hanno individuate prima degli auditor basati sull’IA; poi due autori esperti di sicurezza le hanno esaminate una per una separatamente, e una contava come vulnerabilità solo se entrambi la ritenevano sfruttabile.

Il risultato: il 91% delle app aveva almeno una vulnerabilità, e il 65,77% delle vulnerabilità era di gravità critica o alta. Si concentrano nel controllo degli accessi (broken access control), nell’injection e nell’autenticazione. Il controllo degli accessi è la parte che garantisce che un utente arrivi solo ai propri dati; se manca, l’app funziona lo stesso, quindi in una demo non si nota.

I ricercatori hanno anche riprodotto una parte di queste vulnerabilità per vedere cosa aiuta. A ridurle di più sono state due cose: un prompt che pone il codice pronto per la produzione come condizione perché il lavoro sia considerato finito, e un harness con controlli di sicurezza aggiunti. Ma nessuna configurazione le ha eliminate tutte. C’è un altro risultato che colpisce: in 90 delle 434 esecuzioni in cui una vulnerabilità è stata innescata (20,7%), l’agente ha notato il rischio da solo e ha scritto lo stesso il codice insicuro; spesso ha lasciato un avviso o un commento invece di correggere. Che l’agente conosca il rischio non basta; il controllo deve girare prima che il lavoro sia finito.

Lo studio di Andročec del 21 agosto 2026 pone una domanda piccola ma diretta. Ha fatto scrivere due volte, in un solo passaggio, ciascuna delle 6 applicazioni web allo stesso agente con lo stesso modello. L’unica differenza tra i due prompt era una sezione di requisiti di sicurezza aggiunta in fondo al secondo. La versione con i requisiti di sicurezza ha avuto meno rilievi confermati in ogni app (24 contro 51), e nessuno era critico o alto. Il rilievo più grave, però, l’ha individuato solo il test manuale. L’autore stesso avverte: il campione è piccolo e ogni versione è stata generata una sola volta; i risultati sono osservazioni, non un effetto statistico.

Lo studio di Kraishan (12 settembre 2026) guarda altrove: cosa succede alle pull request degli agenti dopo il merge? Ha confrontato 37.623 pull request di cinque agenti commerciali con le pull request di persone negli stessi repository. Il risultato è «vendor-specific rather than uniform»: nei 90 giorni dopo il merge, il tasso di revert di 3 dei cinque agenti non si distingueva statisticamente da quello delle persone; uno è stato annullato più di rado, uno più spesso. Pattern sospetti come credenziali scritte nel codice o eval comparivano meno spesso nel codice degli agenti che in quello delle persone; ma questa è una scansione di pattern, non vulnerabilità confermate. I dati vanno da dicembre 2024 a luglio 2025; non dicono nulla sulla classifica degli strumenti e dei modelli di oggi. Come leggere un confronto del genere l’abbiamo spiegato nell’articolo su SWE-bench.

Anche gli sviluppatori si fidano soprattutto di ciò che possono verificare. Nel sondaggio 2026 di Stack Overflow, pubblicato il 6 ottobre (più di 30.000 partecipanti; non un campione casuale ma risposte volontarie), il 48% dei partecipanti ha detto di fidarsi dell’IA quando può verificarne facilmente la risposta. La maggior parte delle abitudini qui sotto serve proprio a renderlo più facile.

Su cosa sono d’accordo le guide dei cinque strumenti?

Tutti e cinque gli strumenti hanno una propria guida alle best practice. Il 21 ottobre 2026 le abbiamo lette tutte e abbiamo messo fianco a fianco i loro consigli sugli stessi temi. Per Copilot abbiamo letto insieme tre guide di GitHub (VS Code, Copilot CLI e l’agente cloud); quella di Cursor è un post del blog del 9 gennaio 2026, le altre non sono datate. In quante guide compare ciascuna delle sei abitudini:

Le cinque guide concordano su 3 abitudini. Le altre 3 le consigliano 4 guide; la guida di Antigravity CLI non ne parla, ma consiglia di avviare subagent in parallelo in background nei lavori grandi, e la CLI ha una vista /diff che mostra le modifiche. Cosa dice ogni guida:

Fonte: guide alle best practice dei cinque strumenti, 21 ottobre 2026. La colonna di Copilot viene dalle guide di VS Code, Copilot CLI e dell’agente cloud di Copilot. Ogni cella riassume la frase della guida. «Non è nella sua guida»: nella guida letta quel giorno non abbiamo trovato una frase che lo dica; può trovarsi in altri documenti dello strumento.

Controllo. L’agente si ferma quando il lavoro sembra finito. Secondo la guida di Claude Code, senza un controllo che possa eseguire, «looks done» è l’unico segnale che ha, e ogni errore aspetta che te ne accorga tu. Test, build, linter o uno script che confronta l’output con un esempio: va bene qualsiasi cosa si legga come superato o non superato. Quando l’agente dice «i test passano», chiedigli il comando che ha eseguito e il suo output. L’agente può controllare un’interfaccia nel browser; come trasformarlo in un test Playwright duraturo l’abbiamo spiegato nell’articolo su computer use.

Piano. Il piano evita che l’agente risolva il problema sbagliato. La guida di Claude Code dice anche quando saltarlo: se riesci a descrivere il diff in una frase, non serve; se non sei sicuro dell’approccio, se la modifica tocca più file o se non conosci il codice, fagli fare un piano. Anche la guida di Cursor ritiene che per i compiti piccoli, già fatti molte volte, si possa passare direttamente all’agente. In una funzionalità grande, il passo oltre il piano è una spec; quando aiuta l’abbiamo spiegato nell’articolo sullo spec-driven development.

File delle regole. Codex e Cursor consigliano la stessa strada: partire con poco e aggiungere una regola quando l’agente ripete un errore. La guida di Codex dice che, quando l’agente fa lo stesso errore due volte, devi chiedergli una retrospettiva e aggiornare AGENTS.md. Quale strumento legge quale file l’abbiamo spiegato nell’articolo su AGENTS.md e CLAUDE.md. Per una regola che deve valere ogni volta, un file non basta; secondo la guida di Claude Code un’istruzione è un consiglio, mentre un hook viene eseguito ogni volta (articolo sugli hook). Un prompt che ripeti di continuo può diventare una skill. Lo stesso file serve anche nella review. Il nostro strumento di code review con l’IA, diffox, quando esamina una pull request legge l’AGENTS.md del repository (o, se manca, il CLAUDE.md) dal branch in cui la pull request verrà unita. Usa le frasi che esprimono un obbligo (come «must», «never», «deve», «vietato») come regole che stabiliscono cosa conta come errore.

Leggere la modifica. La guida di Cursor spiega il motivo in poche parole: il codice scritto dall’IA può sembrare giusto ed essere sbagliato in un dettaglio, e più l’agente è veloce, più conta la review. La guida di Claude Code consiglia di fare la review in un contesto nuovo: un subagent che vede solo il diff e i criteri non si lascia influenzare dal ragionamento della sessione che ha scritto la modifica. Come funziona un subagent l’abbiamo spiegato nell’articolo sui subagent, e cosa deve guardare una persona nell’articolo sulla review del codice generato dall’IA.

Lavoro in parallelo. Due agenti che lavorano nella stessa cartella possono modificarsi a vicenda i file. La guida di Codex considera un errore eseguire compiti paralleli sugli stessi file senza worktree; anche Claude Code, Cursor e Copilot consigliano di eseguire ogni sessione nel proprio worktree o in una cartella a parte. Cosa separa un worktree e cosa no l’abbiamo spiegato nell’articolo su git worktree.

Sessione pulita. Man mano che la conversazione si allunga, il contesto si riempie di dettagli non pertinenti e le prestazioni dell’agente calano. La guida di Claude Code consiglia, se l’agente sbaglia ancora dopo che l’hai corretto due volte sullo stesso punto, di ripulire la sessione e ricominciare con un prompt migliore che includa quello che hai imparato. Cosa si perde riassumendo un lavoro lungo l’abbiamo spiegato nell’articolo sull’auto-compact.

Su cosa le guide non sono d’accordo?

Le guide non dicono la stessa cosa su tutto. Si separano in quattro punti; quale scelta fa per te dipende dal tuo lavoro.

• Quanti dettagli dare all’inizio? Codex chiede quattro cose in ogni prompt: l’obiettivo, il contesto, i vincoli e quando il lavoro si considera finito. La guida dell’agente cloud di Copilot chiede una descrizione chiara, criteri di accettazione completi e quali file cambieranno, ma aggiunge che anche senza percorsi di file l’agente spesso trova da solo il codice giusto. Anche Claude Code chiede di indicare file, vincoli e pattern di esempio. Cursor, invece, dice di taggare il file se lo conosci e di lasciarlo trovare all’agente se non lo conosci; i file non pertinenti possono confonderlo.
• Bisogna correggere tutti i rilievi di una review? La guida di Claude Code avverte: un revisore a cui si chiede di trovare lacune di solito ne trova qualcuna, anche quando il lavoro è solido. Inseguire ogni rilievo porta a livelli inutili, codice difensivo e test per casi che non possono capitare. La guida consiglia di far segnalare al revisore solo le lacune che toccano la correttezza o i requisiti dichiarati. Le guide di Cursor e Copilot presentano gli strumenti di review senza questo avvertimento.
• Quando automatizzare? La guida di Codex considera un errore pianificare un compito ricorrente che a mano non funziona ancora in modo affidabile: prima trasformalo in una skill, poi pianificalo quando è prevedibile. Le novità di quest’autunno, invece, rendono più facile la pianificazione; le automazioni di Copilot e i Projects di Cursor possono eseguire lavori senza che tu lo chieda. Prima di attivarli, fatti la domanda di Codex: questo lavoro funziona in modo affidabile a mano?
• Quali lavori non affidare all’agente? L’unica guida che lo dice apertamente è quella di Copilot. Elenca i lavori che potresti preferire fare tu invece di assegnarli all’agente: problemi critici in produzione; lavori che toccano sicurezza, dati personali o autenticazione; compiti poco definiti e argomenti che vuoi imparare tu. Le altre quattro guide non hanno un elenco del genere.

Quali sono le trappole del vibe coding?

Due guide elencano anche gli errori comuni: quella di Claude Code ha 5 voci, quella di Codex 8. Le due liste si incrociano qui: portare avanti ogni lavoro in un’unica lunga sessione, non dare all’agente un modo per controllare il proprio lavoro e mettere le regole nel posto sbagliato (per Claude Code gonfiare CLAUDE.md, per Codex scrivere regole permanenti in ogni prompt). Una frase della lista di Claude Code sembra il riassunto di questo articolo: se non puoi verificarlo, non pubblicarlo.

Nelle cinque trappole qui sotto siamo caduti noi stessi lavorando con agenti di programmazione nel nostro repository; dopo ognuna abbiamo scritto una regola nel file delle regole del repository. Vengono tutte da un solo repository, quindi non sono una statistica; ma dietro ognuna c’è un errore vero. Le domande che ci facciamo quando l’agente dice «finito»:

• Il test che passa in locale è passato anche in CI? Da noi l’ambiente locale differiva dalla CI in più punti: un file .env letto in locale, il pacchetto installato in modo diverso in CI e un controllo che gira solo in CI. Cancellare le variabili d’ambiente non impediva la lettura del file .env; un’opzione d’installazione mancante, inoltre, ha mostrato in rosso un branch corretto e ha portato a una diagnosi sbagliata. La nostra regola adesso: un risultato locale non viene mai riportato come risultato della CI, un errore della CI si riproduce in un clone pulito senza .env e dopo il push si guarda la CI stessa.
• Il risultato è vuoto perché il passaggio è stato eseguito? In uno dei nostri registri, un’esecuzione pulita e una in cui parte dei passaggi era fallita apparivano identiche; entrambe lasciavano un elenco di rilievi vuoto. Ora il registro conserva anche se i passaggi sono stati eseguiti e quanti risultati hanno prodotto; un risultato vuoto e un passaggio morto si distinguono guardando il registro. Se nel codice dell’agente vedi una riga che intercetta un errore e restituisce una lista vuota, fatti la stessa domanda.
• Un valore mancante è stato letto come 0? Uno dei nostri report ha letto come 0 un valore mai misurato e ha scritto «100% saving» accanto a un lavoro fatto davvero; lo stesso errore ha anche disattivato in silenzio un controllo. Un valore non misurato deve restare None ed essere letto controllando se la chiave esiste:

# Esempio: un valore non misurato deve essere None, non 0
seconds = record.get("seconds") or 0   # sbagliato: se la chiave manca diventa 0
seconds = record["seconds"] if "seconds" in record else None   # giusto

or 0 trasforma in zero sia una chiave mancante sia None. Quello zero finisce poi in una media o in una soglia e fa sembrare gratis o riuscito un lavoro mai misurato.

• Il .env è finito sullo schermo? Una volta abbiamo stampato il file .env mascherato con sed. Siccome non tutte le righe hanno la forma KEY=value, la maschera ha saltato una riga e la chiave che conteneva è comparsa in chiaro. Ora chiediamo all’ambiente se una chiave esiste, non al file; il contenuto del file non si stampa, nemmeno mascherato. Quali strumenti impediscono fin dall’inizio all’agente di leggere i file segreti l’abbiamo spiegato nell’articolo sulla sandbox.
• Il percorso, l’indirizzo o il pacchetto citato esiste davvero? Una delle nostre note di misurazione citava come fonte una cartella che non esiste in nessun branch. In una bozza che completava nomi di file abbreviati, la maggior parte dei nomi completati era sbagliata. Ora uno strumento controlla che ogni percorso in una riga di fonte esista sul disco; anche lo strumento che costruisce questo blog rifiuta un percorso di fonte che non si può aprire. Perché controllare a parte i pacchetti che l’agente propone l’abbiamo spiegato nell’articolo sulla review.

Ciò che hanno in comune tutte e cinque è la differenza tra «finito» e «sembra finito». Il consiglio della guida di Claude Code vale anche qui: chiedi all’agente la prova del successo, non che lo dichiari; il comando che ha eseguito e l’output che ha ottenuto.

Quali abitudini servono per ogni tipo di lavoro?

Non ogni lavoro ha bisogno di ogni abitudine. In una correzione da una frase puoi saltare il piano; nel codice che tocca dati degli utenti non puoi saltare la lettura. A grandi linee, ci sono quattro situazioni:

Ogni situazione nel dettaglio, più qualche caso particolare:

• Uno strumento o un prototipo che usi solo tu. Come dice Willison, se un bug colpisce solo te, il vibe coding va bene. Fai comunque commit spesso per poter tornare indietro, e tieni le chiavi nell’ambiente, non nel codice.
• Una piccola correzione in un repository vero. Salta il piano ma non il controllo; il diff è corto, quindi anche leggerlo è rapido. Se stai correggendo un bug, segui l’ordine della guida di Claude Code: prima un test che riproduce il bug e fallisce, poi la correzione.
• Una funzionalità su più file o codice che non conosci. Prima un piano, e una spec nei lavori grandi; fai scrivere i test prima del codice e fai esaminare la modifica in un contesto nuovo. Quando un modello di fascia alta e più effort fanno la differenza nei lavori lunghi e poco definiti l’abbiamo spiegato negli articoli sulla scelta del modello e sull’effort.
• Esecuzioni non sorvegliate e agenti in parallelo. In auto mode, con un agente cloud o in un lavoro pianificato non c’è nessuno a cui chiedere. Metti il controllo in un hook o nella CI, tieni i permessi stretti, attiva la sandbox, dai a ogni agente il proprio worktree e alla fine chiedi prove, non dichiarazioni. Permessi e sandbox li abbiamo spiegati nell’articolo su auto mode e sandbox.
• Dati degli utenti, accessi, pagamenti e segreti. Scrivi esplicitamente i requisiti di sicurezza nel prompt; nello studio di Andročec, aggiungere solo questo ha ridotto i rilievi in ogni app. Ma il rilievo più grave l’ha individuato comunque il test manuale: questo codice deve leggerlo una persona.
• Prima di aprire a tutti un’app fatta in vibe coding. Le vulnerabilità trovate da Deng e colleghi stanno soprattutto nel controllo degli accessi e nell’autenticazione. Provalo tu: un utente può vedere i dati di un altro? Si arriva a una pagina protetta senza fare l’accesso?
• Un repository che non conosci. Prima di aprirlo con un agente, guarda quali file al suo interno possono eseguirsi da soli; quali sono l’abbiamo spiegato nell’articolo sul workspace trust.