Perché i Modelli Costosi Sono Più Economici

TL;DR

Il modello AI più capace è il 60% più economico per attività nonostante costi il 67% in più per token — perché usa meno token, necessita di meno iterazioni e produce il 50–75% in meno di errori. Per i vibe coder che non sanno leggere il codice, la qualità del modello non riguarda l'efficienza — è l'unica rete di sicurezza nell'intera pipeline.

Ultima verifica: febbraio 2026

I punteggi dei benchmark, i nomi dei modelli e i prezzi in questo articolo riflettono lo stato del campo a febbraio 2026. L'argomento centrale — che il costo per attività conta più del prezzo per token — è duraturo anche quando i numeri specifici cambiano.

Il modello di codifica AI più costoso è quasi sempre l'opzione più economica — quando misuri ciò che conta davvero. Il prezzo per token è una distrazione. Ciò che determina il tuo costo reale è quanti token ci vogliono per portare a termine il lavoro, quante iterazioni consumi e quanto tempo dedichi a revisionare e correggere l'output.

L'Illusione dei Prezzi

Ecco i prezzi API per i modelli Claude:

Modello	Input (per 1M token)	Output (per 1M token)
Claude Opus 4.5	$5	$25
Claude Sonnet 4.5	$3	$15

Opus sembra il 67% più costoso. La maggior parte delle persone si ferma qui e sceglie Sonnet. Quella è la matematica sbagliata.

Cosa Succede Davvero

I benchmark di Anthropic raccontano una storia diversa. Con sforzo medio, Opus 4.5 eguaglia il miglior punteggio SWE-bench di Sonnet 4.5 usando il 76% in meno di token di output. Con il massimo sforzo, Opus supera Sonnet di 4,3 punti percentuali usando il 48% in meno di token.^[1]

Facciamo la matematica reale:

	Sonnet 4.5	Opus 4.5
Token di output per attività	~500	~120
Prezzo per 1M token di output	$15	$25
Costo per attività	$0,0075	$0,0030

Opus è il 60% più economico per attività — nonostante costi il 67% in più per token.^[2]

Questo non è un esempio selezionato ad arte. Nelle attività di codifica a lungo orizzonte, Opus raggiunge tassi di superamento più alti usando fino al 65% in meno di token e facendo il 50% in meno di chiamate agli strumenti.^[1:1]

La Tassa delle Iterazioni

Il costo dei token è solo parte della storia. Il costo maggiore è quello delle iterazioni — quanti round di genera-rivedi-correggi ci vogliono per ottenere codice corretto.

Opus 4.5 raggiunge le prestazioni massime in 4 iterazioni. I modelli concorrenti richiedono fino a 10 tentativi per ottenere una qualità simile.^[1:2] Ogni iterazione fallita ti costa:

• Token — il modello legge il contesto e genera di nuovo
• Tempo — revisioni l'output, trovi il problema, riformuli il prompt
• Attenzione — cambio di contesto tra "è giusto?" e "cosa c'è di sbagliato?"

A una tariffa dello sviluppatore di $75/ora, ogni iterazione fallita che richiede 15 minuti per revisionare e correggere costa $18,75 in tempo umano. Sei iterazioni extra (il divario tra 4 e 10) costano $112,50 in tempo dello sviluppatore — per ogni attività complessa. La differenza nel costo dei token? Circa mezzo centesimo.^[3]

Il risparmio di tempo dello sviluppatore è 22.500 volte la differenza nel costo dei token.

Il Moltiplicatore degli Errori

I modelli più economici non solo richiedono più iterazioni — producono anche più errori che sopravvivono in produzione.

Opus 4.5 mostra una riduzione del 50–75% sia negli errori delle chiamate agli strumenti che negli errori di build/lint rispetto ad altri modelli.^[1:3] Questo è importante perché gli errori che sfuggono alla sessione di codifica diventano drammaticamente più costosi a valle:

• Un bug catturato durante la codifica costa minuti per essere corretto
• Un bug catturato in code review costa un'ora (la tua + quella del revisore)
• Un bug catturato in produzione costa giorni (debug, hotfix, comunicazione, post-mortem)

Lo studio di Faros AI — che copre 1.255 team e oltre 10.000 sviluppatori — ha scoperto che un'elevata adozione dell'AI era correlata a un aumento del 9% dei bug per sviluppatore e un aumento del 91% nel tempo di revisione delle PR.^[4] Quando l'IA genera più codice a una precisione inferiore, il collo di bottiglia della revisione assorbe interamente i guadagni di "produttività".

Un modello che fa le cose bene al primo tentativo evita questa cascata.

Le Evidenze di SWE-bench

SWE-bench Verified è lo standard industriale per valutare la capacità di codifica AI su attività reali di ingegneria del software. La classifica di febbraio 2026:^[5]

Modello	SWE-bench Verified
Claude Opus 4.5	80,9%
Claude Opus 4.6	80,8%
GPT-5.2	80,0%
Gemini 3 Flash	78,0%
Claude Sonnet 4.5	77,2%
Gemini 3 Pro	76,2%

Un divario di 3,7 punti tra Opus 4.5 e Sonnet 4.5 significa che Opus risolve circa 1 attività aggiuntiva su 27 che Sonnet fallisce. Quando ognuno di questi fallimenti innesca una sessione di debug manuale, il costo si accumula rapidamente.

Ma ecco il vero colpo di scena — quando i ricercatori hanno misurato il costo per attività risolta piuttosto che il costo per token, Opus era più economico di Sonnet:

Modello	Costo Per Attività	Punteggio SWE-bench
Claude Opus 4.5	~$0,44	80,9%
Claude Sonnet 4.5	~$0,50	77,2%

Sonnet costa di più per attività risolvendo meno attività.^[6]

Codex CLI: Lo Stesso Pattern, Fornitore Diverso

Il Codex CLI di OpenAI mostra la stessa dinamica con i livelli di sforzo di ragionamento:

• Ragionamento medio: Velocità e intelligenza bilanciate — il default
• Ragionamento extra-alto (xhigh): Pensa più a lungo, produce risposte migliori — raccomandato per attività difficili

GPT-5.1-Codex-Max con sforzo medio supera il GPT-5.1-Codex standard allo stesso sforzo usando il 30% in meno di token di pensiero.^[7] Il modello premium è più efficiente nei token perché ragiona meglio — non ha bisogno di generare tanti passi intermedi per raggiungere la risposta giusta.

Il pattern è universale tra i fornitori: i modelli più intelligenti sprecano meno computazione.

L'Avvertimento di METR

Lo studio randomizzato controllato di METR fornisce un racconto ammonitore cruciale. Sedici sviluppatori esperti ($150/ora) hanno ricevuto 246 attività con strumenti AI. Il risultato: gli sviluppatori erano il 19% più lenti con l'assistenza AI. Ancora più sorprendente — gli sviluppatori credevano di essere il 20% più veloci, un divario di percezione di quasi 39 punti percentuali.^[8]

Lo studio usava modelli della classe Sonnet (Claude 3.5/3.7 Sonnet tramite Cursor Pro), non Opus. Meno del 44% del codice generato dall'AI è stato accettato.

Questo suggerisce che la soglia di qualità è enormemente importante. Un modello che produce codice che accetti il 44% delle volte ti rende più lento — trascorri più tempo a revisionare e rifiutare di quanto risparmi. Un modello con il 50–75% in meno di errori e una precisione al primo tentativo drammaticamente superiore potrebbe ribaltare completamente questa equazione.

Lo studio METR non mostra che gli strumenti di codifica AI sono lenti. Mostra che gli strumenti di codifica AI mediocri sono lenti.

Debito Tecnico: Il 75% che Non Stai Conteggiando

Il costo iniziale della scrittura del codice è solo il 15–25% del costo totale del software nel suo ciclo di vita. Il restante 75–85% va in manutenzione, operazioni e correzioni di bug.^[9]

L'analisi di GitClear del codice prodotto durante il 2020–2024 ha trovato un aumento di 8x nei blocchi di codice duplicato e un aumento di 2x nel code churn correlato all'adozione degli strumenti AI. SonarSource ha trovato un aumento del 93% nei bug di livello BLOCKER confrontando l'output di Claude Sonnet 4 con il suo predecessore.^[10]

Se un modello più economico genera codice con quasi il doppio del tasso di bug gravi, e la manutenzione consuma il 75–85% del costo del ciclo di vita, i "risparmi" sulla generazione del codice sono eclissati dai costi a valle. Il codice più economico da mantenere è il codice che era corretto la prima volta.

Matematica degli Abbonamenti

Per gli utenti intensivi, la scelta abbonamento vs. API amplifica ulteriormente l'argomento della qualità del modello.

Piano	Costo Mensile	Cosa Ottieni
Claude Max ($100)	$100	Alto utilizzo di Opus
Claude Max ($200)	$200	Opus illimitato
Utilizzo API equivalente	$3.650+	Gli stessi token Opus

L'abbonamento è circa 18 volte più economico della fatturazione API per lo stesso lavoro.^[11] Al prezzo dell'abbonamento, non c'è costo marginale per usare il modello migliore — il modello "costoso" diventa letteralmente gratuito per ogni query aggiuntiva.

Costo medio di Claude Code in abbonamento: $6 per sviluppatore al giorno, con il 90% degli utenti sotto i $12/giorno.^[12] A $75/ora di stipendio dello sviluppatore, 5 minuti di tempo risparmiato al giorno pagano l'abbonamento. Tutto il resto è puro ritorno.

L'Argomento Composto

Ecco perché la matematica diventa ancora più sbilanciata nel tempo:

1. Meno iterazioni = meno inquinamento del contesto

Ogni tentativo fallito si aggiunge alla cronologia della conversazione. Le conversazioni lunghe degradano le prestazioni del modello — il rapporto segnale-rumore scende. Un modello che riesce in 4 iterazioni ha un contesto più pulito di uno che si arena per 10, il che significa che anche le sue risposte successive sono migliori.

2. Meno errori = meno affaticamento da revisione

Gli studi di produttività di GitHub Copilot hanno trovato che i benefici aumentano con la difficoltà dell'attività.^[13] Le attività difficili sono quelle dove i modelli economici falliscono di più — e dove i modelli costosi brillano. Il caso studio di ZoomInfo ha mostrato un aumento di produttività del 40–50% con l'AI, con il divario che si allarga man mano che la complessità aumenta.

3. Codice migliore = apprendimento migliore

Se sei uno sviluppatore che sta sviluppando le proprie competenze (e ogni sviluppatore dovrebbe farlo), il codice che leggi plasma i tuoi istinti. Leggere output AI costantemente corretto e ben strutturato insegna buoni pattern. Leggere output pieno di bug e verboso insegna cattive abitudini.

4. Il codice corretto viene distribuito più velocemente

Ogni iterazione di cui non hai bisogno è una funzionalità che viene distribuita prima. Nei mercati competitivi, la velocità di sviluppo — misurata in funzionalità distribuite, non in token generati — è ciò che conta.

Per i Vibe Coder, Questo Non Riguarda il Costo — Riguarda la Sopravvivenza

Tutto quanto sopra si applica agli sviluppatori professionisti che possono leggere i diff, individuare i bug e correggere il codice rotto. Ma c'è un gruppo in rapida crescita per cui l'argomento della qualità del modello non riguarda l'efficienza — riguarda se il software funziona del tutto. Questi sono i vibe coder al 100%: non programmatori che costruiscono applicazioni reali interamente tramite prompt in linguaggio naturale, senza la capacità di leggere, auditare o capire una singola riga del codice generato.

Il Rischio Invisibile

Per uno sviluppatore professionista, un modello economico che genera codice pieno di bug è fastidioso — cattura il bug in revisione, lo corregge e va avanti. Per un non programmatore, lo stesso bug è invisibile. Viene distribuito in produzione senza essere rilevato.

La scala di questo problema è sbalorditiva:

• Veracode ha testato oltre 100 LLM e ha scoperto che il codice generato dall'AI introduceva falle di sicurezza nel 45% delle attività. Java era il peggiore con oltre il 70%. È fondamentale notare che i modelli più nuovi e più grandi non hanno mostrato miglioramenti significativi nella sicurezza — il problema è strutturale, non generazionale.^[14]
• CodeRabbit ha analizzato 470 PR open-source e ha trovato che il codice generato dall'AI aveva 1,7 volte più problemi principali e 1,4 volte più problemi critici rispetto al codice umano. Gli errori di logica erano il 75% più alti. I problemi di prestazioni (I/O eccessivo) erano 8 volte più comuni. Le vulnerabilità di sicurezza erano 1,5–2 volte più alte.^[15]
• BaxBench e la ricerca della NYU confermano che il 40–62% del codice generato dall'AI contiene falle di sicurezza — cross-site scripting, SQL injection, validazione degli input mancante — il tipo di vulnerabilità che non fa crashare l'app ma espone silenziosamente i dati di ogni utente.^[16]

Uno sviluppatore professionista riconosce questi pattern. Un vibe coder non sa che esistono.

Catastrofi nel Mondo Reale

Non è teorico. Nel 2025, il ricercatore di sicurezza Matt Palmer ha scoperto che 170 su 1.645 applicazioni costruite con Lovable — una popolare piattaforma di vibe-coding — avevano la sicurezza del database fatalmente mal configurata. Chiunque su Internet poteva leggere e scrivere nei loro database. I dati esposti includevano nomi completi, indirizzi email, numeri di telefono, indirizzi di casa, importi di debiti personali e chiavi API.^[17]

Escape.tech è andata oltre, scansionando più di 5.600 app realizzate con vibe coding pubblicamente distribuite su piattaforme tra cui Lovable, Base44, Create.xyz e Bolt.new. Hanno trovato oltre 2.000 vulnerabilità, 400+ segreti esposti e 175 istanze di PII esposta inclusi cartelle cliniche, IBAN e numeri di telefono.^[18]

Questi non erano errori degli sviluppatori. Gli sviluppatori — se possiamo chiamarli così — non avevano idea che le vulnerabilità esistessero. Hanno chiesto all'IA di costruire un'app, l'app sembrava funzionare e l'hanno distribuita. Le falle di sicurezza erano invisibili a chiunque non potesse leggere il codice.

La Trappola della Supply Chain

I non programmatori affrontano una minaccia che persino gli sviluppatori esperti trovano difficile da cogliere: il slopsquatting. I modelli AI allucinano nomi di pacchetti — circa il 20% dei campioni di codice fa riferimento a pacchetti inesistenti. Gli attaccanti registrano questi nomi di pacchetti fantasma e iniettano malware. Quando l'IA del vibe coder suggerisce di installare il pacchetto, il malware entra automaticamente nella loro applicazione.^[19]

Uno sviluppatore potrebbe notare un nome di pacchetto sconosciuto e verificarlo. Un vibe coder installa qualsiasi cosa l'IA gli dica di installare. Non hanno un quadro di riferimento per capire cosa è legittimo e cosa è allucinato.

Perché la Qualità del Modello È l'Unica Rete di Sicurezza

Il team di ricerca Unit 42 di Palo Alto Networks l'ha detto chiaramente: i citizen developer — persone senza un background di sviluppo — "mancano di formazione su come scrivere codice sicuro e potrebbero non avere una piena comprensione dei requisiti di sicurezza nel ciclo di vita dello sviluppo dell'applicazione." La loro indagine ha trovato violazioni dei dati nel mondo reale, bypass di autenticazione ed esecuzione arbitraria di codice tracciate direttamente ad applicazioni realizzate con vibe coding.^[20]

Per gli sviluppatori professionisti, la code review, il testing e gli audit di sicurezza servono come reti di sicurezza. Catturano ciò che il modello manca. I vibe coder non hanno nessuna di queste reti di sicurezza. Non possono revisionare il codice che non sanno leggere. Non possono scrivere test per un comportamento che non capiscono. Non possono fare audit di proprietà di sicurezza di cui non hanno mai sentito parlare.

Questo significa che il modello AI stesso è l'unico controllo di qualità nell'intera pipeline. Ogni falla che il modello introduce viene distribuita direttamente agli utenti. Non c'è una seconda possibilità, nessun checkpoint umano, nessuna rete di sicurezza.

Ed è precisamente qui che la qualità del modello conta di più:

• Opus produce il 50–75% in meno di errori rispetto ai modelli più economici.^[1:4] Per un vibe coder con zero capacità di cogliere gli errori, questa è la differenza tra un'app funzionante e un'app che perde silenziosamente i dati degli utenti.
• Opus raggiunge le prestazioni massime in 4 iterazioni, non 10.^[1:5] Ogni iterazione extra significa che il vibe coder deve descrivere il problema in linguaggio naturale (non può indicare la riga sbagliata), sperare che l'IA capisca e sperare che la correzione non introduca nuovi bug che anch'esso non può vedere.
• Opus ha la massima resistenza all'injection di prompt tra i modelli frontier — critico quando il vibe coder sta costruendo app che gestiscono input utente che non riesce a sanificare da solo.
• Opus usa meno token per attività, il che significa che genera meno codice per raggiungere lo stesso obiettivo — meno codice significa meno superficie di attacco, meno posti dove i bug possono nascondersi in codice che nessuno leggerà mai.

Per uno sviluppatore, un modello economico è una tassa di produttività. Per un vibe coder, un modello economico è una responsabilità. Il modello non è il loro assistente — è il loro intero team di ingegneria. Assumere l'"ingegnere" più economico possibile quando non hai la capacità di verificare il loro lavoro non è parsimonia. È sconsiderato.

La Vera Decisione per i Non Programmatori

Se non sai leggere il codice, non stai scegliendo tra uno strumento economico e uno costoso. Stai scegliendo tra:

1. Un modello che fa le cose di sicurezza correttamente il 55% delle volte (e non saprai mai dell'altro 45%)
2. Un modello che fa le cose di sicurezza correttamente oltre l'80% delle volte (e produce drammaticamente meno bug silenziosi e invisibili che distruggono le aziende)

Il premio del 67% per token è insignificante rispetto al costo di una violazione dei dati di cui non sapevi fosse possibile, integrata in codice che non potevi leggere, in un'applicazione che hai distribuito a utenti reali.

Per i vibe coder, il modello costoso non è la scelta più economica. È l'unica responsabile.

Il Framework Decisionale

Se tu...	Usa...	Perché
Codifichi per ore ogni giorno	Opus + abbonamento	Nessun costo marginale, massima qualità
Lavori su attività complesse	Extra-alto / Opus	Meno iterazioni, meno bug
Mantieni codice a lungo termine	Il miglior modello disponibile	Il debito tecnico è il costo reale
Fai vibe coding senza leggere il codice	Opus — non negoziabile	Il modello è la tua unica rete di sicurezza
Hai un budget limitato	Comunque Opus tramite abbonamento	$200/mese < costo del debug dell'output economico
Esegui query rapide una tantum	Sonnet / sforzo medio	La soglia di qualità conta meno per attività semplici

L'unico scenario in cui i modelli più economici vincono è per attività banali dove qualsiasi modello riesce al primo tentativo. Per tutto il resto — che è la maggior parte della vera ingegneria del software — il modello costoso è la scelta economica.

Il Punto Finale

Il prezzo per token è una metrica di vanità. Il costo per attività è la metrica reale. E per attività, il modello più capace vince costantemente — non con un piccolo margine, ma con moltiplicatori:

• Il 60% più economico per attività (meno token)
• Il 60% in meno di iterazioni per raggiungere le prestazioni massime
• Il 50–75% in meno di errori
• 22.500 volte più prezioso in termini di risparmio di tempo dello sviluppatore rispetto alla differenza nel costo dei token

Il modello più costoso non è un lusso. È la scelta minima accettabile per chiunque valorizzi il proprio tempo.

---

1. Anthropic (2025). Introducing Claude Opus 4.5. Risultati chiave: con sforzo medio, Opus 4.5 eguaglia il miglior punteggio SWE-bench di Sonnet 4.5 usando il 76% in meno di token di output; con il massimo sforzo, Opus supera Sonnet di 4,3 punti percentuali usando il 48% in meno di token; riduzione del 50–75% negli errori delle chiamate agli strumenti e di build/lint; prestazioni massime raggiunte in 4 iterazioni vs. fino a 10 per i concorrenti. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

2. claudefa.st (2025). Claude Opus 4.5: 67% Cheaper, 76% Fewer Tokens. Analisi che mostra che il premio nel prezzo per token è più che compensato da un consumo di token drammaticamente inferiore per attività, rendendo Opus la scelta più conveniente per la maggior parte dei carichi di lavoro. ↩︎

3. Dati sullo stipendio degli sviluppatori da Glassdoor (2025): stipendio medio US per sviluppatore software $121.264–$172.049/anno. A $75/ora, 15 minuti di revisione/correzione per iterazione fallita = $18,75 in tempo umano. Sei iterazioni extra (divario tra 4 e 10) = $112,50 per attività complessa. Vedere: Glassdoor Software Developer Salary. ↩︎

4. Faros AI (2025). The AI Productivity Paradox. Studio di 1.255 team e oltre 10.000 sviluppatori ha trovato: i singoli sviluppatori nei team ad alto utilizzo di AI completano il 21% in più di attività e uniscono il 98% in più di PR, ma il tempo di revisione delle PR è aumentato del 91%, i bug sono aumentati del 9% per sviluppatore e le dimensioni delle PR sono cresciute del 154%. Nessuna correlazione significativa tra l'adozione dell'AI e il miglioramento delle prestazioni aziendali. ↩︎

5. Classifica SWE-bench Verified, febbraio 2026. Aggregata da marc0.dev, llm-stats.com e The Unwind AI. Claude Opus 4.5 è stato il primo modello a superare l'80% su SWE-bench Verified. ↩︎

6. JetBrains AI Blog (2026). The Best AI Models for Coding: Accuracy, Integration, and Developer Fit. Analisi del costo per attività su più modelli, incorporando il consumo di token e i tassi di successo. Vedere anche: AI Coding Benchmarks su Failing Fast. ↩︎

7. OpenAI (2025). GPT-5.1-Codex-Max; Codex Prompting Guide. Codex-Max con sforzo di ragionamento medio supera il Codex standard allo stesso sforzo usando il 30% in meno di token di pensiero — il modello premium è intrinsecamente più efficiente nei token. ↩︎

8. METR (2025). Measuring the Impact of Early 2025 AI on Experienced Open-Source Developer Productivity. Studio randomizzato controllato: 16 sviluppatori esperti, 246 attività, compensazione a $150/ora. Gli sviluppatori assistiti dall'AI erano il 19% più lenti. Gli sviluppatori si aspettavano un'accelerazione del 24% e credevano a posteriori di essere il 20% più veloci — un divario di percezione di ~39 punti percentuali. Meno del 44% del codice generato dall'AI è stato accettato. Vedere anche: arXiv:2507.09089. ↩︎

9. I dati industriali sui costi del ciclo di vita del software collocano costantemente la manutenzione al 60–80% del costo totale. Vedere: Sommerville, I. (2015). Software Engineering, 10a ed., Capitolo 9: "I costi di modifica del software dopo il rilascio superano tipicamente di gran lunga i costi di sviluppo iniziale." Vedere anche: MIT Sloan: The Hidden Costs of Coding with Generative AI. ↩︎

10. GitClear (2024). AI Code Quality Analysis: aumento di 8x nei blocchi di codice duplicato, aumento di 2x nel code churn (2020–2024). SonarSource (2025): analisi del codice generato dall'AI ha trovato una mancanza sistematica di consapevolezza della sicurezza in ogni modello testato, con Claude Sonnet 4 che produceva quasi il doppio della proporzione di bug di livello BLOCKER — un aumento del 93% nel tasso di introduzione di bug gravi. Vedere: DevOps.com: AI in Software Development. ↩︎

11. Level Up Coding (2025). Claude API vs Subscription Cost Analysis. Confronto della fatturazione abbonamento vs. API che mostra che gli abbonamenti sono circa 18 volte più economici per le sessioni di codifica prolungate. ↩︎

12. The CAIO (2025). Claude Code Pricing Guide. Costo medio di Claude Code: $6 per sviluppatore al giorno, con il 90% degli utenti sotto i $12/giorno sui piani di abbonamento. ↩︎

13. Peng, S. et al. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. Studio di laboratorio: gli sviluppatori hanno completato le attività il 55,8% più velocemente con Copilot. Vedere anche: caso studio ZoomInfo che mostra un aumento di produttività del 40–50% con l'AI, con il divario che cresce man mano che la difficoltà dell'attività aumenta (arXiv:2501.13282). ↩︎

14. Veracode (2025). 2025 GenAI Code Security Report. Analisi di 80 attività di codifica su 100+ LLM: il codice generato dall'AI introduceva falle di sicurezza nel 45% dei casi. Java il peggiore al 70%+, Python/C#/JavaScript al 38–45%. I modelli più nuovi e più grandi non hanno mostrato miglioramenti significativi nella sicurezza. Vedere anche: Annuncio BusinessWire. ↩︎

15. CodeRabbit (2025). State of AI vs Human Code Generation Report. Analisi di 470 PR GitHub open-source (320 co-create con AI, 150 solo umane): il codice AI aveva 1,7x più problemi principali, 1,4x più problemi critici, il 75% in più di errori di logica, 1,5–2x più vulnerabilità di sicurezza, 3x più problemi di leggibilità e quasi 8x più problemi di prestazioni (I/O eccessivo). Vedere anche: Copertura di The Register. ↩︎

16. Ricerca BaxBench e NYU sulla sicurezza del codice AI. Vedere: Tihanyi, N. et al. (2025). Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks. BaxBench combina scenari di codifica backend con exploit di sicurezza progettati da esperti, trovando che il 40–62% del codice generato dall'AI contiene falle di sicurezza tra cui XSS, SQL injection e validazione degli input mancante. ↩︎

17. Palmer, M. (2025). Statement on CVE-2025-48757. Analisi di 1.645 applicazioni costruite con Lovable: 170 avevano la Row Level Security fatalmente mal configurata, permettendo l'accesso non autenticato in lettura e scrittura ai database utente. I PII esposti includevano nomi, email, numeri di telefono, indirizzi di casa, importi di debiti personali e chiavi API. Vedere anche: Superblocks: Lovable Vulnerability Explained. ↩︎

18. Escape.tech (2025). The State of Security of Vibe Coded Apps. Scansione di 5.600+ applicazioni realizzate con vibe coding pubblicamente distribuite su Lovable, Base44, Create.xyz, Bolt.new e altri. Trovate 2.000+ vulnerabilità, 400+ segreti esposti e 175 istanze di PII esposta incluse cartelle cliniche, IBAN e numeri di telefono. Vedere anche: Dettaglio della metodologia. ↩︎

19. Lanyado, B. et al. (2025). AI-hallucinated code dependencies become new supply chain risk. Studio di 16 modelli AI di generazione del codice: ~20% di 756.000 campioni di codice raccomandava pacchetti inesistenti. Il 43% dei pacchetti allucinati veniva ripetuto in modo consistente tra le query, rendendoli sfruttabili. I modelli open-source allucinano al 21,7%; i modelli commerciali al 5,2%. Vedere anche: HackerOne: Slopsquatting. ↩︎

20. Palo Alto Networks Unit 42 (2025). Securing Vibe Coding Tools: Scaling Productivity Without Scaling Risk. Indagine di incidenti di sicurezza nel mondo reale del vibe coding: violazioni dei dati, bypass di autenticazione ed esecuzione arbitraria di codice. Nota che i citizen developer "mancano di formazione su come scrivere codice sicuro e potrebbero non avere una piena comprensione dei requisiti di sicurezza nel ciclo di vita dello sviluppo dell'applicazione." Ha introdotto il framework di governance SHIELD. Vedere anche: Copertura di Infosecurity Magazine. ↩︎