Guida Dual LLM Verification

Guida Dual LLM Verification

Chiedere alla stessa intelligenza artificiale che ha scritto una funzione di rileggerla per trovarne i difetti è un po’ come chiedere a uno studente di correggere il proprio compito in classe: userà sempre lo stesso ragionamento, le stesse scorciatoie mentali che lo hanno portato all’errore. La Dual LLM Verification nasce per rompere questo specchio: una seconda AI, indipendente dalla prima, rilegge il codice con occhi diversi. In questa guida vediamo cos’è, cosa dice la ricerca più recente, cosa raccontano gli sviluppatori su Reddit e nelle community tecniche, e come costruirla in pratica partendo da Claude Code.

Indice dei contenuti – Guida Dual LLM Verification

1. Perché una sola AI non basta a garantire codice sicuro
2. Cos’è la Dual LLM Verification
3. Le metodologie più moderne: cosa dice la ricerca
4. Cosa dicono gli sviluppatori: Reddit e community a confronto
5. Esempio pratico: costruire e revisionare una mini Task List app
6. Mini guida: il workflow di Dual LLM Verification in 6 passi
7. Best practice da adottare da subito
8. Quale AI scegliere come secondo revisore
9. Conclusioni: l’AI corre veloce, chi resta fermo perde terreno

1. Perché una sola AI non basta a garantire codice sicuro

Immagina la scena, comune a chiunque usi oggi un coding agent: apri il terminale, dai a Claude Code l’obiettivo “aggiungi la gestione dei task a questa API”, in pochi minuti il codice è pronto, i test passano, il commit è fatto. Tutto sembra a posto. Due giorni dopo, in produzione, salta fuori un edge case che un secondo paio d’occhi avrebbe notato subito: un caso null non gestito, un pulsante collegato a nulla, un errore ingoiato in silenzio invece di essere sollevato.

Vediamo gradualmente i motivi di questa situazione. Un modello che scrive codice e poi lo rilegge da solo tende a confermare le proprie scelte, non a metterle in discussione: condivide la stessa distribuzione di addestramento, le stesse euristiche, gli stessi punti ciechi che lo hanno portato a scrivere il codice in quel modo. Diversi studi pubblicati tra il 2025 e il 2026 confermano il pattern: nelle pipeline che affidano scrittura e revisione allo stesso modello, gli errori tendono a ripetersi invece che ad annullarsi a vicenda, perché manca la diversità realmente indipendente che serve a smontare un ragionamento sbagliato. Lo stesso fenomeno è stato osservato anche fuori dallo sviluppo web, ad esempio nella generazione di codice di basso livello, dove un secondo agente “revisore” tendeva ad accettare gli errori del primo invece di correggerli, semplicemente perché condivideva lo stesso punto di vista.

2. Cos’è la Dual LLM Verification

La Dual LLM Verification è un pattern di lavoro in cui il codice viene generato da un modello (il writer) e revisionato da un secondo modello, architetturalmente separato (il reviewer), idealmente di un altro fornitore o di un’altra famiglia. L’obiettivo non è avere “due opinioni” a caso, ma rompere la correlazione tra chi scrive e chi controlla: se i due modelli condividono lo stesso addestramento, tendono a condividere anche gli stessi errori sistematici.

Esistono diversi livelli di indipendenza, dal più debole al più forte:

• Self-review: lo stesso modello, nella stessa sessione, rilegge quello che ha appena scritto. È il livello più debole: il modello difende le proprie decisioni.
• Cross-instance, stesso modello: una seconda sessione dello stesso modello, senza memoria della prima, rilegge il codice. Non ha “investito” nella scelta originale, quindi la critica in modo più onesto, ma condivide comunque gli stessi bias di fondo.
• Cross-vendor: un modello di un altro fornitore (ad esempio Claude che scrive e un modello OpenAI o Google che revisiona) controlla il codice. È il livello di indipendenza più forte, perché le architetture, i dati e le scelte di allineamento sono diversi.

Anthropic stessa ha portato questo principio dentro Claude Code con la funzione Code Review, che distribuisce più agenti in parallelo su ogni pull request, li fa lavorare su tutta la codebase e aggiunge un passaggio di falsificazione: prima di segnalare un problema, l’agente deve provare a smentirlo. Secondo i dati diffusi da Anthropic, questo ha portato la percentuale di PR interne con almeno una segnalazione utile dal 16% al 54%, con un tasso di falsi positivi sotto l’1%. È un ottimo livello di qualità, ma resta comunque una revisione “in famiglia”: più modelli Claude che si controllano a vicenda. Per questo, nella pratica quotidiana, molti sviluppatori affiancano a questo strato un secondo modello di un altro fornitore, per avere una vera indipendenza di giudizio.

3. Le metodologie più moderne: cosa dice la ricerca

La ricerca accademica e i team che lavorano su questi sistemi ogni giorno concordano su un punto: aggiungere una seconda AI non basta da sola, il modo in cui la si integra fa la differenza.

• Multi-Review con aggregatore. Uno studio del 2025 ha testato un approccio in cui la stessa pull request viene revisionata più volte in modo indipendente, poi un modello “aggregatore” sintetizza i risultati. Con più run indipendenti dello stesso modello (variante Self-Agg), il punteggio F1 è migliorato di oltre il 40% rispetto a una singola revisione, con un miglioramento della recall superiore al 100%; i benefici però si appiattiscono dopo 5-10 run, quindi moltiplicare le revisioni all’infinito non serve.
• Attenzione al “consensus-seeking”. Uno studio del febbraio 2026 ha mostrato che i team multi-agente eterogenei possono comunque ottenere risultati peggiori del singolo miglior membro del gruppo, con perdite di performance fino al 37,6%, anche quando al sistema viene detto esplicitamente chi è l’esperto. Il problema è che i modelli tendono a cercare il consenso invece di valorizzare il parere più competente: un motivo in più per dare al revisore un compito chiaro e circoscritto, trovare difetti, non “votare” sulla soluzione migliore.
• Loop di convergenza adversariale. Un pattern che sta guadagnando terreno tra sviluppatori esperti è il ciclo di revisione ripetuto: un secondo modello (spesso da un altro fornitore) rilegge il codice con sessioni sempre nuove, non continuazioni della stessa conversazione, finché un ulteriore giro non trova più nulla di nuovo da segnalare. La sessione nuova è importante: un revisore che ha già validato il proprio giudizio in un round precedente tende a difenderlo nei round successivi, invece di rimetterlo in discussione.
• Evidenza, non fiducia. Le guide ufficiali di Claude Code insistono su questo principio: il modello che verifica non deve limitarsi a dire “sembra corretto”, ma deve mostrare l’evidenza, l’output dei test eseguiti, il comando lanciato, il risultato ottenuto. È lo stesso principio che i team di revisione umana applicano da sempre, applicato ora anche al revisore artificiale.

4. Cosa dicono gli sviluppatori: Reddit e community a confronto

Fuori dai paper accademici, la Dual LLM Verification si sta diffondendo prima come abitudine informale che come processo aziendale strutturato. Su r/ClaudeAI è diventato virale il racconto di uno sviluppatore che ha fatto lavorare due istanze di Claude Code sullo stesso progetto: una come autrice del codice, una come revisore. La cosa interessante è che la seconda istanza, pur essendo lo stesso modello e senza alcuna informazione su chi avesse scritto cosa, ha segnalato con precisione una gestione degli errori troppo permissiva e una variabile rinominata in modo sospetto, sintomo (a detta del thread) di una scelta affrettata durante la scrittura. Il fatto che bastasse una sessione pulita, senza infrastruttura dedicata, ha convinto molti lettori che questo tipo di controllo incrociato sia alla portata di qualunque sviluppatore già oggi.

Lo stesso thread solleva però un dubbio ancora aperto: non è chiaro se l’indipendenza del giudizio regga anche quando le due istanze condividono lo stesso prompt di sistema, o quando l’intero progetto entra comodamente nella finestra di contesto di un solo modello. È un limite reale della revisione “in famiglia” di cui accennavamo al punto 2.

Il salto verso la revisione cross-vendor si vede bene in una serie di racconti pubblicati su Substack e su DEV Community nella prima metà del 2026: sviluppatori che, dopo aver letto su Reddit che un modello concorrente era particolarmente bravo a trovare bug, hanno iniziato a far scrivere il codice a Claude Code e a farlo rileggere a un secondo modello in un terminale separato. Il pattern ricorrente descritto è sempre lo stesso: Claude è molto rapido e tende a consegnare presto, il secondo modello arriva senza il contesto delle decisioni prese e si limita a chiedersi se il codice funzioni davvero, individuando casi null non gestiti o percorsi che funzionano solo nello scenario “felice”.

Il segnale più forte sulla direzione presa dal mercato, però, è che questo pattern sta uscendo dalla fase di esperimento personale: OpenAI ha rilasciato un plugin ufficiale per Claude Code che permette di richiamare Codex direttamente come secondo revisore, e strumenti open source come cc-review, nato per lo stesso identico motivo, evitare che “Claude riveda Claude”, stanno raccogliendo consenso nella community proprio perché rendono la revisione incrociata configurabile con qualsiasi provider (Gemini, DeepSeek, modelli locali via Ollama). Detto questo, chi analizza il fenomeno con occhio critico ammette che mancano ancora dati su larga scala: non sappiamo con certezza quanto bene, in produzione, un pool di modelli multi-agente riesca a intercettare i bug scritti da un singolo agente, ma la direzione (dall’abitudine personale allo strumento supportato ufficialmente) è ormai chiara a livello internazionale.

5. Esempio pratico: costruire e revisionare una mini Task List app

Vediamo il pattern applicato a un caso concreto e minimale: una piccola Task List full-stack con backend Node/Express e frontend React. Chiediamo a Claude Code di generare l’endpoint di creazione task e il componente che lo consuma.

Prompt a Claude Code (writer):

Crea un endpoint POST /tasks su Express che accetta {title}
e lo salva in memoria, e un componente React che mostra
la lista dei task e permette di aggiungerne uno nuovo.

Output di Claude Code — server.js

• // server.js — backend Express minimale
• const express = require(‘express’);
• const app = express();
• app.use(express.json());
•  
• let tasks = [];
•  
• app.post(‘/tasks’, (req, res) => {
•   const task = { id: Date.now(), title: req.body.title };
•   tasks.push(task);
•   res.status(201).json(task);
• });
•  
• app.get(‘/tasks’, (req, res) => res.json(tasks));
• app.listen(3001);

Output di Claude Code — TaskList.jsx

// TaskList.jsx — frontend React minimale
function TaskList({ tasks }) {
  return (
    <ul>
      {tasks.map(t => (
        <li key={t.id}
            dangerouslySetInnerHTML={{ __html: t.title }} />
      ))}
    </ul>
  );
}

Il codice funziona, i test manuali passano, l’app sembra pronta. È esattamente il momento in cui entra in gioco il secondo revisore: apriamo una sessione nuova su un modello diverso (ad esempio Codex o Gemini) e gli passiamo solo il diff, chiedendo una revisione da “collega scettico”, senza il contesto delle decisioni prese durante la scrittura.

Prompt al secondo modello (reviewer):

Rivedi questo diff come farebbe un senior engineer scettico.
Non fidarti dei commenti: cerca input non validati, casi limite
non gestiti e vulnerabilità di sicurezza. Motiva ogni segnalazione.

Il secondo modello segnala due problemi reali che Claude Code, concentrato sul “far funzionare” la feature, non aveva sollevato: il backend non valida req.body.title, quindi una richiesta senza titolo crea un task con title undefined e nessun limite di lunghezza; il frontend, usando dangerouslySetInnerHTML per renderizzare un testo scritto liberamente dall’utente, apre una falla di Cross-Site Scripting classica — chiunque può inserire un tag <script> come titolo del task.

Fix applicato dopo la revisione:

// server.js — con validazione dell'input
app.post('/tasks', (req, res) => {
  const title = (req.body.title || '').trim();
  if (!title || title.length > 200) {
    return res.status(400).json({ error: 'Titolo non valido' });
  }
  const task = { id: Date.now(), title };
  tasks.push(task);
  res.status(201).json(task);
});
 
// TaskList.jsx — niente HTML non sanificato
function TaskList({ tasks }) {
  return (
    <ul>
      {tasks.map(t => <li key={t.id}>{t.title}</li>)}
    </ul>
  );
}

Nessuno dei due difetti era esotico: sono gli errori più comuni nel codice generato da AI, proprio perché il modello ottimizza per “far vedere che la feature funziona”, non per la robustezza. Ed è esattamente il tipo di errore che un secondo modello, senza il contesto e la fretta del primo, individua in pochi secondi.

6. Mini guida: il workflow di Dual LLM Verification in 6 passi

• 1. Definisci il compito con chiarezza. Prima di far scrivere codice a Claude Code, scrivi requisiti e criteri di accettazione: un revisore, umano o AI, lavora meglio se sa cosa deve essere vero alla fine.
• 2. Genera con Claude Code. Usa Claude Code (in modalità plan quando la modifica è ampia) per produrre l’implementazione, e chiedi sempre evidenza dell’esecuzione: output dei test, comando lanciato, risultato ottenuto.
• 3. Isola il diff. Prepara una sintesi pulita delle modifiche (file cambiati, motivazione, eventuale PR) da passare al revisore, così il secondo modello valuta il codice, non la narrazione di chi lo ha scritto.
• 4. Passa il diff a un secondo modello, sessione nuova. Scegli un modello di un altro fornitore quando possibile, apri una sessione senza storico e chiedigli esplicitamente di comportarsi da revisore scettico.
• 5. Fai convergere, non solo raccogliere. Se il secondo modello solleva dubbi, applica le correzioni sensate e ripeti la revisione con una sessione ancora nuova, finché un giro non trova più nulla di rilevante.
• 6. La decisione finale resta umana. Nessun livello di Dual LLM Verification sostituisce il merge fatto da una persona: automatizza la raccolta di segnali, non la responsabilità.

7. Best practice da adottare da subito

• Diversifica il fornitore. La diversità di addestramento tra le due AI è il fattore che riduce di più gli errori correlati: non basta usare due chat diverse dello stesso modello.
• Sessioni sempre fresche. Un revisore che continua la stessa conversazione del writer eredita, anche solo psicologicamente nel modo in cui è stato istruito, la stessa direzione di pensiero.
• Chiedi motivazioni, non verdetti. Un “looks good” non è una revisione: pretendi che il modello indichi riga, motivazione e possibile impatto di ogni segnalazione.
• Automatizza il gate, non il giudizio. Integra la doppia revisione come step in CI/CD (ad esempio su ogni pull request), ma lascia sempre all’essere umano l’approvazione finale del merge.
• Traccia i disaccordi. Quando i due modelli non sono d’accordo, quel disaccordo è un segnale prezioso di per sé: spesso indica codice ambiguo o sotto-specificato, non un errore di uno dei due.
• Non esagerare con i round. I benefici di run multipli si appiattiscono dopo 5-10 iterazioni: oltre quella soglia si paga solo più tempo e più token, senza guadagno reale in qualità.

8. Quale AI scegliere come secondo revisore – Guida Dual LLM Verification

Non esiste un abbinamento “giusto” in assoluto: quello che conta, secondo tutte le fonti analizzate, è la diversità tra chi scrive e chi controlla. Alcune indicazioni pratiche emerse dalla ricerca e dall’uso reale:

• OpenAI Codex / GPT-5: è oggi l’abbinamento più diffuso con Claude Code, al punto che OpenAI ha pubblicato un plugin ufficiale per richiamarlo come revisore direttamente dentro Claude Code. Diversi sviluppatori lo trovano particolarmente efficace su edge case e gestione degli errori.
• Google Gemini: grazie alla finestra di contesto molto ampia, è indicato quando la revisione deve considerare l’intera codebase o molti file correlati, non solo il singolo diff.
• Claude Code Review (nativo Anthropic): è il layer più comodo da attivare perché integrato, con verifica multi-agente e falsificazione dei falsi positivi. Va considerato un ottimo primo filtro, da affiancare, non sostituire, a un secondo modello di un altro fornitore per l’indipendenza reale.

Per un team che parte da zero, un buon compromesso è: Claude Code per la scrittura, Code Review nativo come primo filtro automatico su ogni PR, e un modello di un altro fornitore (Codex o Gemini, in base a cosa già usate in azienda) come secondo parere sulle modifiche più delicate, autenticazione, pagamenti, gestione dati sensibili.

9. Conclusioni: l’AI corre veloce, chi resta fermo perde terreno

La Dual LLM Verification non è una moda passeggera: è la risposta naturale a un problema strutturale che si sta manifestando ovunque, dagli hobby project ai processi di revisione ufficiali di Anthropic. E la velocità con cui il settore si sta muovendo, plugin ufficiali di cross-provider review, strumenti open source, feature native nei principali coding agent, dice chiaramente che tra pochi mesi questo non sarà più un vezzo da early adopter, ma una prassi attesa in ogni team che scrive software con l’AI.

Chi oggi si limita a “chiedere a Claude di scrivere il codice” senza costruire un processo di verifica solido rischia di accumulare debito tecnico nascosto molto più in fretta di quanto lo accumulasse prima, semplicemente perché il codice viene prodotto a una velocità che il vecchio processo di revisione umana non riesce più a reggere da solo. Le aziende e gli sviluppatori che invece imparano subito a padroneggiare questi workflow, Claude Code per costruire, un secondo modello per verificare, un processo chiaro in mezzo, stanno già guadagnando un vantaggio competitivo difficile da recuperare in corsa.

Se vuoi portare questi workflow nel tuo team in modo strutturato, senza procedere per tentativi, il Corso Claude Code per aziende di Innovaformazione è pensato esattamente per questo: dalla scrittura del codice con Claude Code fino ai processi di revisione e verifica, incluso l’uso combinato di più modelli AI. Scopri il programma completo sul sito www.innovaformazione.net .

Contatti

Per un preventivo personalizzato o maggiori dettagli sul corso per la tua azienda, scrivi a info@innovaformazione.net o chiama il 347 1012275 — Dario Carrassi.

(fonte) (fonte) (fonte)