Linus Torvalds publicó el 8 de noviembre de 2026 el anuncio de la versión 7.4-rc2 del kernel de Linux y, entre los párrafos de trámite, dejó una frase que cambia el tono de la conversación: buena parte del trabajo de mantenimiento de las últimas semanas fueron correcciones asistidas por inteligencia artificial y piensa dejar de repetirlo en cada correo. En el archivo oficial del proyecto, la 7.4-rc2 figura como línea principal desde el 9 de noviembre, con la 7.3.4 ya publicada como estable.
El dato que sostiene ese cambio de tono no es suyo. Alexei Starovoitov, mantenedor de BPF, el mecanismo de filtros programables que el kernel usa para inspeccionar tráfico y llamadas al sistema, trasladó que el ritmo de correcciones en esa parcela supera ya al de informes nuevos de fallos. Si la proporción se mantiene, ese equipo deja de limitarse a tapar lo que llega y empieza a vaciar la cola vieja.
El hallazgo es modesto y el propio Torvalds lo acota: la mayoría de las otras áreas del kernel no ha llegado a ese punto y, en el mejor de los casos, es señal de que la marea puede estar girando. Lo interesante no es el titular sobre máquinas que programan, sino que una corrección que cierra un fallo antiguo reduce riesgo acumulado de verdad, mientras el anuncio de que dejará de mencionarlo abre una pregunta incómoda sobre auditoría.
¿Qué dijo Torvalds y qué dejó fuera?
El correo del 8 de noviembre de 2026 llega tras un ciclo de mucho volumen. Torvalds describe la 7.4-rc2 como una candidata grande y la compara con la rc1 anterior, que califica sin matices como la más grande de la historia del kernel.
Buena parte de ese tamaño tuvo origen mecánico: actualizaciones automáticas de Coccinelle, la herramienta que reescribe patrones de código en masa y que lleva años moviendo miles de líneas por ciclo. Eso engorda el recuento de parches sin que haya una función nueva detrás de cada uno, un detalle que conviene tener presente antes de leer las cifras como un auge repentino de actividad humana o de actividad asistida.
En el anuncio de la 7.4-rc2 la frase clave es una cesión de terreno. Torvalds escribe que buena parte del mantenimiento reciente fueron correcciones con ayuda de IA y que dejará de repetirlo porque, a estas alturas, puede darse por supuesto. No hay lista de herramientas ni recuento de parches. Tampoco aparecen los ficheros tocados.
Esa ausencia de detalle no es un descuido de redacción, y tampoco una omisión menor: sin inventario público, nadie puede medir qué parte del código aceptado salió de un modelo ni en qué áreas se concentra.
Lo que sí queda claro es el límite del mensaje. No sostiene que el kernel se escriba con IA, no ofrece porcentajes y no insinúa que se acepte código generado sin la revisión de siempre. Un parche asistido sigue pasando por las mismas manos y las mismas pruebas, y esa es la única garantía que el proceso puede ofrecer hoy. Los cambios que trae la 7.4-rc2 pasaron por ese mismo filtro, como cualquier otra candidata.
¿Por qué una corrección pesa más que un parche nuevo?
Un fallo que lleva meses en el árbol es riesgo que se paga a diario: cada versión estable lo hereda y cada distribución lo arrastra a servidores, teléfonos y routers. Una corrección retira ese riesgo de golpe, mientras que una función nueva añade superficie y obliga a revisar más código del que había antes.
Por eso el indicador que importa no es cuántos parches entran, sino si el equipo que atiende un área llega a cerrar más de lo que recibe. En términos de cola, corregir lo viejo y corregir lo nuevo se parecen poco: lo primero descuenta deuda, lo segundo la mantiene estable. Esa distinción explica por qué una nota de una línea en un correo de release puede valer más que un hito de rendimiento.
La 7.4 también ha tocado el inventario de funciones que el proyecto consideraba peligrosas y que Torvalds decidió retirar del árbol, otra limpieza que reduce superficie de ataque sin añadir capacidad nueva.
Riesgo acumulado no es lo mismo que gravedad, y el ratio de un área tampoco distingue: se pueden cerrar cien correcciones menores en un mes y seguir arrastrando un fallo crítico abierto desde hace dos años.
De ahí que el aviso sea más informativo por lo que restringe que por lo que celebra. El propio mensaje señala que la mayoría de las otras áreas no ha llegado a ese punto, así que el éxito de BPF funciona como excepción visible y no como tendencia general del árbol. Un mantenedor que vacía su cola no demuestra que el resto pueda hacerlo.
El dato de BPF en contexto
Conviene separar lo que cada señal mide de lo que sugiere, porque el anuncio mezcla tres cosas distintas en pocos párrafos y solo una de ellas tiene números detrás: el estado de una cola concreta, en un momento concreto del ciclo.
| Señal en el anuncio |
Qué mide |
Qué deja fuera |
| Correcciones con ayuda de IA |
volumen de mantenimiento reciente, sin cifra |
qué herramientas y qué parches concretos |
| Ritmo de correcciones en BPF |
entradas frente a salidas de la cola de un área |
gravedad, latencia de los arreglos y regresiones |
| 7.4-rc1 y rc2 grandes |
tamaño de la ventana de fusión |
cuánto de ese volumen es automático |
| Resto del kernel |
el reconocimiento de que no llega a ese punto |
qué áreas van por detrás y por qué |
| Proceso de revisión |
que no se anunciaron cambios |
trazabilidad del origen de cada parche |
La lectura útil de la tabla es la segunda fila. El ratio de BPF compara llegadas con salidas en una parcela concreta, no mide calidad ni antigüedad de lo corregido, y tampoco dice si el arreglo lo encontró una persona o un modelo. Una cola que baja es buena noticia operativa, y a la vez puede esconder que lo fácil se cierra antes que lo difícil.
Tampoco hay cifras públicas detrás de la observación de Starovoitov: sin recuentos de informes y de arreglos por semana, el ratio funciona como la impresión de quien lleva el área, que vale mucho, pero no como una medición que otro pueda replicar.
El calendario ordena el resto. La segunda parte del repaso del merge window de la 7.4 se publicó el 2 de noviembre, y el 10 de noviembre la rama estable ya iba por la 7.3.4, con la 7.2.15 marcada como fin de vida desde el día 1. Quien quiera ver el efecto de estas correcciones en su propio equipo tiene la vía de compilar un kernel propio, que sigue siendo la forma más directa de comprobar qué parches aterrizan y cuáles no.
Un mantenimiento que se normaliza sin rastro público
A estas alturas, la pregunta ya no es si la IA ayuda a mantener el kernel, sino si el rastro de esa ayuda sobrevive a la próxima candidata. Cuanto más mantenimiento automatizado hay, más falta hace saber de dónde sale cada parche que toca memoria o red en un servidor ajeno, y el anuncio del 8 de noviembre deja esa parte fuera del correo.
La parte menos citada del anuncio es la que más debería pesar a medio plazo. Si el mantenimiento asistido deja de señalarse, el origen de los parches deja de ser un dato público, y con él desaparece la posibilidad de discutir qué clases de fallo encuentran los modelos y cuáles se les escapan. No hace falta sospechar del proceso para echar de menos un registro que hasta hace poco se consideraba parte del anuncio.
Un identificador en el parche, del tipo que ya se usa para reconocer coautorías y revisiones, resolvería la trazabilidad sin tocar la revisión. Cuesta una línea por envío y devuelve algo que ningún correo de release puede dar: la posibilidad de contar. Sin eso, la normalización avanza y la evidencia se queda en la puerta.
