La inteligencia artificial ya está dentro del desarrollo de software, pero eso no significa que todo aporte generado con IA sea útil. Linus Torvalds, creador de Linux, volvió a marcar una línea clara: las herramientas pueden ayudar, pero no deben reemplazar el criterio técnico ni llenar de ruido los procesos de revisión.
Según Hipertextual, Torvalds criticó el aumento de parches triviales y reportes repetidos asociados al uso de herramientas de IA en el desarrollo del kernel de Linux. El problema no es que alguien use IA para encontrar errores. El problema es enviar hallazgos sin contexto, sin análisis y sin una corrección real que justifique interrumpir el ciclo de estabilización.
En un proyecto como Linux, esa diferencia es central. El kernel no es una aplicación menor ni un repositorio experimental. Es una pieza crítica usada por servidores, dispositivos, infraestructura cloud, sistemas embebidos y millones de equipos. Cualquier cambio debe pasar por revisión estricta porque una corrección superficial puede introducir problemas mayores.
El problema no es la IA, es el uso irresponsable
Torvalds no está diciendo que la IA sea inútil. Su punto es más preciso: usar una herramienta para detectar un posible problema no convierte automáticamente ese hallazgo en una contribución valiosa.
En desarrollo de software, encontrar una advertencia es apenas el inicio. Hay que entender si el problema es real, si ya fue corregido, si aplica a la rama correcta, si introduce una regresión, si merece entrar en ese momento del ciclo y si el parche propuesto no rompe otra parte del sistema.
Cuando ese trabajo no se hace, los mantenedores reciben reportes que parecen productivos, pero que en realidad consumen tiempo. El resultado es una carga invisible: revisar duplicados, explicar por qué algo no procede, redirigir informes, cerrar tickets y defender el foco del ciclo de release.
Por qué el ciclo del kernel importa
Hipertextual señala que la crítica aparece en el contexto de Linux 7.1 RC5. En una versión candidata avanzada, el objetivo principal ya no es meter cambios de limpieza ni ajustes cosméticos. El objetivo es estabilizar.
Eso significa que los cambios aceptables deberían estar relacionados con regresiones reales o problemas suficientemente graves. Si en esa etapa entran parches menores, el equipo pierde foco y aumenta el riesgo de alterar código que ya estaba siendo probado.
Para cualquier equipo de software, la lección es directa: no todas las mejoras pertenecen a cualquier momento. Hay fases para experimentar, fases para refactorizar y fases para reducir riesgo. La IA puede acelerar propuestas, pero no debe saltarse la disciplina del proceso.
El costo de los reportes duplicados
Otro punto relevante es la repetición. Si muchas personas usan herramientas parecidas sobre el mismo código, es esperable que encuentren los mismos supuestos problemas. Si cada una reporta sin verificar antecedentes, el sistema de mantenimiento se satura.
Esto no es exclusivo de Linux. Puede ocurrir en cualquier empresa que adopte asistentes de código sin reglas. Un equipo puede terminar con decenas de sugerencias similares, vulnerabilidades mal clasificadas, falsos positivos o cambios de estilo presentados como si fueran correcciones críticas.
La IA aumenta el volumen. Pero si no mejora la calidad de la señal, el equipo trabaja más para avanzar lo mismo.
Qué debería hacer un desarrollador
El criterio que se desprende de la crítica de Torvalds es exigente, pero razonable:
- leer la documentación antes de reportar;
- validar si el problema ya existe en issues o listas previas;
- reproducir el fallo;
- explicar el impacto;
- proponer un parche real cuando corresponda;
- ubicar el cambio en la fase adecuada del ciclo;
- aceptar que no toda advertencia merece una integración inmediata.
La IA puede ayudar en varios de esos pasos: resumir documentación, explorar código, sugerir pruebas, comparar cambios o revisar posibles impactos. Pero el responsable sigue siendo la persona que firma la contribución.
Qué significa para empresas que programan con IA
Muchas empresas están adoptando asistentes de programación para acelerar desarrollo. Eso puede funcionar, pero solo si se ajusta el proceso. No basta con activar una herramienta y esperar más productividad.
Conviene definir reglas: qué tipo de código puede generarse con IA, qué pruebas son obligatorias, cómo se documenta el uso, qué revisiones humanas son necesarias y qué cambios no pueden aprobarse sin análisis manual.
El error habitual es medir productividad por cantidad de líneas, pull requests o tickets cerrados. Con IA, esas métricas pueden empeorar la calidad. Un equipo puede producir más cambios y, aun así, crear más deuda técnica.
Lectura estratégica
La crítica de Torvalds no es una reacción nostálgica contra la IA. Es una defensa del mantenimiento serio. En proyectos críticos, el valor no está en producir más parches, sino en producir mejores cambios.
La IA será útil para desarrollo cuando aumente la comprensión, no cuando sustituya la responsabilidad. Si un aporte generado con IA no viene acompañado de criterio técnico, pruebas y contexto, no es automatización: es transferencia de trabajo hacia quienes revisan.
Para equipos de producto, esta es la advertencia: la IA no elimina la ingeniería. La vuelve más dependiente de procesos sólidos.
Fuente original: Hipertextual.
