Las cifras atribuidas a una presentación de Roman Gushchin, ingeniero de Google, en Linux Plumbers Conference —celebrada del 5 al 7 de octubre de 2026— sitúan a Sashiko por encima de 191.000 revisiones de parches del kernel Linux, repartidas entre 99 listas de correo y realizadas en menos de un año. Son recuentos de actividad; el benchmark publicado por el proyecto mide otro aspecto y se limita a una prueba retrospectiva concreta.
Qué cuentan las cifras de actividad
Una revisión es un análisis automatizado de un parche, es decir, un cambio propuesto para el kernel. El recuento de más de 191.000 contabiliza revisiones efectuadas; la incorporación de un cambio al kernel es una etapa distinta.
El balance gráfico correspondiente al periodo marzo-octubre de 2026 recoge 19,3 millones de consultas autónomas a herramientas Git. La actualización también atribuye a Sashiko más de 7.600 respuestas de más de 1.100 desarrolladores del kernel. Se comunicaron, además, 1.277 referencias a Sashiko en commits de linus/master y 1.567 en linux-next/master.
La cifra relacionada con vulnerabilidades es de 463 registros CVE que incluyen referencias a Sashiko. Cuenta menciones en esos registros: no es un recuento de vulnerabilidades descubiertas por el sistema.
Qué mide el benchmark del proyecto
El proyecto publica una tasa de detección del 53,6 % en un benchmark retrospectivo con Gemini 3.1 Pro. La prueba tomó los últimos 1.000 commits upstream sin filtrar que llevaban la etiqueta Fixes: y evaluó errores que ya habían pasado la revisión humana y se habían incorporado a mainline.
Ese resultado describe esa muestra y ese modelo; no mide una tasa general de acierto en revisiones en directo. El repositorio también sitúa por debajo del 20 % los falsos positivos en un muestreo manual, sobre todo observaciones de «zona gris». La herramienta advierte que sus resultados son probabilísticos y pueden variar entre ejecuciones.
Revisión local y papel humano
Sashiko permite revisar cambios desde un checkout local del kernel con el comando sashiko review; el repositorio también describe revisiones automatizadas desde listas de correo y forjas Git. El flujo de inicio documentado requiere Rust 1.90 o posterior, Git y una clave de API de un proveedor de modelos de lenguaje (LLM).
El flujo local envía al proveedor configurado los datos del parche y el contexto pertinente del repositorio. El análisis pasa por varias etapas —entre ellas, implementación, flujo de ejecución, recursos, bloqueos y seguridad— antes de consolidar hallazgos candidatos. Los resultados sirven para que las personas que mantienen el kernel valoren los cambios; no sustituyen esa revisión humana.
