{"id":4607,"date":"2026-04-07T03:01:41","date_gmt":"2026-04-07T02:01:41","guid":{"rendered":"https:\/\/www.fullo.net\/blog\/?p=4607"},"modified":"2026-04-07T09:19:49","modified_gmt":"2026-04-07T08:19:49","slug":"adversarial-verification-claude-skill","status":"publish","type":"post","link":"https:\/\/www.fullo.net\/blog\/2026\/04\/07\/adversarial-verification-claude-skill\/","title":{"rendered":"Adversarial verification come metodo"},"content":{"rendered":"\n

Se avete letto il post sugli agenti disfunzionali<\/a>, conoscete gi\u00e0 la storia. Stavo sviluppando CarePlatform con cinque agenti AI in ruoli espliciti: PM, Developer, QA, Security, UX. Le prime otto iterazioni sembravano filare lisce. I task venivano contrassegnati come completati. I test salivano: 35, 92, 200. Tutto sotto controllo. Solo che non lo era.<\/p>\n\n\n\n\n\n\n\n

L’activity logging era contrassegnato come effettuato. Il trait LogsActivity<\/code> non era mai stato applicato a nessun modello. QA non aveva segnalato nulla. Security non aveva alzato la mano. L’equivalente digitale di installare un antifurto senza collegare i sensori.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Da quel momento ho iniziato a riscrivere i prompt introducendo l\u2019adversarial verification esplicita: ogni agente doveva sfidare il lavoro degli altri, fornire evidenza concreta per ogni claim e ricevere uno scrutinio proporzionato alla propria storia di falsi positivi. Ha funzionato, nel senso che i bug emergevano prima di arrivare in produzione.<\/p>\n\n\n\n

Il problema \u00e8 che quel metodo viveva nei prompt. Ogni progetto nuovo richiedeva di ricostruirlo da zero, di ricordarsi di inserirlo, di sperare di non dimenticare uno dei domini critici. Un approccio efficace ma non trasferibile.<\/p>\n\n\n\n

adversarial-verify <\/a>\u00e8 un tentativo di renderlo trasferibile.<\/p>\n\n\n\n

Cosa fa, concretamente<\/h2>\n\n\n\n

La skill applica la metodologia Chain-of-Verification (CoV)<\/a> di Dhuliawala et al. (2023) combinata con tecniche che vengono dalla ricerca sull’alignment degli LLM \u2014 un campo che, a prima vista, sembra lontano dalla code review ma che condivide un problema fondamentale identico: come fai a trovare comportamenti problematici che il sistema non ha nessun incentivo a dichiararti?<\/p>\n\n\n\n

Abstractive Red-Teaming<\/strong> \u2014 invece di cercare singoli bug, cerca pattern ricorrenti di errore nell’intero codebase. Nei paper di Anthropic, questa tecnica (Rahn et al., 2026<\/a>) viene utilizzata per individuare categorie di query che elicitano violazioni di carattere nei modelli linguistici; ho analizzato i comportamenti osservati e li ho utilizzati come ispirazione per estendere il concetto al dominio della code review. La logica di fondo \u00e8 la stessa: non cercare istanze singole, ma classi di situazioni in cui i problemi emergono sistematicamente.<\/p>\n\n\n\n

Hidden Behavior Probing \u2014<\/strong> rileva comportamenti che il codice non dichiara, tracciando i path di esecuzione effettivi anzich\u00e9 quelli previsti. Se una funzione dice di fare X ma, in certi contesti, fa Y, la skill lo riconosce.<\/p>\n\n\n\n

Modular Adversarial Scaffold<\/strong> \u2014 modella ci\u00f2 che un reviewer umano non noterebbe e cerca proprio l\u00ec. Ispirata direttamente all’approccio di AuditBench<\/a> (Anthropic, 2026), che costruisce benchmark su comportamenti nascosti che i modelli sono addestrati a non rivelare quando gli si chiede direttamente. Anche qui il trasferimento non \u00e8 letterale ma di principio: un reviewer umano ha gli stessi punti ciechi di un agente AI che ottimizza per la plausibilit\u00e0 locale.<\/p>\n\n\n\n

I cinque domini verificati:<\/p>\n\n\n\n