This content is currently only available in Spanish. English translation is on the roadmap — in the meantime, here's the original.
El cuello de botella del kernel ya no es escribir código, es revisarlo
"Given the current throughput in the kernel resulting from AI-generated series, I unfortunately lack the bandwidth to generally be able to offer review except in those areas I maintain."
Esa frase está en el mensaje de un commit al archivo MAINTAINERS del kernel Linux. La firma Lorenzo Stoakes, ingeniero de Arm y una de las personas que más revisa en la gestión de memoria (mm). No se va del kernel ni deja lo que mantiene. Simplemente dice que no puede con todo.
Qué ha pasado
Stoakes ha enviado una serie de cuatro parches. Tres lo quitan como revisor de las secciones MM core, MM misc y MM rust del archivo MAINTAINERS; el cuarto añade una entrada en CREDITS por su etapa como co-mantenedor de THP (las huge pages transparentes), algo que ya había dejado en verano. Sigue como mantenedor en sus áreas.
Parece un cambio administrativo, pero tiene consecuencias prácticas. Herramientas como get_maintainer.pl leen ese archivo para decidir a quién se le manda cada parche, así que en cuanto se fusione dejará de recibir buena parte de lo que le llegaba. En la entrevista que concedió a The Register, según recoge la prensa, contaba que los envíos generados con IA han pasado de ser algo esporádico a cerca de la mitad de lo que le entra para revisar. Ese dato es suyo y no lo he podido contrastar con nada más.
Lo curioso es el momento. Casi a la vez, varios medios recogían comentarios de Linus Torvalds sobre la 7.4-rc2 en los que veía con buenos ojos que las correcciones asistidas por IA se estén volviendo algo normal. Las dos cosas son ciertas a la vez, y ahí está lo interesante.
Mi lectura: el problema es la asimetría
En soporte esto tiene nombre, aunque sea a otra escala. Cuando abrir un ticket cuesta cero, los tickets se multiplican, y el cuello de botella pasa al técnico que tiene que leerlos, entenderlos y descartar los que no llevan a ningún sitio. El volumen no lo absorbe la herramienta, lo absorbe una persona.
Con el kernel pasa igual, pero peor. Un parche en mm puede parecer correcto, compilar y pasar los tests, y aun así romper algo sutil en reclaim o en un caso límite de concurrencia que solo ve alguien con años en ese código. Generarlo con un modelo lleva minutos. Revisarlo bien lleva lo mismo que antes. Y la gente capaz de hacerlo en mm cabe en una sala pequeña.
Mi postura: el kernel no debería intentar filtrar "parches de IA" como categoría, porque eso es imposible de verificar y además injusto con quien usa la herramienta bien. Lo que sí debería hacer es subir el coste de enviar. Exigir que quien manda un parche explique qué ha probado y en qué hardware, que lo declare si un modelo ha hecho el trabajo pesado, y que los mantenedores puedan ignorar sin culpa a quien manda series en bruto una y otra vez.
El mejor argumento del otro lado es serio: la IA está encontrando bugs reales, y hay gente que gracias a estas herramientas contribuye por primera vez. Poner barreras puede espantar justo a quien el proyecto necesita como relevo. Lo reconozco. Pero un proyecto que quema a sus revisores para ganar contribuidores nuevos está cambiando lo escaso por lo abundante.
Como estudiante de Ingeniería en IA, esto me deja una idea incómoda. Pasamos mucho tiempo midiendo lo bien que un modelo escribe código y muy poco midiendo lo que cuesta comprobar que ese código es correcto. Y en sistemas, el que paga ese coste suele ser siempre el mismo: el que está al otro lado de la cola.
Si el recurso escaso del software libre ya no es quien escribe, sino quien revisa, ¿no deberíamos estar construyendo herramientas para ellos antes que para los que envían?
