La señal sobre eBPF es local: allí, según lo que Linus Torvalds atribuyó a Alexei Starovoitov, las correcciones llegaban más rápido que los nuevos reportes. Torvalds dijo que la mayoría de las demás áreas del kernel aún no presentaba ese balance. El reporte sobre Linux 7.4-rc2 se publicó el 9 de noviembre de 2026; esa fecha corresponde al informe, no a la publicación de la versión candidata.
Qué indica el balance de eBPF
El dato compara dos flujos en un subsistema: las correcciones y los nuevos reportes de fallos. No es un recuento de todos los envíos asistidos por IA en Linux ni de los parches aceptados en todo el kernel. Por eso, el balance descrito para eBPF no basta para afirmar que la avalancha de parches de IA haya alcanzado su pico general.
La diferencia importa: los reportes señalan posibles problemas; las correcciones son trabajo dirigido a resolverlos. Un cambio en la relación entre ambos dentro de eBPF no describe por sí solo lo que ocurre en las demás áreas del kernel.
Este seguimiento aborda un desarrollo distinto del caso de assoc_array que NeoTeo ya había contado, cuando Torvalds recurrió a herramientas de IA para examinar ese código.
Qué espera Torvalds de quienes presentan hallazgos con IA
En una entrevista publicada por SavvyNik el 26 de agosto de 2026, Torvalds explicó que comprobar si un reporte generado con un modelo de lenguaje describe un fallo real puede exigir bastante trabajo. Quien presenta el hallazgo debería proponer un parche y seguir disponible para conversar con los mantenedores. Así, el reporte no queda separado de la persona que puede explicar cómo se encontró y ayudar a discutir una solución.
Un hallazgo asistido por IA aporta más cuando quien lo presenta puede ayudar a comprobarlo, proponer una corrección y conversar con los mantenedores.
Una demostración rápida no equivale a código de producción
Torvalds también distinguió entre crear una demostración con rapidez y producir código listo para integrarse. En esa entrevista dijo que no estaba convencido de que los modelos de lenguaje necesariamente acelerasen el desarrollo de código de producción. El hallazgo de un posible fallo, su verificación y una corrección adecuada son tareas distintas; la rapidez de una demostración no resuelve por sí sola las otras.
