Negli ambienti di ingegneria del software moderni, l'utilizzo degli agenti AI (come Cursor, Claude Code o Copilot) ha invertito i costi tradizionali: scrivere righe di codice è diventato estremamente rapido ed economico, mentre leggerle, capirle e certificarle è il vero collo di bottiglia che consuma tempo.

Edsger W. Dijkstra osservava che i test possono mostrare la presenza di errori, ma non dimostrarne l'assenza (EWD268, Structured Programming). Fidarsi di migliaia di righe generate senza una validazione autonoma è un rischio concreto. I test tradizionali sono efficaci, ma coprono solo i casi limite a cui lo sviluppatore umano ha già pensato in fase di scrittura. Cosa succede quando la specifica iniziale presenta delle zone grigie?

Dossier in breve

  • Il test di divergenza: dai lo stesso requisito a più agenti AI indipendenti che non si parlano. Esegui il codice generato sugli stessi input per vedere dove divergono.
  • Cosa rivela: dove gli output differiscono, può esserci un requisito ambiguo o mancante oppure un errore nel codice generato.
  • Il caso e-commerce: nella simulazione offline, tre implementazioni didattiche producono rimborsi diversi sugli stessi limiti di soglia (14 e 30 giorni).
  • Costo: il confronto può essere automatizzato tramite API, ma il costo varia in base ai modelli scelti, al numero di chiamate e alla quantità di testo elaborata. Il tema è approfondito nel dossier sui token di Kimi.

Il principio della divergenza

Il Test di Divergenza (o differential testing) consiste in una procedura lineare: si fornisce lo stesso identico requisito logico a cinque modelli AI indipendenti (GPT, Gemini, Claude, Kimi e un modello locale tramite Ollama), lasciandoli generare implementazioni separate senza che comunichino tra loro. In seguito, si eseguono queste implementazioni parallele passandogli un ampio set di test input strutturati.

Quando i risultati differiscono, Divergo mostra il punto da controllare. La causa può essere un requisito ambiguo o mancante, oppure un errore in una delle implementazioni generate. Il confronto aiuta a trovare il problema prima del rilascio in produzione.

Il Metodo

Differential Testing per AI

Usare modelli di linguaggio differenti come generatori di interpretazioni indipendenti dello stesso requisito, trattando il loro disaccordo logico come una sonda automatica per scovare le lacune nei requisiti del software.

Una simulazione offline: il reso merci

Divergo include una simulazione didattica basata su questa regola: "reso gratuito entro 14 giorni se non usato, altrimenti rimborso del 50%. Tra 15 e 30 giorni rimborso del 60% solo se non usato, oltre 30 giorni nessun reso". Le implementazioni e i risultati mostrati qui sono simulati: non rappresentano risposte ottenute interrogando GPT, Kimi o Claude.

# Implementazione A (simulata)
if giorni_passati < 14:
    return prezzo_originario

# Implementazione B (simulata)
if giorni_passati <= 14:
    return prezzo_originario

Risultati della simulazione offline

Input Testato (Giorni reso) Implementazione A Implementazione B Implementazione C
Giorno 14 (Soglia) 60.0 (Rimborso tardivo) 100.0 (Gratuito) 100.0 (Gratuito)
Giorno 30 (Soglia) 60.0 (Rimborso) 60.0 (Rimborso) 0.0 (Nessun rimborso)

Le tre implementazioni simulate hanno interpretato "entro 14 giorni" ed "oltre 30 giorni" in modo diverso. Il confronto mostra che la specifica deve chiarire se le soglie sono incluse o escluse.

Prova live del 26 luglio 2026: OpenAI gpt-5.6-sol, Google gemini-3.6-flash, Anthropic claude-sonnet-5 e Moonshot AI kimi-k2.7-code-highspeed hanno prodotto risultati coerenti tra loro. Ollama mistral:latest ha restituito risultati diversi in sette casi, che Divergo ha segnalato e analizzato.

Attenzione al codice non validato: Se viene usata un'implementazione che esclude per errore il quattordicesimo giorno, il rimborso può essere calcolato in modo errato anche se il codice è sintatticamente corretto.

Limiti del metodo

  • Errore comune: se tutti i modelli interpretano male la specifica nello stesso modo, non emerge alcuna divergenza. Serve comunque una revisione dei requisiti critici.
  • Costi reali: interrogare più modelli richiede più chiamate. Il consumo cresce con requisiti lunghi e grandi quantità di testo.
  • Codice non valido: un modello può generare codice con errori. Divergo lo segnala, ma in questo caso il problema non nasce necessariamente da un requisito ambiguo.

Divergo v1.1, Strumento di Validazione Locale

Abbiamo creato un'utilità offline per Windows chiamata Divergo. Gira in locale e ti permette di eseguire test di divergenza su qualsiasi funzione. La versione 1.1 introduce la generazione dinamica dei test analizzando la specifica dei requisiti e il dibattito automatico delle divergenze, spiegando in linguaggio naturale l'ambiguità logica riscontrata.

Include sia una modalità offline (basata sulla simulazione del reso merci) sia la modalità live con OpenAI, Google Gemini, Anthropic Claude, Moonshot AI Kimi e modelli locali tramite Ollama. Le chiavi API restano sul computer dell'utente.

Vai alla pagina di Divergo