Cada cierto tiempo la industria tecnológica anuncia el final de una etapa. Primero fue el low-code, después el no-code y ahora la inteligencia artificial generativa. La promesa cambia, el mensaje apenas: escribir código importará cada vez menos porque una herramienta lo hará por nosotros. La realidad suele ser más terca de lo que parece.
La IA puede generar código, explicar funciones, sugerir tests, traducir entre lenguajes y quitar trabajo repetitivo. Python seguirá siendo una herramienta enorme para automatización, ciencia de datos, backend e IA. Pero ni Python ni los asistentes de código eliminan las necesidades físicas, regulatorias, históricas y operativas que sostienen el software real. Producir líneas de código no es lo mismo que construir sistemas que tengan que funcionar bajo presión, con rendimiento, seguridad, compatibilidad y consecuencias reales.
El código cambia, los sistemas no perdonan
La parte más visible del desarrollo es el código, pero lo que de verdad sostiene un sistema está debajo: arquitectura, memoria, concurrencia, latencia, despliegue, observabilidad, seguridad, deuda técnica, datos y operación. Las demos de IA brillan porque enseñan resultados rápidos en entornos controlados. Los sistemas reales viven en servidores viejos, dependencias heredadas, requisitos legales, hardware específico, picos de tráfico, ventanas de mantenimiento y errores que solo aparecen cuando el usuario menos oportuno pulsa el botón menos esperado.
Por eso algunos lenguajes sobreviven a cada ciclo de entusiasmo: no porque sean perfectos ni porque sus comunidades vivan fuera del tiempo, sino porque están pegados a problemas que no desaparecen. Un banco no reescribe veinte años de lógica de negocio porque un asistente genere código bonito. Un driver no se mueve a Python porque sea más legible. Un sistema de baja latencia no acepta pausas imprevisibles solo porque el lenguaje de moda sea más cómodo.
Lenguaje | Por qué resiste |
C | Hardware, sistemas operativos, firmware y control de memoria |
C++ | Rendimiento extremo, motores, navegadores, trading y bases de datos |
Rust | Seguridad de memoria, concurrencia e infraestructura moderna |
Java | Sistemas empresariales, compatibilidad y estabilidad a largo plazo |
Go | Infraestructura cloud, herramientas DevOps y simplicidad de equipo |
SQL | Datos, consultas, rendimiento y reporting |
Bash | Automatización, servidores, despliegues y operación diaria |
Assembly | Seguridad, compiladores, ingeniería inversa y el nivel más bajo del hardware |
La IA no hace irrelevantes estos lenguajes; los hace más accesibles para determinadas tareas. Pero también aumenta la necesidad de profesionales que sepan distinguir cuándo el código generado es correcto y cuándo solo lo parece.
C y C++: donde el hardware todavía manda
C no es un lenguaje de museo. El hardware sigue existiendo y lo necesita: sistemas operativos, firmware, drivers y sistemas embebidos necesitan un control directo que otros lenguajes ocultan por diseño. Cuando importa la disposición de memoria, la latencia en microsegundos o el comportamiento de una interrupción, C sigue siendo una herramienta difícil de sustituir.
Python, de hecho, depende de C en buena parte de su rendimiento real. Muchas librerías críticas en ciencia de datos, computación numérica e IA están escritas en C o usan extensiones nativas. La comodidad de Python se apoya a menudo en capas bastante menos cómodas.
C++ ocupa otro territorio. Llamarlo «C con clases» es simplificar demasiado, y meterlo en el mismo saco que C tampoco ayuda. Es un lenguaje complejo, multiparadigma y lleno de compromisos, pero esa complejidad permite construir motores gráficos, navegadores, bases de datos, sistemas financieros de baja latencia y software donde cada milisegundo puede tener valor económico. Las novedades de C++26 en reflexión, seguridad de memoria y concurrencia muestran que el lenguaje sigue evolucionando activamente.
Lenguaje | Uso típico | Lo que la IA no decide sola |
C | Kernel, firmware, drivers, embebidos | Undefined behavior, memoria, interrupciones, arquitectura |
C++ | Motores, navegadores, trading, BBDD | Cachés, concurrencia, ABI, latencia, lifetime |
Assembly | Ingeniería inversa, seguridad, compiladores | Qué ocurre realmente en CPU, registros y memoria |
La IA puede escribir C o C++ y también puede introducir un bug sutil que solo aparece bajo carga, en una arquitectura concreta o después de varias horas de ejecución. En estos lenguajes, generar una solución plausible es la parte fácil; asumir las consecuencias de que sea incorrecta, la difícil.
Rust: seguridad sin magia
Rust ha ganado tanta atención en el mundo de sistemas porque ataca un problema real: los errores de memoria. Su modelo de propiedad y préstamo obliga a pensar en quién posee los datos, cuánto viven y cómo se comparten. Esa disciplina puede resultar incómoda al principio, pero evita clases enteras de fallos que en C o C++ dependen de revisión, pruebas y experiencia.
No aspira a reemplazar todo lo anterior de golpe. Encaja bien en herramientas de infraestructura, servicios concurrentes, componentes de seguridad, blockchain y sistemas embebidos modernos, sobre todo en partes nuevas de proyectos donde la seguridad de memoria compensa el coste de aprendizaje. Rust ya ha llegado al kernel de Linux, lo que da una idea de hasta dónde ha madurado.
La IA puede ayudar a escribir Rust, pero Rust también expone los límites de los asistentes de código. No basta con que la sintaxis parezca correcta: hay que entender ownership, lifetimes, concurrencia, unsafe, FFI y diseño de APIs. Un asistente puede pelearse con el borrow checker; un buen desarrollador aprende a trabajar con él.
Conviene rebajar el entusiasmo en algún punto. Rust no es automáticamente más rápido que C, ni convierte todo código en seguro por arte de magia. En caminos muy críticos de rendimiento puede requerir decisiones cuidadosas, eliminar abstracciones innecesarias o trabajar sin biblioteca estándar. Su ventaja está en reducir riesgos sin renunciar a un rendimiento competitivo.
Java y Go: el peso de las empresas y la nube
Java es uno de esos lenguajes que sobreviven porque resuelven problemas poco glamurosos. Bancos, aseguradoras, administraciones públicas, aerolíneas y grandes empresas tienen millones de líneas escritas en Java, equipos formados, frameworks probados, herramientas maduras y años de inversión acumulada. La JVM ofrece estabilidad, rendimiento predecible, compatibilidad hacia atrás y una base enorme de talento disponible. Java en 2026 sigue activo con un ciclo de releases previsible y mejoras importantes como los virtual threads de Java 21.
La IA no va a convencer a una organización regulada de reescribir veinte años de lógica de negocio solo porque exista una alternativa más moderna. En muchos casos, el coste, el riesgo y la falta de retorno hacen que esa conversación termine antes de llegar a la reunión de presupuesto.
Go, por su parte, ha ganado terreno por una razón casi opuesta: su sencillez. Cloud, DevOps, herramientas de infraestructura y sistemas distribuidos necesitan código que muchos equipos puedan leer, mantener y desplegar sin exhibiciones de virtuosismo. Go reduce opciones, ofrece herramientas excelentes y hace que la concurrencia sea manejable para la mayoría de casos prácticos. Go 1.26 consolida esa apuesta sin añadir complejidad innecesaria.
Lenguaje | Por qué sigue creciendo o resistiendo |
Java | Estabilidad, compatibilidad, ecosistema empresarial y talento disponible |
Go | Simplicidad, despliegue fácil, concurrencia y legibilidad |
Rust | Seguridad, control, concurrencia y confianza en componentes críticos |
La IA puede generar Go sin dificultad, pero el valor real de Go está en que un equipo pueda mantener ese código dentro de seis meses sin odiar a quien lo escribió.
SQL y Bash: los lenguajes que nadie consigue enterrar
SQL lleva décadas siendo declarado obsoleto por capas de abstracción. ORMs, dashboards, herramientas visuales y ahora asistentes de IA intentan ocultarlo. Pero cuando los números no cuadran, alguien acaba abriendo la consulta.
Los datos siempre viven en alguna parte, y entender joins, índices, planes de ejecución, bloqueos, migraciones, agregaciones y consistencia sigue siendo una habilidad esencial. Las funciones de ventana o las novedades de PostgreSQL 17 no se aprovechan de verdad sin conocer SQL a fondo. Una consulta generada por IA puede ser útil como punto de partida, pero en reporting financiero, analítica de negocio o migraciones críticas, «parece correcto» no basta.
Bash es menos elegante, más áspero y más peligroso si se usa mal, pero está en todas partes. Pipelines de CI/CD, despliegues, administración de servidores, automatización rápida, tareas de emergencia y depuración en producción siguen dependiendo de la shell. Cuando una abstracción falla, muchas veces queda una terminal y poco tiempo.
Lenguaje | Dónde aparece cuando importa |
SQL | Datos, reporting, auditoría, analítica y rendimiento |
Bash | Automatización, despliegue, servidores y operación urgente |
Python | Orquestación, scripts, datos, pruebas y prototipos |
IA generativa | Borradores, explicación, tests, refactorizaciones y ayuda contextual |
La IA puede escribir consultas y scripts, pero no conoce el entorno real: no sabe los permisos, las convenciones internas, la historia de producción ni lo que ocurre si borra el directorio equivocado.
Assembly: no se usa todos los días, pero alguien debe entenderlo
Pocos desarrolladores escriben Assembly a diario, pero eso no lo hace irrelevante. En seguridad ofensiva y defensiva, ingeniería inversa, compiladores, análisis de malware, optimización extrema o investigación de vulnerabilidades, alguien debe entender qué está pasando en el nivel más bajo.
Assembly es la capa donde ya no se puede culpar al framework: solo hay registros, memoria, instrucciones, llamadas, pila y el comportamiento real de la CPU. Un asistente puede traducir fragmentos o explicar instrucciones, pero entender por qué un programa se comporta de una manera concreta sigue siendo una habilidad de alto valor.
Su importancia está en que los equipos serios necesitan al menos alguien capaz de bajar hasta esa capa cuando el problema lo exige. No hace falta que todo el mundo lo domine.
Lo que la IA sí va a reemplazar
La IA cambiará la programación, pero no como a veces se cuenta. Reemplazará parte del boilerplate, acelerará primeros borradores, reducirá búsquedas repetitivas, ayudará a escribir tests y permitirá prototipar más rápido. También hará más productivos a quienes ya entienden el problema.
Lo que no reemplaza es el juicio. No decide qué trade-off acepta una empresa, no asume responsabilidad si un sistema financiero calcula mal y no entiende una regulación sectorial por sí sola. Tampoco sabe si una degradación de latencia es aceptable para un cliente, ni se queda de guardia cuando una actualización rompe producción.
La habilidad importante será entender dominios, no memorizar sintaxis. Saber cuándo elegir C, cuándo usar Rust, cuándo mantener Java, cuándo escribir una consulta SQL directa, cuándo basta con un script de Bash y cuándo la IA solo debe ser un asistente.
Aprender lenguajes sigue importando, pero de otra manera
El error sería estudiar lenguajes como si fueran cromos. La pregunta útil es «qué problemas quiero ser capaz de resolver», no «qué lenguaje me asegura empleo». Quien trabaje cerca del hardware necesitará conocer C o Rust. El que entre en grandes empresas probablemente se encontrará con Java; el que trabaje en cloud e infraestructura verá Go y Bash. Los datos pasan por SQL tarde o temprano, y quien quiera analizar seguridad a fondo acabará mirando Assembly.
La IA puede ayudar en todos ellos, pero usarla sin comprender el terreno crea una habilidad frágil. Si solo sabes programar cuando el asistente está disponible, no estás construyendo criterio: estás delegando sin capacidad de revisión.
El futuro pertenece a quien entienda mejor los sistemas, no a quien memorice más sintaxis. La sintaxis se consulta; la responsabilidad no.
Preguntas frecuentes
¿La IA reemplazará a los programadores?
No de forma general. Reemplazará tareas repetitivas y acelerará el trabajo, pero los sistemas reales siguen necesitando diseño, criterio, responsabilidad y comprensión del entorno.
¿Python puede sustituir a C o C++?
No en áreas donde importan control de memoria, latencia, hardware o rendimiento extremo. Python es excelente para muchas tareas, pero suele apoyarse en componentes nativos para el rendimiento crítico.
¿Qué lenguaje conviene aprender primero?
Depende del objetivo. Python es muy útil para empezar, pero aprender un lenguaje de bajo nivel como C o Rust ayuda a entender cómo funcionan memoria, rendimiento y sistemas.
¿SQL seguirá siendo necesario con IA?
Sí. La IA puede generar consultas, pero entender datos, índices, joins y planes de ejecución sigue siendo esencial cuando los resultados deben ser correctos y auditables.
Imagen: Pexels / Markus Spiske