El kernel de Linux siempre funcionó como una meritocracia técnica rigurosa: el código entra si supera la revisión de pares. Esa compuerta se está atascando. Con la versión 7.3 en desarrollo, los mantenedores del subsistema de red —Jakub Kicinski y Paolo Abeni— estiman que entre un tercio y la mitad de los envíos a net-next son correcciones de baja prioridad, ajustes menores y aclaraciones producidas por modelos de lenguaje. No aportan valor. Solo ruido.
La aritmética es brutal. Este ciclo se integraron 632 cambios en la sección de red y 648 en net-next. Cada parche, por irrelevante que sea, exige lectura, contexto y verificación. La IA genera a velocidad de máquina; los humanos revisan a velocidad de persona. El resultado es una asfixia selectiva: los expertos —recurso escaso y sin sustitutos locales— gastan ciclos filtrando basura en lugar de resolver bugs críticos.
El problema no es que la IA escriba código malo. Es que escribe código plausible sin entender la arquitectura. Los modelos no captan invariantes de subsistema, disciplina de bloqueo, convenciones de API ni interacciones transversales. Producen parches que compilan, pasan tests básicos y silencian un crash, pero violan restricciones que solo un revisor humano detecta. Eso obliga a ciclos iterativos: v1, v2, v3… hasta v6 o más. Un estudio de la Universidad de Illinois Chicago y la Universidad de Indiana reconstruyó 6.946 ciclos de vida de bugs reportados por syzbot —la infraestructura de fuzzing continuo de Google— y confirmó que las correcciones aceptadas son frecuentemente no locales y moldeadas por restricciones que el reporte original no menciona.
La ironía duele: syzbot aceleró el hallazgo de bugs, pero la promesa de "IA que arregla bugs" está rompiendo el cuello de botella posterior. Los investigadores proponen PatchAdvisor, un sistema que aprende del historial de revisiones para guiar agentes hacia parches alineados con lo que los mantenedores aceptan. Funciona mejor que la generación a ciegas, pero admite que es una prueba de concepto. Mientras tanto, la avalancha real sigue llegando.
Linus Torvalds ha llevado la queja a la lista de seguridad: los informes de errores generados por IA la han vuelto "casi completamente inmanejable". No rechaza las herramientas —dice que son geniales si realmente ayudan—. Critica el uso superficial: diferentes personas usando las mismas herramientas envían reportes duplicados de fallos que ya se resolvieron semanas atrás. La lista es privada, así que los propios remitentes no ven lo que ya se envió. Torvalds pide menos "copiar y pegar" y más trabajo real: leer la documentación, preparar un parche, aportar contexto.
Greg Kroah-Hartman, otro pilar del kernel, tiene una visión más optimista: asegura que los informes asistidos por IA han evolucionado desde envíos de baja calidad hasta contribuciones útiles. El debate está abierto, pero la tensión es estructural.
Un análisis académico de 7.703 archivos atribuidos a cuatro herramientas mayores —ChatGPT, GitHub Copilot, Amazon CodeWhisperer y Tabnine— encontró 4.241 instancias CWE en 77 tipos de vulnerabilidad. Python exhibió tasas consistentemente más altas (16-18%) frente a JavaScript (8-9%) y TypeScript (2-7%). El 39% de los archivos eran documentación generada por IA, un vector de mantenibilidad poco estudiado.
Quién gana con esta dinámica no son los mantenedores. Ganan las plataformas que venden "productividad de desarrollador" medida en líneas de código o pull requests por hora. Métricas vanas que ignoran el coste externo: la atención de los guardianes del kernel. Cada parche IA irrelevante es una micro-transferencia de riqueza desde el mantenimiento comunitario hacia el proveedor del modelo. La comunidad Linux no tiene facturación para cobrar esa externalidad.
Para Latinoamérica, la lección es doble. Primero: las empresas que adoptan asistentes de codificación para contribuir al kernel o auditar su cadena de suministro deben presupuestar revisión humana experta, no solo generación. El coste marginal de un parche IA es cero; el coste marginal de revisarlo no lo es. Segundo: la dependencia de Linux en infraestructura crítica —bancos, telcos, nube pública, edge— significa que la saturación de mantenedores es un riesgo sistémico regional. No hay sustitutos locales para Kicinski o Abeni.
Llegará tarde e imperfecta la solución técnica —mejores filtros, puntuación de confianza, bots que rechacen parches sin firma de humano calificado—. La solución política es más incómoda: reconocer que la IA generativa, sin gobernanza de comunidad, es un ataque de denegación de servicio distribuido sobre la capacidad de revisión experta. Mientras los ejecutivos evalúan copilotos para "acelerar desarrollo", la infraestructura invisible que sostiene sus nubes pide a gritos que dejen de tirar basura al pozo común.
¿Cuántos ciclos de revisión más aguantará el modelo de desarrollo abierto antes de que los expertos decidan que el coste de filtrar ruido supera el valor de seguir participando?
