Linus Torvalds acaba de mostrar la forma correcta de usar la IA para programar y todos lo pasaron por alto

Linus Torvalds no presentó un curso de “programación con IA”, pero acaba de dejar una de las lecciones más importantes para desarrolladores: la inteligencia artificial puede ser útil, siempre que siga siendo una herramienta y no reemplace el criterio humano. En medio del debate sobre asistentes de código en el kernel de Linux, Torvalds defendió una postura pragmática: Linux no es un proyecto “anti-IA”, pero las contribuciones deben seguir el proceso técnico normal, con revisión, responsabilidad y calidad.

Lo que muchos pasaron por alto es que Torvalds no está defendiendo el “vibe coding” irresponsable ni la entrega ciega de código generado por modelos. Su mensaje real es más profundo: usar IA para programar puede ser correcto si el programador entiende el resultado, revisa el código, lo prueba, asume la responsabilidad y no descarga el costo sobre los mantenedores. La documentación del kernel ya lo formaliza: los asistentes de IA pueden ayudar, pero los agentes no pueden firmar el Developer Certificate of Origin; solo una persona puede certificar legalmente una contribución.

1. Qué dijo realmente Linus Torvalds sobre la IA

Torvalds fue claro: la IA es una herramienta, como otras herramientas usadas por los programadores, y ya resulta útil. También fue tajante contra una posición de rechazo absoluto: el kernel de Linux no adoptará una postura anti-IA solo porque algunos desarrolladores rechacen los modelos generativos.

Pero esa defensa no significa carta blanca. En el mismo debate se reconoció que las herramientas de IA también pueden generar carga adicional para mantenedores, falsos positivos, reportes duplicados y código de baja calidad. Por eso el punto de Torvalds no es “usar IA sin límites”, sino hacer que esas herramientas ayuden en lugar de estorbar.

2. La frase que resume todo: la IA es herramienta, no autor final

Torvalds ya había explicado que le molesta escuchar frases como “99% del código fue escrito por IA”, porque el programador no debería desaparecer del proceso. Comparó la IA con herramientas anteriores como ensambladores y compiladores: todas aumentan productividad, pero ninguna elimina la necesidad de entender lo que se está construyendo.

Esta es la clave que muchos ignoraron. Para Torvalds, la IA puede cambiar la productividad, pero no cambia los fundamentos de la programación: entender el problema, diseñar una solución, revisar el resultado, probarlo, mantenerlo y responder por sus consecuencias.

Usa IA para acelerar.
No la uses para abdicar.

Puedes pedir:

* borradores de código
* explicación de errores
* pruebas unitarias
* revisión de parches
* búsqueda de fallos

Pero debes conservar:

* criterio técnico
* revisión humana
* pruebas
* responsabilidad
* capacidad de mantenimiento

3. El ejemplo que todos pasaron por alto: su proyecto personal AudioNoise

El caso más revelador no ocurrió dentro del kernel, sino en un proyecto personal de Torvalds. En su repositorio AudioNoise, relacionado con efectos digitales de audio, explicó que una herramienta visualizadora en Python fue escrita básicamente mediante “vibe coding” con Google Antigravity. Pero el contexto importa: lo presentó como un proyecto de aprendizaje, un experimento personal y no como código crítico del kernel.

Ese detalle muestra una práctica madura: usar IA donde el riesgo es bajo, donde el objetivo es aprender o prototipar, y donde el resultado puede revisarse sin comprometer infraestructura crítica. Torvalds no está diciendo “programa todo así”; está mostrando que hay contextos donde la IA puede ser útil sin convertirla en autoridad final.

4. La regla del kernel: el humano firma, el humano responde

La documentación oficial del kernel sobre asistentes de código con IA es contundente: los agentes de IA no deben añadir firmas Signed-off-by. Solo humanos pueden certificar el Developer Certificate of Origin. El remitente humano debe revisar el código generado por IA, verificar licencias, añadir su firma y asumir responsabilidad total por la contribución.

Además, las guías sobre contenido generado por herramientas indican que, si una parte significativa de una contribución fue creada por una herramienta, se debe ser transparente sobre su origen, describir qué herramienta se usó, qué partes fueron afectadas, cómo se probó el cambio y qué papel tuvo la asistencia.

5. Sashiko: la IA como revisor, no como sustituto del mantenedor

El debate que encendió la postura de Torvalds estuvo relacionado con Sashiko, un sistema de revisión de código para el kernel que analiza parches y busca errores. Según reportes técnicos, sus creadores afirman que puede encontrar una parte significativa de fallos que luego serían corregidos por humanos, aunque también puede producir falsos positivos y aumentar la carga de revisión.

Ahí aparece otra enseñanza: la IA puede ser valiosa como segunda mirada. Puede detectar patrones, revisar parches, encontrar errores repetitivos o sugerir zonas sospechosas. Pero la decisión final sigue siendo de los mantenedores, porque el mantenimiento de software no es solo detectar una línea problemática: también implica contexto, compatibilidad, estilo, regresiones, impacto en usuarios y evolución futura del proyecto.

6. La forma correcta de usar IA para programar

La lección práctica se puede resumir así: usa IA para acelerar partes del trabajo, pero conserva el control intelectual del proceso. Un buen desarrollador no pregunta “¿la IA escribió esto?”, sino “¿entiendo esto?, ¿lo puedo mantener?, ¿lo probé?, ¿sé explicar por qué funciona?, ¿sé qué riesgos introduce?”.

La documentación de envío de parches del kernel insiste en principios que aplican perfectamente al código asistido por IA: describir el problema, explicar el impacto, separar cambios lógicos, justificar optimizaciones, revisar estilo y responder a comentarios de revisión.

7. La forma incorrecta: entregar código que no entiendes

Torvalds ha insistido en que el desarrollador debe entender el resultado final. En una intervención reportada por TechRadar, explicó que incluso cuando usa IA en proyectos personales, revisa el código y busca comprender cómo funciona, porque solo así se puede mantener algo a largo plazo.

Este punto destruye la idea más peligrosa del “vibe coding”: creer que basta con que el programa “parezca funcionar”. En software real, especialmente en sistemas operativos, servidores, seguridad, salud, finanzas o infraestructura, un código que funciona en una demo puede fallar en producción, filtrar datos, romper compatibilidad o crear una vulnerabilidad.

8. Checklist Torvalds para programar con IA sin perder calidad

Si llevamos la postura de Torvalds a un checklist práctico, la regla es simple: la IA puede entrar al flujo de desarrollo, pero debe someterse al mismo estándar que cualquier otra herramienta. El código debe compilar, pasar pruebas, respetar estilo, ser revisable y tener un humano responsable.

1. ¿Entiendo qué problema resuelve?
2. ¿Entiendo cada cambio importante?
3. ¿El código compila sin advertencias relevantes?
4. ¿Pasa pruebas unitarias y de integración?
5. ¿No introduce dependencias innecesarias?
6. ¿Respeta licencias y estilo del proyecto?
7. ¿No expone secretos, tokens o datos sensibles?
8. ¿No cambia comportamiento fuera del alcance?
9. ¿El diff es pequeño y revisable?
10. ¿Puedo defender este cambio ante un revisor?

9. Flujo recomendado para desarrolladores

Un flujo saludable con IA no empieza pidiendo “hazme todo el sistema”. Empieza dividiendo el problema, generando una propuesta pequeña, revisando el diff, ejecutando pruebas y corrigiendo manualmente. Esta lógica coincide con una práctica histórica del kernel: cambios separados, justificados y verificables.

# 1. Crear una rama de trabajo
git checkout -b mejora-pequena-con-ia

# 2. Revisar cambios generados o sugeridos

git diff

# 3. Ver archivos modificados

git status

# 4. Ejecutar pruebas del proyecto

make test
pytest
npm test

# 5. Revisar dependencias y cambios inesperados

git diff --stat

# 6. Confirmar solo lo que entiendes

git add archivo_revisado
git commit -s -m "mejora: describir cambio concreto"

La firma del commit no es un trámite decorativo. En proyectos como Linux, el Signed-off-by representa responsabilidad del desarrollador sobre el origen y la legitimidad de la contribución. Por eso la documentación del kernel aclara que esa firma debe hacerla una persona, no un agente.

10. Qué deben aprender las empresas

Las empresas suelen cometer dos errores opuestos: bloquear toda IA por miedo o permitir que cualquier empleado conecte modelos a repositorios, datos internos y servidores. La postura de Torvalds permite un punto medio más profesional: IA sí, pero con políticas, revisión, trazabilidad, pruebas, control de permisos y responsabilidad humana.

11. La diferencia entre programador aumentado y programador reemplazado

La idea más valiosa de Torvalds es que la IA no convierte automáticamente a alguien sin criterio técnico en buen programador. Al contrario: cuanto más potente sea la herramienta, más importante será saber revisar su salida. La IA puede escribir código plausible; el desarrollador debe saber si ese código es correcto, seguro, mantenible y adecuado al proyecto.

12. Por qué esta postura importa para el software libre

El software libre depende de confianza entre contribuyentes, revisores y usuarios. Si los proyectos se llenan de parches generados automáticamente, reportes duplicados y contribuciones que nadie entiende, la IA puede destruir más productividad de la que aporta. Las guías del kernel reconocen precisamente que el tiempo de revisión es escaso y que la transparencia sobre el uso de herramientas ayuda a mantener saludable el proceso.

Por eso la solución no es negar la IA, sino domesticarla. Un proyecto puede aceptar ayuda de modelos, pero debe conservar reglas claras: atribución cuando corresponda, pruebas, revisión humana, estilo del proyecto, licencias compatibles y derecho de los mantenedores a pedir explicaciones o rechazar contribuciones generadas de forma irresponsable.

13. Errores comunes al interpretar a Torvalds

14. Preguntas clave

Recomendamos

En resumen

Linus Torvalds acaba de mostrar una postura mucho más inteligente que el debate simplista entre “IA sí” o “IA no”. Para él, la IA es una herramienta útil, pero no una excusa para abandonar los fundamentos de la programación: entender, revisar, probar, mantener y asumir responsabilidad.

La documentación del kernel ya convirtió esa idea en práctica: los agentes no firman, el humano responde, la transparencia importa y los mantenedores pueden exigir más revisión cuando el contenido fue generado por herramientas. Esa es la forma correcta de usar IA para programar: no como sustituto del desarrollador, sino como herramienta bajo control técnico humano.