Sashiko ha superato 191.000 revisioni di patch Linux su 99 mailing list in meno di un anno, secondo i dati attribuiti a Roman Gushchin, ingegnere di Google, durante la Linux Plumbers Conference, tenuta dal 5 al 7 ottobre 2026. Il progetto ha anche pubblicato un benchmark in cui il sistema ha rilevato il 53,6% di una precisa categoria di bug: quelli già passati dalla revisione umana e integrati nel kernel.
L’attività di revisione riportata di Sashiko
Il conteggio delle revisioni misura quante volte Sashiko ha analizzato patch, cioè modifiche proposte al codice del kernel Linux. Non è un conteggio di modifiche accettate: descrive l’attività del sistema. Un riepilogo delle metriche per marzo-ottobre 2026 riporta inoltre 19,3 milioni di interrogazioni autonome a Git.
Tra gli altri numeri riferiti figurano più di 7.600 risposte da oltre 1.100 sviluppatori del kernel. Un conteggio annuale attribuisce a Sashiko 1.277 citazioni nei commit di linus/master e 1.567 in linux-next/master. Il dato sui CVE del kernel riguarda 463 record che citano Sashiko: misura i riferimenti, non le vulnerabilità individuate dal sistema.
Il benchmark del progetto e il suo ambito
Il repository di Sashiko riporta un rilevamento del 53,6% in un benchmark su Gemini 3.1 Pro. Il test ha preso in esame gli ultimi 1.000 commit upstream non filtrati con tag Fixes:; i bug cercati erano quelli che avevano già superato la revisione umana ed erano stati integrati nel ramo principale del kernel.
È quindi un risultato riferito a una popolazione retrospettiva precisa, non una misura generale del successo di ogni revisione in corso. Il progetto riferisce anche che un campionamento manuale ha stimato sotto il 20% i falsi positivi, perlopiù segnalazioni su questioni borderline. La documentazione avverte che le risposte sono probabilistiche e possono variare anche ripetendo l’analisi sullo stesso input.
Revisione locale e valutazione umana
Sashiko può analizzare un checkout locale del kernel oppure operare automaticamente a partire da mailing list e forge Git. Per avviare una revisione locale, il progetto documenta il comando sashiko review, che può esaminare un commit o un intervallo di commit. Il flusso usa una copia temporanea di lavoro e lascia intatti l’albero di lavoro e i metadati Git originali.
La configurazione richiede Rust 1.90 o successivo, Git e una chiave API per un provider di modelli linguistici. La pipeline combina analisi parallele — per esempio di flusso di esecuzione, risorse, blocchi, sicurezza e hardware — con una fase successiva che verifica e organizza le possibili segnalazioni. Le patch e il contesto pertinente del repository vengono inviati al provider configurato; le revisioni a più passaggi possono comportare costi API significativi.
