L'IA ormai scrive il vostro codice. Gli incidenti per pull request sono aumentati del 242 %.
Il codice generato dall'IA supera la code review: incidenti per PR +242 %, bug per sviluppatore +54 %.Perché i test end-to-end sono ora il controllo di qualità che regge il ritmo.
10 min di letturaDal team di GUI Test Studio
Cosa ha misurato Faros AI
Nell'aprile 2026 Faros AI ha pubblicato The AI Engineering Report 2026: The Acceleration Whiplash.Non è un sondaggio su come si sentono gli sviluppatori.Si tratta di circa due anni di telemetria su 22.000 sviluppatori in oltre 4.000 team, e confronta i periodi di minore e di maggiore adozione dell'IA all'interno di ciascuna organizzazione.
Il primo risultato inquadra la scena.Nell'80% dei team, più della metà degli sviluppatori usa strumenti di IA ogni settimana, e la quota di codice generato dall'IA che gli sviluppatori accettano è salita dal 20% al 60%.
«L'IA non sta assistendo gli sviluppatori. Nella maggior parte delle organizzazioni, li sta guidando.»
La buona notizia è reale, e il report lo dice.Con un'alta adozione dell'IA, i team completano più lavoro.
+66%
Epic completate per sviluppatore
+33.7%
Attività completate per sviluppatore
+16.2%
Pull request integrate per sviluppatore
Poi arriva il contraccolpo.Gli stessi team rilasciano più incidenti e più bug, e la curva si fa più ripida, non più piatta.
Qualità in produzione con un'alta adozione dell'IA
Incidenti per pull request
Gli incidenti per modifica integrata si verificano con una frequenza più che tripla.
Incidenti mensili
Interruzioni del servizio, eventi di sicurezza e guasti che arrivano agli utenti.
Bug per sviluppatore, report 2026
Bug per sviluppatore, report 2025
Il tasso di difetti si fa più ripido, non si appiattisce.
Bug per pull request
Perché bug e incidenti aumentano con il codice generato dall'IA?
Un incidente è ciò che un utente avverte: un'interruzione del servizio, un evento di sicurezza, un guasto del sistema.Tra bassa e alta adozione dell'IA, il rapporto tra incidenti e pull request integrate è salito del 242.7%, e gli incidenti mensili sono saliti del 57.9%.
«Per ogni PR integrata, gli incidenti si verificano con una frequenza più che tripla.»
I bug seguono la stessa linea.Il report 2025 di Faros, The AI Productivity Paradox, aveva misurato i bug per sviluppatore in aumento del 9%.In questo insieme di dati, la cifra è in aumento del 54%, e la pagina stessa del report indica i bug per pull request in aumento del 28.7%.Più un team si affida all'IA, più in fretta crescono i difetti.
Questi numeri descrivono ciò che è successo, non un'unica causa, e Faros ha cura di precisarlo.Ma puntano tutti nella stessa direzione.Più codice arriva in produzione, più in fretta, e ogni modifica porta con sé più rischio di prima.
Perché la revisione del codice non riesce a stare al passo con gli agenti di programmazione IA?
La revisione del codice è stata pensata per codice scritto a velocità umana.Un agente di programmazione IA scrive una pull request in pochi minuti, e un team con cinque agenti apre in un giorno più pull request di quante i suoi ingegneri senior riescano a leggerne in una settimana.
La revisione del codice sotto il volume generato dall'IA
Tempo mediano in revisione
Tempo mediano fino alla prima revisione
Pull request integrate senza alcuna revisione
Non le ha guardate né una persona né un agente IA.
Faros ha misurato la coda: il tempo mediano fino alla prima revisione è in aumento del 156.6%, il tempo mediano in revisione in aumento del 441.5%.E la pressione trova una via d'uscita.Le pull request integrate senza alcuna revisione, né umana né agentica, sono in aumento del 31.3%.
«Il codice sta arrivando nei sistemi di produzione senza alcuna supervisione con una frequenza significativamente più alta.»
Anche una revisione attenta ha un punto cieco.
- Chi fa la revisione legge un diff, e un diff non mostra mai l'applicazione in esecuzione.
- Un pulsante nascosto da un nuovo stile, un totale calcolato nel modo sbagliato nella pagina del checkout, una finestra di dialogo che si apre dietro la finestra: nessuno di questi è visibile nel codice che lo ha causato.
Cosa intercetta i bug che la revisione si lascia sfuggire?
La prima idea è chiedere all'agente più test unitari.Fatelo, ma non fermatevi lì.I test scritti dall'agente che ha scritto il codice condividono la sua interpretazione dell'attività: se ha frainteso il requisito, il codice e i suoi test concordano tra loro, e sono sbagliati entrambi.
La rete di sicurezza che tiene il passo dell'IA ha tre proprietà.
| Proprietà | Perché conta con il codice generato dall'IA |
|---|---|
| Automatizzata | Viene eseguita su ogni pull request e a ogni build, alla velocità degli agenti, senza attendere chi fa la revisione. |
| Indipendente | È affidata a una persona, e non dipende dal codice né dall'IA che ha scritto il codice, quindi non può condividerne gli errori. |
| Controlla ciò che vedono gli utenti | Guida l'applicazione reale attraverso la sua interfaccia e verifica lo schermo, dove gli incidenti si avvertono. |
Questo è un test end-to-end: un test dell'intera applicazione attraverso la sua interfaccia, come la percorre un utente, dall'accesso al pagamento.È a questo che si riduce testare il codice generato dall'IA, ed è ciò che chiedono i numeri di Faros: un controllo che cresce con il volume delle modifiche, non con il numero dei revisori.
Un agente apre una PR
Minuti di lavoro, molti file
I test unitari passano
L'interpretazione dell'agente stesso
Vengono eseguiti i test end-to-end
Ciò che vede l'utente, affidato a una persona
Merge, o bloccata
Un fallimento attende una correzione
Come trasformare i test end-to-end in un quality gate CI/CD?
Definizione
Un quality gate è un controllo che una modifica deve superare prima del merge o del rilascio.
- Cinque abitudini trasformano i test end-to-end in un quality gate che un agente non riesce ad aggirare a parole.
- 1
Elencare i percorsi che non devono mai rompersi
Registrazione, accesso, ricerca, checkout, il report che i vostri clienti esportano ogni lunedì.Da cinque a dieci percorsi, ciascuno con il risultato che un utente si aspetta.Quell'elenco è la specifica, e appartiene a una persona, non all'agente.
- 2
Testare lo schermo, non il codice
Verificate ciò che un utente legge e vede: il totale, il messaggio, il pulsante, la disposizione.Un agente rinomina classi e riscrive componenti liberamente.Un test ancorato allo schermo sopravvive a tutto questo, e fallisce comunque quando lo schermo è sbagliato.
- 3
Eseguire su ogni pull request, e bloccare in caso di fallimento
Un risultato che si limita ad avvisare viene presto ignorato.Fate in modo che un test end-to-end non superato faccia fallire la build, così la modifica attende una correzione invece di arrivare agli utenti.
- 4
Tenere i test fuori dalla portata dell'agente
L'agente può eseguire i test e leggerne i risultati.Una modifica a ciò che un test si aspetta richiede l'approvazione di una persona, altrimenti i test scivolano verso ciò che il codice si trova a fare.
- 5
Rendere leggibili i fallimenti, e registrarli come bug
Un fallimento dovrebbe dire quale passaggio non è riuscito e in che modo lo schermo differisce, con le immagini, così l'agente può proporre una correzione e una persona può decidere.E dovrebbe diventare un bug nel vostro tracker senza che nessuno copi degli screenshot: vedete trasformare i test non superati in bug Jira.
Un avvertimento: un gate che fallisce senza motivo è peggio di nessun gate, perché le persone imparano a ignorarlo.Un gate ha bisogno di test che distinguano una vera regressione dal rumore innocuo.È l'argomento di test instabili e falsi positivi.
Da fare
- Test end-to-end dei percorsi su cui gli utenti fanno affidamento
- Un'esecuzione non superata che blocca il merge
- Una persona che approva ogni modifica a ciò che un test si aspetta
- Fallimenti con immagini e passaggi, registrati come bug
Da evitare
- I test dell'agente stesso come unica rete di sicurezza
- Fare il merge quando i revisori sono troppo occupati per guardare
- Un'esecuzione end-to-end rossa che si limita ad avvisare
- Gate così instabili che nessuno si fida più
Testare il codice generato dall'IA a ogni build con GUI Test Studio
GUI Test Studio è costruito esattamente per questo gate.Testa end-to-end app web, app desktop Windows, telefoni e giochi, attraverso la loro interfaccia, senza codice di test da scrivere né da mantenere.
Un test in pochi minuti: registratelo, o descrivetelo
Registrate un flusso una volta in GUI Test Runner-Recorder, facendo clic e digitando nell'applicazione reale.Oppure descrivetelo in un prompt a Claude, a ChatGPT con Codex o a un modello di IA locale, uno nostro o uno vostro, e il test viene creato per voi.Ogni controllo che un assistente aggiunge viene provato sul momento e rifiutato se non può passare sullo schermo adesso.
In entrambi i casi, il test controlla ciò che mostra lo schermo.
- Un'asserzione visiva confronta l'immagine di un elemento, un'asserzione testuale ne legge le parole.
- Il GTS Engine + AI trova ogni elemento chiedendo prima all'applicazione, tramite le sue informazioni di accessibilità o gli elementi propri della pagina web, e a vista quando l'applicazione non lo dice.
- Una classe rinominata o un componente riscritto non rompono il test.
Un gate nella vostra pipeline, con gtr-cli
gtr-cli esegue gli stessi test su una macchina di build Windows e risponde come si aspetta una pipeline: il suo codice di uscita fa fallire la build, un file JUnit riempie la scheda dei test, e un riepilogo Markdown è pronto per la pull request.Con una sola opzione, un test non superato diventa un ticket Jira con i passaggi per riprodurlo e le immagini attesa e trovata.
gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
--summary results\summary.md --artifacts results\artifacts --jira on-failureFunziona in TeamCity, Jenkins, GitHub Actions, GitLab e Azure DevOps: vedete Eseguire i test nella pipeline, e Eseguite i vostri test end-to-end a ogni build per una configurazione di TeamCity passo dopo passo.
Una vera regressione, o rumore innocuo?
Ogni esecuzione termina con un report di affidabilità: per ogni controllo, se l'elemento è stato trovato nella Fase di ricerca e se corrisponde a ciò che è stato registrato nella Fase di verifica.
- Quando un'immagine differisce, l'analisi intelligente con IA dà un secondo sguardo.
- Ignora il rumore di rendering, e coglie comunque una parola cambiata, un badge mancante o un pulsante diventato grigio, poi dice cosa è cambiato in parole semplici.
Anche l'agente può eseguire il gate
Attraverso il suo connettore, l'assistente che scrive il vostro codice può eseguire i vostri test, leggerne l'esito e proporre una modifica a un test, che attende la vostra conferma.Una persona resta responsabile di ciò che i test si aspettano.L'intero ciclo è in Sviluppo con agenti IA (ADLC).
Punti chiave
- 1L'IA è ormai l'autrice principale del codice. La produttività è in aumento, e così gli incidenti: +242.7% per pull request integrata, +57.9% al mese.
- 2I bug accelerano, non si stabilizzano. I bug per sviluppatore sono saliti del 54%, contro il 9% del report 2025.
- 3La revisione ha raggiunto il suo limite. Le pull request integrate senza alcuna revisione sono il 31.3% in più.
- 4La rete di sicurezza deve essere automatizzata e indipendente: test end-to-end di ciò che vedono gli utenti, affidati a una persona, eseguiti a ogni build.
- 5Fatene un gate. Un fallimento blocca il merge, apre un bug e dice cosa è cambiato.
Domande
Il codice generato dall'IA causa più bug?
L'AI Engineering Report 2026 di Faros AI ha confrontato i periodi di minore e di maggiore adozione dell'IA all'interno di ciascuna organizzazione, su 22.000 sviluppatori.Con un'alta adozione, i bug per sviluppatore sono saliti del 54% e gli incidenti per pull request integrata del 242.7%.Il report misura ciò che è successo, non un'unica causa, ma il tasso di difetti sale man mano che l'adozione si approfondisce.
Perché la revisione del codice non basta per il codice generato dall'IA?
Il tempo di revisione cresce con il volume del codice, e l'IA moltiplica il volume.Faros ha misurato il tempo mediano fino alla prima revisione in aumento del 156.6% e le pull request integrate senza alcuna revisione in aumento del 31.3%.Chi fa la revisione, inoltre, legge un diff, mai l'applicazione in esecuzione, quindi uno schermo rotto può superare una revisione attenta.
Come si testa il codice generato dall'IA prima che arrivi in produzione?
Mantenete test end-to-end dei vostri flussi critici affidati a una persona, indipendenti dal codice e dall'agente che lo ha scritto.Eseguiteli su ogni pull request o a ogni build, e fate in modo che un fallimento blocchi il merge.Controllano ciò che vedono gli utenti, chiunque abbia scritto il codice.
Che cos'è un quality gate CI/CD?
Un quality gate è un controllo nella vostra pipeline che una modifica deve superare prima del merge o del rilascio.Un test end-to-end non superato fa fallire la build, così la modifica attende una correzione invece di arrivare agli utenti.
Un agente di programmazione IA può creare ed eseguire test di GUI Test Studio?
Sì.Claude, ChatGPT con Codex, Copilot Chat in VS Code, o un modello di IA locale, uno nostro o uno vostro, possono creare un test da un prompt ed eseguirlo attraverso il connettore di GUI Test Studio.In una pipeline, gtr-cli esegue gli stessi test senza alcun assistente.
Dati: Faros AI, The AI Engineering Report 2026: The Acceleration Whiplash (aprile 2026), e la pagina del report per i bug per pull request.Faros AI, Claude, ChatGPT, Codex, Copilot, OpenAI, Anthropic, Jira, TeamCity, Jenkins, GitHub, GitLab, Azure DevOps e YouTube sono marchi dei rispettivi proprietari.
Pronti a registrare il vostro primo test?
Tutte le funzionalità, per 15 giorni.
Preferite vederlo sul tipo di app che testate?Prenotate una chiamata gratuita di 30 minuti con il nostro team.