El desarrollo del kernel de Linux se sostiene sobre una premisa que no admite atajos: el código debe ser correcto, justificado y sostenible durante décadas, porque una vez que entra en el árbol principal va a vivir en millones de máquinas que nadie termina de inventariar. Esa premisa es la que empezó a tensionarse en 2026, cuando la irrupción de la IA generativa en el flujo de contribuciones obligó a los mantenedores más veteranos del proyecto a repensar, en tiempo real, cómo se audita el trabajo de una máquina que redacta con la misma soltura con la que se equivoca.

Nadie representa mejor esa tensión que Greg Kroah-Hartman, mantenedor de la rama estable del kernel y una de las voces con más autoridad moral del proyecto. A comienzos de 2026 describía el fenómeno con una palabra que se volvió estándar en la jerga del kernel: “slop”. Reportes de seguridad generados por IA que sonaban plausibles pero no resistían un segundo de escrutinio, con razonamientos ilógicos, vulnerabilidades inexistentes y rutas de código que simplemente no se correspondían con la realidad del proyecto. Kroah-Hartman llegó a decir que, en ese momento, el fenómeno “no preocupaba demasiado” (The Register) porque el kernel, a diferencia de proyectos más chicos, tiene suficientes mantenedores como para repartirse el ruido. curl no tuvo esa suerte: los reportes falsos generados por IA fueron uno de los motivos por los que Daniel Stenberg terminó suspendiendo el pago de recompensas por bugs en su programa de seguridad.

Lo interesante —y lo que la nota original que armaste no llega a capturar— es que esa historia no es lineal. Según el propio Kroah-Hartman, algo cambió de manera casi simultánea en todo el ecosistema de código abierto alrededor de marzo de 2026: “empezamos a recibir reportes reales, bien escritos, que efectivamente señalaban un bug y a veces venían con un parche” (OpenSSF, What’s in the SOSS? #64). GitHub, curl, HAProxy y el propio kernel coincidieron en el mismo salto de calidad, sin que nadie —ni siquiera él— pudiera explicar con precisión qué lo produjo. El propio Kroah-Hartman se puso a experimentar con la herramienta: le pidió que encontrara problemas en el código y recibió sesenta sugerencias, un tercio equivocadas pero apuntando a un problema real, y dos tercios efectivamente correctos, aunque necesitaran limpieza humana antes de convertirse en parches presentables (The Register).

Ese matiz importa porque cambia el diagnóstico. El problema que describís en tu borrador —código que parece impecable pero esconde errores sutiles— sigue siendo real, pero ya no es el cuadro completo. La comunidad no está simplemente defendiéndose de una invasión de ruido: está aprendiendo, con bastante fricción, a distinguir entre la IA como generadora de basura plausible y la IA como herramienta de auditoría que efectivamente encuentra bugs que los revisores humanos vienen pasando por alto hace años. Esa segunda función quedó ilustrada con Sashiko, el revisor agéntico construido por Roman Gushchin, de Google, que corre sobre Gemini y que Kroah-Hartman respaldó públicamente: sometido a mil issues recientes del kernel etiquetados como “Fixes”, el sistema encontró alrededor de la mitad de los bugs que ningún revisor humano había detectado (ByteIota). Es una asimetría incómoda de sostener: una herramienta que corre sobre un modelo en la nube encontró errores en código que cientos de contribuyentes experimentados ya habían leído.

La respuesta institucional del proyecto no fue, sin embargo, un abrazo acrítico ni un rechazo de bloque. Fue algo más quirúrgico. En agosto de 2026, Kroah-Hartman publicó en la lista de correo de linux-staging una política que prohíbe activamente los parches generados por LLM en ese subsistema específico (lore.kernel.org, vía It’s FOSS), citando un “aluvión” de envíos automatizados. La razón no tiene que ver con la calidad del código sino con la función social de ese árbol: drivers/staging existe como terreno de entrenamiento, el lugar donde los programadores nuevos aprenden el proceso de envío haciendo limpiezas de estilo y cambios de API relativamente simples. Si una IA hace ese trabajo por ellos, dijo, se destruye la razón de ser del subsistema. La política incluye una sola excepción, estricta: un hallazgo de seguridad genuino producido por una IA puede enviarse, pero solo si quien lo envía probó el parche sobre el hardware real que el driver controla y puede explicar de manera convincente cómo lo hizo. De paso, Kroah-Hartman fue explícito con quienes pensaran en disimular el origen del parche: “es MUY obvio cuando alguien envía un parche generado por LLM, así que no piensen que no divulgarlo les va a permitir salirse con la suya” (It’s FOSS).

Esa política conecta con algo que tu borrador intuye pero no nombra: el verdadero cuello de botella nunca fue la IA en sí, sino el tiempo de atención humana, un recurso que no escala al mismo ritmo que la generación automática de texto plausible. Un parche defectuoso escrito por un programador novato suele tener errores obvios, fáciles de señalar y de rechazar en el primer vistazo. Un parche defectuoso escrito por un modelo de lenguaje viene con changelog prolijo, formato impecable y una justificación que suena razonable hasta que alguien se toma el trabajo de rastrear si la función que invoca existe de verdad o si la corrección rompe compatibilidad con un controlador que todavía corre en producción en algún servidor de los noventa. Auditar esa clase de error cuesta más tiempo que corregir un error evidente, y ese costo lo paga siempre el mismo grupo reducido de mantenedores.

Lo notable es que Linus Torvalds, en paralelo, viene moviéndose en la dirección contraria a la de un rechazo defensivo. Le respondió a los críticos del uso de IA en el proyecto diciendo, sin vueltas, que Linux “no es uno de esos proyectos anti-IA” y que quien no esté de acuerdo puede hacer un fork o irse (It’s FOSS). La política de Kroah-Hartman para staging no contradice esa postura: la especifica. No es una prohibición general de la IA en el kernel, sino la decisión de que hay un lugar puntual —el gimnasio de los recién llegados— donde el atajo automatizado desvirtúa el propósito del ejercicio.

Ahí está, me parece, la lectura más honesta de lo que está pasando en la gobernanza del código abierto en 2026. No es una comunidad meritocrática siendo desbordada por una ola indiscriminada de basura, como sugiere el relato más alarmista. Es una comunidad meritocrática tratando de trazar, subsistema por subsistema, la línea entre el uso de la IA que multiplica la capacidad de detección de errores —como Sashiko, encontrando la mitad de los bugs que la revisión humana venía dejando pasar— y el uso de la IA que multiplica el volumen de trabajo sin multiplicar el valor, saturando la atención de mantenedores que siguen siendo, en última instancia, personas con horas finitas en el día. El kernel no está regulando la IA por temor a la máquina. Está protegiendo, con instrumentos bastante precisos, el único recurso que ninguna automatización puede reponer: el juicio humano entrenado para reconocer cuándo un texto perfecto esconde una mentira.