Linus Torvalds depura un bug en Linux con IA tras 24 parches

Linus Torvalds y la IA: del escepticismo histórico al pragmatismo

El creador de Linux, Linus Torvalds, no necesita presentación: lleva más de tres décadas al frente del proyecto de software libre más importante del planeta. Lo que sí cambia con los años es su relación con la IA. Hasta hace poco era público su escepticismo hacia el uso masivo de modelos generativos en el kernel; sin embargo, en julio de 2026 publicó en la lista de correo del kernel que «AI es una herramienta, igual que otras herramientas que usamos. Y claramente es una útil» y zanjó el debate interno: Linux no se convertirá en un proyecto anti-IA. Quien no esté de acuerdo, dijo, puede hacer un fork o simplemente irse, según recogió ADTMag.

Esa postura coincide con la formalización de la primera política oficial del kernel sobre contribuciones asistidas por IA. Como explica ZDNet, las nuevas reglas establecen tres principios: la IA no puede añadir etiquetas Signed-off-by (que certifican legalmente el origen del código), las contribuciones con asistencia de IA deben incluir un Assisted-by tag indicando modelo y herramientas, y el humano que envía el parche asume toda la responsabilidad.

El bug que la IA quería dar por imposible

El episodio que ha vuelto a poner a Torvalds en el foco ocurrió con el controlador Xe, el driver del kernel encargado de gestionar las GPU de Intel. El fallo era sutil: la dirección de memoria reservada para el almacenamiento CCS se redondeaba hacia arriba cuando debía hacerse hacia abajo. Cuando esa memoria mal calculada coincidía con las tablas de páginas de la GPU, el resultado era corrupción de pantalla y, en los casos más graves, del propio sistema, según recoge el artículo de Hipertextual.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Lo relevante para cualquier desarrollador es el coste humano de aislar el problema. Torvalds explicó en la lista de correo que necesitó más de 24 parches sucesivos solo para añadir información de depuración, y 18 arranques del kernel antes de identificar la causa exacta. En el camino, el asistente de IA al que recurrió llegó a afirmar, en varias ocasiones, que el problema no tenía solución y que lo razonable era limitarse a documentar el fallo. Torvalds no aceptó y siguió forzando al modelo a generar código de instrumentación adicional.

«Sospecho que esas cosas han sido entrenadas por personas que tal vez no sean tan tercas como yo», bromeó al cerrar el hilo. La persistencia dio resultado: tras identificar la función mal aplicada que provocaba el error, dejó que fuera la propia IA la que redactara el mensaje del commit final.

La nueva política del kernel: humanos responsables, IA como herramienta

Lo de Torvalds con el driver Xe es la excepción que confirma la regla. En el ciclo de desarrollo de Linux 7.1, según TechSpot, Torvalds mostró su hartazgo con los reportes de bugs generados por IA que saturan las listas de correo, generan duplicados y obligan a los maintainers a separar señal de ruido. Su petición fue directa: quien envíe un reporte asistido por IA debe verificarlo y comprometerse con la solución, no hacer un drive-by report.

La línea oficial queda sintetizada en la política de Assisted-by:

Transparencia: toda contribución con ayuda sustancial de IA debe etiquetarse con el modelo, agente y herramientas auxiliares usadas (por ejemplo, Assisted-by: Claude:claude-3-opus coccinelle sparse).
Responsabilidad humana: el Signed-off-by legal lo firma una persona; esa persona responde por la corrección, la licencia y los fallos de seguridad que pueda introducir el código.
No se prohíbe el uso: se obliga a declarar el uso. La penalización es reputacional y de revisión extra, no la exclusión.

El debate no es solo filosófico. Como resume ZDNet, hay dos problemas prácticos abiertos: los parches creíbles (código que compila, pasa smoke tests y aun así codifica un bug sutil o una deuda de mantenimiento a largo plazo) y los reportes de vulnerabilidades duplicados que inundan los canales de seguridad. La política no pretende cazar a los infractores: asume que algunos se colarán y sube el coste de ser descubierto.

Qué significa esto para tu startup

Que el maintainer más exigente del software libre haya pasado de «la IA entorpece el kernel» a «es claramente útil, pero bajo reglas» es una señal interesante para cualquier equipo técnico. Las conclusiones prácticas son tres:

Asume la IA como copiloto, no como autor. El patrón de Torvalds (instrumentar el código, iterar sobre logs reales, dejar que el modelo redacte solo el texto rutinario) es replicable en cualquier startup que tenga un bug complejo enquistado. La IA acelera el triage, no el fix.
Documenta el uso de IA en tu código y en tus PRs. Si el kernel de Linux va a pedir Assisted-by tags, tus clientes enterprise, auditores SOC 2 o revisores de due diligence técnica pueden exigírtelo mañana. Adelantarte es barato y te diferencia.
Filtra el ruido antes de escalar al CTO o al founder. El mismo problema que tiene Torvalds con RC5 (muchos reportes automáticos de baja calidad) lo tiene cualquier equipo que recibe tickets generados por IA: invierte tiempo en definir criterios de aceptación para que un bug report cuente como válido antes de que toque a un humano.

Si trabajas con un equipo pequeño y código crítico (fintech, salud, infra), la lección es que la IA no elimina la necesidad de ingeniería senior: solo cambia su trabajo. El senior pasa de teclear a presionar al modelo hasta que reconozca el bug, exactamente como hizo Torvalds. Tu próxima contratación ya no compite con un LLM en velocidad: compite en terquedad metódica y criterio técnico.