Linus Torvalds ha resuelto un error crítico en el controlador gráfico de Intel para Linux que llevaba semanas sin solución. La combinación de 24 parches y 18 reinicios del kernel dejó al descubierto una lección de programación asistida por inteligencia artificial que ha pasado casi desapercibida: el creador del kernel ignoró el diagnóstico de la IA cuando esta calificó el problema de imposible.
El fallo, registrado en el commit 818bebe, provocaba pantallas negras en el sistema Battlemage G21 de Torvalds cada vez que fallaba el gestor de pantallas. La solución final resultó mínima: cambiar la función round_up() por round_down(). Llegar hasta ahí le costó semanas: 24 parches, 18 reinicios del kernel y varias veces en las que el modelo de IA calificó el error como «imposible e irresoluble».
La IA repitió que el problema no tenía solución en Linux
La herramienta no se limitó a proponer pistas que no llevaban a ningún sitio. En varias sesiones de depuración declaró, de forma tajante, que el error era imposible e irresoluble, una conclusión que equivalía, de hecho, a pedirle a Torvalds que tirara la toalla y documentara el fallo como un caso sin salida. El desarrollador optó por seguir adelante pese a esa recomendación.
Ahí está el matiz que no debemos perder de vista cuando trabajamos con estas herramientas: que un modelo no encuentre la solución no significa que esta no exista. Si trabajáis a diario con algún asistente de IA, seguro que os habéis topado con esa misma seguridad rotunda, la que da por agotadas las opciones sin haberlas comprobado. Torvalds no dejó que ese tono pesara más que su propio criterio, y esa distinción es la que separa usar la IA como apoyo de dejar que decida por nosotros.
Reparto de tareas: la máquina ejecuta, el humano decide
En el resto del proceso, la división de trabajo fue clara. La IA se encargó de las tareas repetitivas: añadir salidas de depuración, probar cambios y encadenar los sucesivos reinicios del sistema. Torvalds dejó que redactara el mensaje final del commit, porque explicaba los hallazgos con claridad, y la acreditó por su nombre en las notas del parche.
Lo que no delegó fue el veredicto. Decidir si la investigación había llegado realmente a una respuesta siguió siendo tarea suya. Esa separación os puede servir de guía si usáis IA en vuestro propio trabajo: aprovechar la capacidad de la máquina para lo que agota la paciencia, sin renunciar al análisis crítico en el momento que define si el proyecto avanza o se estanca. El reparto no resta mérito al trabajo de la máquina, simplemente lo sitúa donde aporta más, dejando el criterio final para quien conoce el proyecto.
El conocimiento acumulado que ningún modelo tiene
Resolver este fallo exigía entender el papel exacto del controlador gráfico dentro del sistema, algo distinto de describir qué está haciendo en un momento dado. Torvalds ha acumulado ese conocimiento durante décadas trabajando en el kernel de Linux, y ningún modelo actual dispone de ese historial. Ese bagaje podría incluir recordar decisiones de diseño adoptadas hace años y por qué ciertos atajos nunca funcionaron.
Las herramientas de IA pueden describir con detalle un comportamiento sin identificar qué parte de ese comportamiento es la que realmente falla. Es probable que también falte la memoria de cómo evolucionó ese código y el conocimiento de las dependencias ocultas que solo adquiere quien ha mantenido el proyecto durante años. Por eso, cuando el modelo asegura que algo no tiene solución, conviene preguntarse si esa afirmación nace de un análisis exhaustivo o de los límites de lo que la herramienta puede ver.
La regla que sirve para cualquier proyecto, no solo para el kernel
Os estaréis preguntando si esta lección se limita al desarrollo del sistema operativo. No es así: un script de automatización que se detiene a mitad de ejecución, una hoja de cálculo con fórmulas enrevesadas o un conflicto entre plugins de WordPress puede generar la misma respuesta: el modelo asegura, con total seguridad, que la tarea no tiene solución.
Antes de aceptar ese diagnóstico, conviene preguntarse si disponemos de información que la IA no puede inferir por sí sola: el objetivo original, el comportamiento esperado del sistema o la experiencia de haberlo visto funcionar antes. Habrá casos en los que lo imposible para el modelo lo sea de verdad, pero determinarlo sigue siendo trabajo nuestro, no de la máquina. El fallo del controlador gráfico quedó documentado en el commit 818bebe, prueba de que delegar la búsqueda no obliga a delegar también el juicio.