El apoyo de Linus Torvalds a la programación con IA se enfrenta al problema de los mantenedores de Linux
El apoyo de Linus Torvalds a la programación con IA suena ahora inusualmente entusiasta, pese al creciente conflicto en torno a las contribuciones generadas por máquinas en el software de código abierto. En una conferencia magistral del 9 de octubre, el creador de Linux afirmó que ahora “realmente le gusta usar IA”, después de considerar anteriormente poco impresionante la programación con IA.
Ese respaldo no era permiso para enviar código sin verificar. Torvalds calificó la IA como una forma útil de hacer que programar resulte agradable, especialmente para principiantes y proyectos personales. También advirtió a los desarrolladores que fueran “muy cuidadosos” al usarla en trabajos serios.
La distinción importa porque el kernel de Linux ya ha encontrado ambas caras del desarrollo asistido por IA. Las herramientas automatizadas pueden detectar defectos reales y ayudar a los desarrolladores a trabajar fuera de los lenguajes que mejor dominan. También pueden inundar a los mantenedores con informes duplicados, parches superficiales y trabajo que los humanos deben verificar.
Por ello, Linux plantea una pregunta más difícil que si la IA escribe código aceptable. El reto consiste en decidir quién asume el coste de validar ese código. La respuesta emergente combina un uso permisivo de las herramientas con divulgación, revisión humana y responsabilidad personal.
Los comentarios de Linus Torvalds sobre programación con IA trazan un límite firme
Torvalds respalda la IA como herramienta de programación, pero ese apoyo termina donde comienza el resultado no verificado.
Torvalds habló sobre IA durante una conversación con Dirk Hohndel en Open Source Summit Europe, en Praga. La Linux Foundation programó la sesión para el 9 de octubre como parte del programa del 35.º aniversario del proyecto. La agenda de la conferencia situó su conversación junto a sesiones sobre Linux, IA abierta, confianza digital y software crítico para la seguridad.
Su postura reflejó un cambio en su experiencia personal. Torvalds dijo que antes creía que la programación con IA “simplemente no era muy buena”. Desde entonces ha llegado al punto de disfrutar de su uso y considerarla una herramienta valiosa cuando se maneja correctamente.
Ese cambio no lo convirtió en defensor de la generación de software sin supervisión. Torvalds recalcó que es ante todo el mantenedor y punto de integración del kernel, más que alguien que escribe la mayor parte de su código. Sus propios experimentos pertenecen a una categoría de riesgo distinta de aceptar cambios en una infraestructura utilizada en todo el mundo.
Describió la IA como especialmente útil para tareas fuera de su experiencia consolidada. Un ejemplo involucraba un proyecto personal de pedal de guitarra. Torvalds podía crear el firmware en C, pero la interfaz parecía anticuada. Entonces utilizó IA para producir una implementación en Java, un lenguaje que normalmente no usa.
El resultado no se presentó como ingeniería experta en Java. Le mostró cómo su implementación familiar en C se trasladaba a otro lenguaje y dio al proyecto una interfaz funcional. El experimento ilustra un caso de uso acotado en el que el desarrollador entiende el comportamiento previsto y puede inspeccionar el resultado.
Torvalds también vinculó la IA con la experiencia de aprender a programar. Cuando comenzó a escribir código en 1981, los programas simples aún podían parecer significativos porque el software comercial era menos refinado. Hoy, los nuevos desarrolladores comparan sus primeros proyectos con aplicaciones maduras creadas por grandes equipos.
La IA puede reducir esa barrera psicológica. Puede ayudar a los principiantes a convertir una idea pequeña en algo visible antes de dominar todos los componentes. Torvalds caracterizó ese proceso como una forma de encontrar alegría en la programación e incluso llamó a la IA una “droga de entrada” al campo.
La advertencia sobre el trabajo serio cambia el sentido de esas declaraciones. Una interfaz generada para un hobby que funciona mal causa inconvenientes. Un parche defectuoso para el kernel puede introducir fallos, pérdida de datos, vulnerabilidades de seguridad o problemas de mantenimiento difíciles de detectar.
Por ello, Torvalds atribuyó la responsabilidad a la persona que opera la herramienta. Un desarrollador debe entender qué debe hacer el software y confirmar que la implementación generada lo hace. La habilidad para redactar prompts por sí sola no sustituye el criterio técnico.
Este es el límite central dentro del apoyo de Linus Torvalds a la programación con IA. La IA puede reducir el esfuerzo necesario para obtener un resultado inicial. No elimina el trabajo requerido para determinar si ese resultado pertenece a una base de código crítica.
Su postura no es ni un respaldo generalizado ni un rechazo ideológico. Trata la IA como otras herramientas de desarrollo, al tiempo que reconoce que sus resultados fluidos pueden ocultar errores de manera más convincente que las herramientas tradicionales.
Esta posición práctica e intermedia coincide estrechamente con las reglas de contribución en desarrollo del kernel. El proyecto acepta ayuda de sistemas automatizados, pero no permite que un agente de IA asuma las responsabilidades legales o técnicas de un colaborador.
El kernel de Linux permite asistencia, no automatización anónima
Las reglas del kernel se centran en colaboradores responsables porque el código generado no puede certificar por sí mismo su origen, licencia ni corrección.
El kernel de Linux publica ahora una guía específica sobre asistentes de IA para colaboradores. Esta dirige el trabajo asistido por IA a través del mismo proceso de desarrollo, estándares de codificación, requisitos de licencias y expectativas de revisión que se aplican a los parches escritos por humanos.
Esa continuidad es importante. Linux lleva mucho tiempo aceptando código influido por compiladores, analizadores estáticos, generadores de código, sistemas de refactorización automatizada y scripts. Una contribución no se vuelve aceptable simplemente porque una persona haya tecleado cada carácter.
A la inversa, una contribución no se vuelve inaceptable únicamente porque una herramienta haya producido parte de ella. A los revisores les importan el comportamiento, la mantenibilidad, las licencias y si quien la envía puede defender el cambio.
Los sistemas generativos complican este modelo establecido porque pueden producir código, explicaciones, mensajes de commit y comentarios de revisión mediante una sola interfaz. Sus resultados pueden parecer completos incluso cuando su razonamiento es incorrecto o su procedencia sigue siendo incierta.
La guía del kernel aborda esa incertidumbre mediante la responsabilidad humana. Los agentes de IA no deben añadir una etiqueta Signed-off-by. Esa etiqueta corresponde a una persona que pueda hacer la certificación requerida por el Developer Certificate of Origin, comúnmente llamado DCO.
Según el proceso DCO del kernel, el firmante confirma que la contribución tiene un origen aceptable y puede distribuirse bajo la licencia del proyecto. Un modelo de lenguaje no puede hacer esa declaración legal.
La persona que envía trabajo asistido por IA debe revisar el código generado, garantizar el cumplimiento de las licencias, añadir su propia firma y aceptar plena responsabilidad. Esto significa que “el modelo lo escribió” no puede servir como defensa cuando los revisores encuentran un problema.
La guía también introduce una etiqueta Assisted-by para revelar una participación significativa de LLM. Los colaboradores pueden identificar el uso de un LLM y otras herramientas especializadas de análisis. La etiqueta brinda a los mantenedores contexto útil sin pretender que la herramienta sea un colaborador legal.
Las reglas separadas sobre contenido generado extienden el principio más allá de los archivos fuente. Pueden abarcar mensajes de commit, cartas de presentación, documentación y traducciones cuando el contenido generado entra de forma sustancial en un envío.
Estas reglas animan a los colaboradores a explicar qué herramientas utilizaron y, cuando resulte útil, qué entradas produjeron el trabajo. El propósito no es exigir una transcripción de cada sugerencia de autocompletado. Es revelar la automatización sustancial que pueda afectar a la revisión, la procedencia o la responsabilidad.
La transparencia se vuelve más importante a medida que la asistencia de IA es menos visible. Un parche generado puede reescribirse a mano. Un parche escrito por humanos puede recibir una descripción generada por IA. Un modelo podría encontrar un defecto mientras que la corrección final proviene de un mantenedor.
El enfoque del kernel reconoce estos flujos de trabajo mixtos. Evita la tarea poco realista de clasificar cada carácter como humano o generado por máquina. En cambio, pregunta si una herramienta hizo una contribución significativa y si un humano está preparado para respaldar el envío final.
Este modelo ofrece a empresas y otros proyectos de código abierto un precedente útil. Los equipos no necesitan elegir entre prohibir todas las herramientas de IA y aceptar resultados opacos de agentes. Pueden definir umbrales de divulgación, preservar la firma humana y exigir evidencia normal de pruebas.
Sin embargo, las reglas sobre atribución solo resuelven una parte del problema. Identifican la responsabilidad después de que alguien ha creado un envío. No impiden que la IA incremente el número de informes y parches que los mantenedores deben inspeccionar.
Ese problema de volumen es donde la postura permisiva de Linux enfrenta su prueba más difícil.
La IA abarata las contribuciones mientras la revisión sigue siendo costosa
El conflicto no es código humano frente a código de máquina. Es producción generada abundante frente a atención escasa de los mantenedores.
Torvalds reconoció que el análisis asistido por IA está detectando problemas valiosos en el kernel. También describió un flujo de parches aleatorios que abarcan desde fallos de seguridad importantes hasta controladores que nadie ha tocado en 20 años.
Un sistema automatizado no comprende de forma natural qué defecto merece atención humana escasa. Si se le pide buscar fugas de memoria, puede producir informes allí donde su análisis detecte un patrón sospechoso. No le importa si el componente afectado se utiliza ampliamente, está obsoleto o ya está siendo reparado.
Esa falta de priorización transfiere trabajo a los mantenedores. Alguien debe establecer si un informe es válido, determinar si duplica trabajo previo, encontrar al responsable del subsistema adecuado, inspeccionar la corrección propuesta y evaluar consecuencias más amplias.
Un informe plausible pero falso puede consumir más tiempo que uno evidentemente débil. Los mantenedores deben investigar suficiente contexto para refutarlo. La persona que generó el informe puede haber pasado solo unos minutos dando instrucciones a un modelo.
Torvalds ya había advertido que una afluencia de informes de IA estaba dificultando la gestión de la lista de seguridad del kernel. Los descubrimientos duplicados agravaron la carga porque distintos usuarios podían ejecutar herramientas similares sobre el mismo código e informar de manera independiente sobre el mismo problema.
En el evento de Praga, afirmó que la IA estaba mejorando el código base en general. Esa valoración favorable vino acompañada de una advertencia igual de directa: estaba sometiendo a los mantenedores a presión “hasta el punto de convertirse en un problema”.
La magnitud de la preocupación fue visible en la reunión de mantenedores asociada. Según Torvalds, aproximadamente tres cuartas partes de sus conversaciones se centraron en hacer que las herramientas de IA para generación y revisión de código fueran menos estresantes y más útiles.
Ese detalle sitúa el debate más allá de las preferencias personales. Los mantenedores no están simplemente discutiendo si el código generado parece auténtico. Están rediseñando flujos de trabajo en torno a un cambio de producción que ya ha llegado.
La IA reduce varias barreras a la vez. Permite a desarrolladores menos experimentados elaborar borradores de parches, ayuda a investigadores a examinar subsistemas desconocidos y convierte un problema sospechoso en un informe pulido. Estas capacidades pueden ampliar la base de colaboradores y revelar errores que, de otro modo, permanecerían sin detectar.
Sin embargo, esa misma facilidad fomenta la participación ocasional. Una persona puede enviar un informe sin entender el código circundante y luego desaparecer cuando un mantenedor pide pasos para reproducirlo, pruebas o una corrección más completa.
La fricción tradicional de contribuir antes filtraba parte de ese comportamiento. Preparar un parche, redactar una explicación coherente y responder a la revisión exigía suficiente esfuerzo como para demostrar compromiso. Las herramientas generativas pueden imitar esas señales antes de que el usuario haya desarrollado los conocimientos correspondientes.
La divulgación no puede restaurar por completo esa señal perdida. Una etiqueta Assisted-by indica al revisor que participó la automatización. No revela si quien envía la contribución entiende el subsistema ni si seguirá involucrado después de la primera respuesta.
Por lo tanto, el kernel necesita filtros operativos junto con la atribución. Los mantenedores necesitan formas de agrupar hallazgos duplicados, clasificar el impacto práctico, verificar afirmaciones automáticamente e identificar a colaboradores que presentan trabajo utilizable de manera recurrente.
También necesitan permiso para rechazar rápidamente resultados de poco valor. Tratar cada informe fluido generado por IA como una contribución completa convertiría el volumen generado en una obligación para revisores no remunerados o sobrecargados.
Esta preocupación afecta aún más a los proyectos pequeños. Linux cuenta con una amplia red de colaboradores y mantenedores empleados por grandes empresas tecnológicas. Una biblioteca gestionada por uno o dos voluntarios tiene mucha menos capacidad para absorber informes automatizados.
Ese desequilibrio explica por qué los proyectos de código abierto han adoptado distintas normas sobre LLM. Una prohibición puede ser una decisión de gestión de recursos, no una afirmación de que todo el código generado sea defectuoso. Una política permisiva puede funcionar cuando un proyecto cuenta con infraestructura de pruebas y suficientes revisores para hacer cumplir sus estándares.
Linux ocupa una posición inusual. Puede beneficiarse del análisis de IA en una enorme base de código, pero cada cambio aceptado afecta infraestructura crítica. Su escala crea tanto la razón más sólida para usar automatización como la razón más sólida para limitarla.
La verdadera disyuntiva es acceso frente a responsabilidad
La IA puede invitar a más personas a programar, mientras que una contribución responsable sigue exigiendo experiencia, perseverancia y sentido de responsabilidad.
La parte más atractiva del argumento de Torvalds se refiere al acceso. La programación resulta más fácil de explorar cuando un principiante puede describir una idea, recibir un borrador funcional y modificarlo mediante conversación.
Ese ciclo de retroalimentación puede mantener comprometido al aprendiz. En lugar de dedicar la primera sesión a resolver problemas de instalación o memorizar sintaxis, la persona puede ver un resultado e ir examinando gradualmente cómo funciona.
Para desarrolladores experimentados, las mismas herramientas pueden cubrir brechas de conocimiento más pequeñas. Un programador del kernel puede necesitar una interfaz de usuario, un arnés de pruebas o un script en un lenguaje desconocido. La IA puede proporcionar un punto de partida sin requerir semanas de especialización ajena al objetivo.
Se trata de una ganancia legítima de productividad. También es distinto de delegar a un modelo un cambio completo sensible para la seguridad. El desarrollador del primer escenario ya entiende el sistema deseado y puede delimitar el componente desconocido.
La distinción se debilita cuando los usuarios no pueden evaluar el resultado. Un principiante puede creer que un programa funciona porque supera una prueba visible. Un ingeniero experimentado puede pasar por alto un error fuera de su especialidad porque la explicación generada parece creíble.
Por eso, «humano en el circuito» puede convertirse en una garantía vacía. Que una persona apruebe un resultado no garantiza una supervisión significativa. El revisor debe contar con suficiente contexto, tiempo y autoridad para detectar fallos.
La regla del kernel sobre la aprobación humana define quién responde por el cambio, pero no puede fabricar competencia. Una persona puede firmar un parche que en realidad no entiende. Los mantenedores siguen necesitando evidencia técnica y participación receptiva.
El código generado también plantea cuestiones de procedencia aún sin resolver. Los modelos pueden reproducir patrones conocidos sin proporcionar un historial claro para una salida concreta. Los colaboradores deben garantizar que el trabajo enviado cumple los requisitos de licencia GPL-2.0-only del kernel, incluso cuando el modelo no pueda explicar todas las influencias de su entrenamiento.
La política de Linux no pretende resolver debates más amplios sobre datos de entrenamiento o derechos de autor. Establece un límite para contribuir: la persona que envía el cambio debe poder realizar la certificación legal existente.
La seguridad introduce otra incertidumbre. Los sistemas de IA pueden descubrir errores en rutas de código olvidadas, lo que beneficia al proyecto. También pueden crear una vía eficiente para producir afirmaciones superficiales de vulnerabilidades a una escala que desborde los canales de reporte privado.
Los reportes públicos generan riesgos distintos. La divulgación inmediata puede exponer a los usuarios antes de que los mantenedores puedan preparar y distribuir una corrección. El reporte privado protege la coordinación, pero se vuelve ineficaz si sus canales se llenan de hallazgos duplicados o fabricados.
Los comentarios de Torvalds sugieren que Linux no resolverá esta tensión rechazando la IA de plano. A comienzos de 2026, sostuvo que Linux no era un proyecto anti-IA y que las herramientas debían ayudar a los mantenedores en vez de causarles problemas.
Ese estándar ejerce presión sobre quienes desarrollan herramientas. El éxito no puede medirse solo por el número de defectos encontrados, parches producidos o comentarios de revisión generados. Un sistema útil debe reducir el esfuerzo humano total necesario para llegar a una decisión correcta.
Para un agente de detección de errores, eso implica reproducciones, evaluación del impacto, detección de duplicados y evidencia vinculada a rutas de código específicas. Para un generador de parches, implica cambios enfocados, pruebas y explicaciones que resistan una revisión experta.
Para los agentes de revisión, la utilidad significa identificar defectos relevantes sin sepultar a los mantenedores bajo advertencias especulativas. La precisión y la priorización importan más que un gran número de comentarios.
La misma lección se aplica dentro de las empresas que adoptan sistemas de programación con IA. Medir líneas generadas o sugerencias aceptadas puede premiar el volumen sin revelar el costo de mantenimiento. Los equipos deben seguir el tiempo de revisión, las regresiones, el retrabajo, las tasas de incidentes y la responsabilidad a largo plazo.
El entusiasmo personal de Torvalds no invalida esas preocupaciones. Las agudiza. Si un desarrollador que entiende los riesgos del kernel aún considera la IA agradable y útil, rechazarla por completo deja beneficios importantes sobre la mesa.
Si Linux aceptara todos los resultados generados sin controles adicionales, transferiría los costos ocultos de la tecnología a los mantenedores. La dirección actual del proyecto busca preservar la experimentación mientras rechaza esa transferencia.
Lo que la comunidad de Linux debe demostrar a continuación
La política de IA de Linux solo tendrá éxito si las contribuciones generadas resultan más fáciles de verificar, priorizar y mantener que la actual avalancha de envíos.
La primera señal a observar es cómo el kernel aplica sus reglas de divulgación en la revisión cotidiana. La documentación formal importa, pero una práctica coherente determinará si los colaboradores entienden cuándo usar Assisted-by y qué información esperan los revisores.
Una divulgación demasiado amplia podría producir metadatos repetitivos con poco valor. Una divulgación débil podría ocultar automatización relevante y privar a los revisores de contexto. El equilibrio útil surgirá mediante envíos reales, comentarios de los mantenedores y revisiones de las directrices.
La segunda señal es si la automatización de la revisión reduce la carga creada por la generación. Torvalds señaló que los proyectos ya utilizan IA para revisar parches asistidos por IA, creando a veces la apariencia de bots hablando con bots.
Ese ciclo no es automáticamente absurdo. El análisis estático ya revisa código generado por máquinas y escrito por humanos. Un revisor de IA puede cumplir una función similar si sus hallazgos son precisos, reproducibles y están subordinados a mantenedores responsables.
El peligro aparece cuando un sistema incierto valida a otro y los humanos tratan esa coincidencia como evidencia. Varios modelos pueden repetir la misma suposición equivocada. Las cadenas de revisión deben basarse en pruebas, resultados de compilación, comportamiento en tiempo de ejecución y análisis de código trazable, en lugar del consenso entre modelos.
Preste atención a las herramientas que adjuntan verificación concreta a cada hallazgo. Un informe que incluye un reproductor, una configuración afectada, un resultado de prueba y un parche mínimo es más valioso que un párrafo seguro de sí mismo que describe un posible defecto.
La tercera señal es la carga de trabajo de los mantenedores. Si disminuyen los informes de seguridad duplicados, los parches de poco valor reciben una clasificación más rápida y los colaboradores útiles se mantienen involucrados durante la revisión, el modelo de aceptación controlada de Linux parecerá sostenible.
Si las colas siguen creciendo y los mantenedores experimentados se agotan, los proyectos tendrán razones más sólidas para imponer límites más estrictos. El resultado relevante no es cuánto código generado por IA entra en el árbol. Es si la comunidad puede preservar la calidad de la revisión sin agotar a las personas responsables de ella.
Los proveedores de herramientas deberían tratar ese resultado como un requisito de producto. Un agente que produce diez parches mientras genera veinte horas de trabajo de revisión no ha entregado diez unidades de productividad.
Los desarrolladores también deberían distinguir la experimentación de la contribución. El vibe coding, es decir, la programación iterativa mediante instrucciones en lenguaje natural, puede funcionar bien para un prototipo desechable. Integrar código aguas arriba exige comprender su comportamiento, historial, pruebas y consecuencias de mantenimiento.
Esa transición es donde el respaldo de Linus Torvalds a la programación con IA resulta más útil como guía. Empiece con una tarea delimitada. Use IA donde ayude. Examine lo que crea. Pruebe el resultado, explíquelo con sus propias palabras y acepte la responsabilidad antes de pedir a otra persona que lo revise.
Los principiantes no deberían interpretar la cautela como una razón para evitar la IA. La metáfora de Torvalds sobre la «droga de entrada» reconoce que herramientas accesibles pueden crear la motivación necesaria para aprender. El siguiente paso consiste en convertir un éxito generado en comprensión genuina.
Los ingenieros experimentados no deberían interpretar su experiencia como inmunidad frente al error. La fluidez puede fomentar un exceso de confianza, especialmente cuando un modelo produce código plausible en un dominio desconocido. Los sistemas serios exigen verificación independiente incluso cuando el primer resultado parece pulido.
Los mantenedores, por su parte, necesitan la autoridad para definir qué tipo de asistencia ayuda realmente a su proyecto. Linux puede respaldar la IA sin exigir que cada responsable de subsistema acepte trabajo ilimitado generado por máquinas.
El modelo emergente del kernel es exigente, pero coherente. Las herramientas pueden participar. Los humanos deben divulgar asistencia sustancial, cumplir las normas de licencia, entender sus envíos y seguir siendo responsables de las consecuencias.
Ese enfoque no pondrá fin al debate del código abierto sobre el contenido generado por LLM. Distintos proyectos enfrentan riesgos y capacidad de revisión diferentes. Sin embargo, desplaza el debate de la identidad hacia las operaciones.
Los próximos meses deberían mostrar si Linux puede convertir ese principio en un flujo de trabajo manejable. Los desarrolladores pueden ayudar a responder la pregunta ahora: antes de enviar trabajo asistido por IA, verifiquen que ahorra tiempo a los mantenedores en lugar de limitarse a ahorrar tiempo a quien lo generó.
