# Il vibe coding è sicuro? Cosa ha trovato un banco di prova di 186 compiti reali

> Tra dodici configurazioni di agenti, quella che più spesso ha prodotto codice funzionante vi è riuscita nel 57 % dei compiti; solo nell'11,8 % dei compiti il suo codice funzionava e insieme superava il test di sicurezza. Informare l'agente del rischio ha aiutato un poco. Lo studio poteva verificare ciascun difetto perché era già stato trovato e corretto, e la correzione era accompagnata da un test di sicurezza. Il nuovo codice del vostro agente non ha ancora un test del genere.

Source: https://counterproof.io/it/notes/il-vibe-coding-e-sicuro/ · Published 28 September 2026 · CounterProof è una practice di Clavestra Capital Limited (Malta, C 113987).


**Nello studio, la configurazione di agenti che più spesso ha prodotto codice funzionante vi è riuscita nel 57 % dei compiti. Solo nell'11,8 % dei compiti il suo codice funzionava e insieme superava il test di sicurezza.** Tra le sue soluzioni funzionanti, il 79,3 % non superava comunque un test di sicurezza. Quando gli agenti non ricevevano indicazioni sulla sicurezza, nessuna configurazione ha prodotto, in più del 12,9 % dei compiti, codice che funzionava e insieme superava il test di sicurezza.

Queste sono le [cifre principali](https://counterproof.io/glossary/#benchmark-score). Per capire cosa significano, bisogna guardare a come è stato costruito il banco di prova.

Lo studio è *Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks* (Zhao, Wang, Zhang, Luo, Li e Li, ICML 2026, arXiv:2512.03262).

## Cosa ha fatto il banco di prova

Gli autori hanno costruito 186 compiti a partire da grandi repository open source su GitHub. Ciascuno partiva da un caso reale: una persona aveva implementato una funzionalità, l'implementazione si era rivelata vulnerabile e la vulnerabilità era stata poi corretta. Nel complesso, i compiti coprono 79 categorie di debolezze della Common Weakness Enumeration di MITRE.

Per ciascun compito, l'agente riceve la base di codice e una descrizione della funzionalità, «senza dettagli di implementazione né indicazioni di sicurezza». Gli viene poi chiesto di implementare la funzionalità. La sua patch viene eseguita contro due insiemi di test scritti da persone. Uno verifica se la funzionalità funziona; l'altro verifica la presenza della vulnerabilità eliminata dalla correzione del progetto stesso.

Gli autori hanno provato tre framework per agenti (SWE-agent, OpenHands e Claude Code) con quattro modelli: Claude 4 Sonnet, Kimi K2, Gemini 2.5 Pro e Gemini 3 Pro. Ne sono risultate dodici configurazioni, ciascuna con un tentativo per compito.

## Cosa ha trovato

- La configurazione che più spesso ha prodotto codice funzionante, SWE-agent con Claude 4 Sonnet, vi è riuscita nel 57,0 % dei compiti. Nell'11,8 %, il codice superava anche il test di sicurezza. Come scrivono gli autori, «il 79,3 % di queste soluzioni funzionalmente corrette non è sicuro».
- OpenHands con lo stesso modello ha mostrato uno schema simile: il 77,8 % delle sue soluzioni funzionanti non era sicuro.
- Claude Code con Claude 4 Sonnet ha prodotto codice funzionante nel 41,4 % dei compiti. Nel 5,9 %, il codice superava anche il test di sicurezza.
- Quando gli agenti non ricevevano indicazioni sulla sicurezza, la quota più alta di compiti risolti in modo sia corretto sia sicuro è stata del 12,9 %, per SWE-agent con Gemini 3 Pro, che ha prodotto codice funzionante nel 37,1 % dei compiti.
- Sulle dodici configurazioni, quella quota è stata in media dell'8,4 % (nostro calcolo dalla tabella 3); gli autori descrivono la media come «solo intorno al 10 %».
- In ciascuna delle dodici configurazioni, la maggior parte delle soluzioni funzionanti non superava un test di sicurezza. La proporzione andava dal 59 % all'86 %, secondo i nostri calcoli sulla tabella 3 dell'articolo.

## Informare l'agente sulla sicurezza ha aiutato un poco

Gli autori hanno provato due prompt sulla configurazione che più spesso ha prodotto codice funzionante. Il primo fornisce all'agente l'elenco completo delle categorie CWE coperte dal banco di prova, con le relative descrizioni. Prima di scrivere codice, l'agente individua quali debolezze il compito possa comportare. Il secondo prompt nomina il tipo o i tipi di debolezza presi di mira dal compito e chiede all'agente di evitare implementazioni vulnerabili.

Con questi prompt, la quota di compiti in cui si è ottenuto codice che funzionava e insieme superava il test di sicurezza è salita dall'11,8 % al 14,5 % e al 15,1 %, rispettivamente. Ma la quota in cui si è ottenuto codice funzionante è scesa dal 57,0 % al 50,0 % e al 55,4 %. Con le parole degli autori, il miglioramento «non attenua in modo sostanziale il problema della sicurezza».

Nella nostra lettura, il secondo prompt dà all'agente un'informazione che un utente non ha ancora. Gli autori osservano che gli esperti umani possono individuare i potenziali rischi di sicurezza prima dell'implementazione; il primo prompt segue quell'approccio. Il secondo nomina il tipo di debolezza che il compito è stato costruito per verificare. Fuori da un banco di prova, quell'informazione diventa disponibile solo una volta che il difetto è stato trovato.

## Il test esisteva perché il difetto era già stato trovato

È la parte del disegno che sottolineeremmo. Ogni compito è accompagnato da un test di sicurezza che gli sviluppatori del progetto hanno aggiunto nel commit che correggeva la vulnerabilità originale. Qualcuno aveva già trovato il difetto, e gli sviluppatori del progetto avevano scritto un test per esso. È quella storia a permettere al banco di prova di verificare la presenza della vulnerabilità. Gli autori hanno poi controllato a mano ogni test di sicurezza e rivisto quelli legati troppo strettamente a una sola implementazione.

La nuova funzionalità del vostro agente non ha un test del genere. La vostra suite di test vi dice ciò che i test funzionali del banco di prova dicevano agli autori: che la funzionalità funziona. Eppure la maggior parte delle soluzioni funzionanti dello studio non superava comunque un test di sicurezza.

Trovare un difetto per il quale nessuno ha ancora scritto un test è il lavoro di una revisione adversariale. La nostra spiegazione della [revisione del codice adversariale](https://counterproof.io/it/revisione-del-codice-adversariale/) espone cosa copre quel lavoro e dove stanno i suoi limiti.

## Modelli diversi evitano difetti diversi

Gli autori riferiscono che «i framework per agenti e gli LLM sono bravi a evitare vulnerabilità diverse». Kimi K2 gestiva meglio gli errori crittografici, mentre Gemini 3 Pro era più bravo ad applicare i controlli di accesso.

Quel risultato riguarda la scrittura del codice. Non stabilisce se un secondo modello coglierebbe i difetti nel lavoro del primo. Né un secondo modello è di per sé un controllo indipendente: quando due modelli sbagliano, [spesso sbagliano allo stesso modo](https://counterproof.io/glossary/#correlated-errors) (Kim et al., ICML 2025). Si veda [*The attacker can run any model. How many do you run?*](https://counterproof.io/notes/the-attacker-can-run-any-model/).

È una delle ragioni per cui non trattiamo l'accordo tra modelli come una prova: l'affermazione che lo sia è una delle [cinque affermazioni che ci rifiutiamo di fare](https://counterproof.io/refusals/).

## Una domanda che lo studio lascia aperta

Ogni compito partiva da una vulnerabilità che una persona aveva introdotto in un progetto reale. Nella maggior parte delle soluzioni funzionanti, gli agenti non superavano il test di sicurezza per quella vulnerabilità. Ma lo studio non si chiede se i modelli avessero incontrato durante l'addestramento la storia di quei progetti, comprese le versioni vulnerabili. Si veda [*The Illusion of the Score*](https://counterproof.io/notes/the-illusion-of-the-score/).

Non può quindi distinguere tra la riproduzione di un difetto incontrato durante l'addestramento e l'arrivo indipendente allo stesso errore. Il nostro documento di ricerca, [Agentic Stemmatics](https://research.counterproof.io/agentic-stemmatics.html), esamina come distinguere queste possibilità.

## Cosa non mostra

- **Tassi di base.** I 186 compiti sono stati scelti perché ciascuno è sensibile per la sicurezza e in passato una persona l'aveva sbagliato. I tassi descrivono quel tipo di funzionalità, non il codice scritto da agenti in generale.
- **Modelli più recenti.** Lo studio ha provato quattro modelli, con un tentativo per compito per ciascuna configurazione. Altri modelli, e versioni successive, possono ottenere punteggi diversi.
- **Revisione.** Lo studio misura un agente che scrive codice senza revisione umana. Non ci dice cosa un team, uno strumento o un revisore coglierebbe in seguito. Si veda [*A Clean Benchmark Is Not a Clean Codebase*](https://counterproof.io/notes/a-clean-benchmark-is-not-a-clean-codebase/) e [*La velocità passa. La complessità resta.*](https://counterproof.io/it/notes/la-velocita-passa-la-complessita-resta/).

Il risultato è limitato, ma chiaro. In questi compiti sensibili per la sicurezza, la maggior parte delle soluzioni funzionanti non superava comunque un test di sicurezza. Una suite di test che verificasse soltanto se la funzionalità funziona non rivelerebbe questa distinzione.

---

*Le citazioni dallo studio di Zhao et al. (ICML 2026, arXiv:2512.03262) sono una nostra traduzione dall'originale inglese. Questa pagina è una traduzione dell'originale inglese; in caso di divergenza prevale l'originale. Se qualcosa qui è errato, lo correggeremo per iscritto su questa pagina.*


## Questions this page answers

**Il vibe coding è sicuro?**

In questo banco di prova, non di per sé. Tra dodici configurazioni di agenti, quella che più spesso ha prodotto codice funzionante vi è riuscita nel 57 % dei compiti; solo nell'11,8 % dei compiti il suo codice superava anche il test di sicurezza, e, quando gli agenti non ricevevano indicazioni sulla sicurezza, nessuna configurazione ha superato il 12,9 %. Ogni compito è stato scelto perché sensibile per la sicurezza, quindi questi tassi descrivono quel tipo di funzionalità, non tutto il codice scritto da agenti.

**Se i miei test passano, il codice è sicuro?**

Superare i test funzionali vi dice che la funzionalità funziona. Nello studio, il 79,3 % delle soluzioni funzionanti di SWE-agent con Claude 4 Sonnet, la configurazione che più spesso ha prodotto codice funzionante, non superava comunque un test di sicurezza.

**Chiedere all'agente di pensare alla sicurezza aiuta?**

Un poco. Un prompt chiedeva all'agente di individuare i rischi a partire da un elenco fornito, prima di scrivere il codice. Un altro nominava il tipo di debolezza da evitare. La quota di compiti con soluzioni che funzionavano e insieme superavano il test di sicurezza è salita dall'11,8 % al 14,5 % e al 15,1 %, rispettivamente. Entrambi i prompt hanno anche ridotto la quota di compiti con soluzioni funzionanti.

**Un secondo modello di IA coglierebbe ciò che il primo non ha visto?**

Lo studio ha misurato la scrittura del codice, non la sua revisione. Ha trovato che modelli diversi evitano debolezze diverse. Se un secondo modello colga i difetti del primo è una questione a parte. Modelli di aziende diverse non sono automaticamente indipendenti.