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, pero el mensaje se parece mucho: escribir código será cada vez menos importante porque una herramienta lo hará por nosotros. La realidad suele ser bastante más resistente.
La inteligencia artificial puede generar código, explicar funciones, sugerir tests, traducir entre lenguajes y acelerar tareas repetitivas. Python seguirá siendo una herramienta enorme para automatización, ciencia de datos, backend, inteligencia artificial y prototipado. Pero ni Python ni los asistentes de código eliminan las necesidades físicas, regulatorias, históricas y operativas que sostienen el software real. Una cosa es producir líneas de código. Otra distinta es construir sistemas que deban funcionar bajo presión, con rendimiento, seguridad, compatibilidad y consecuencias.
El código cambia, los sistemas no perdonan
La parte más visible del desarrollo es el código. La parte más importante suele estar debajo: arquitectura, memoria, concurrencia, latencia, despliegue, observabilidad, seguridad, deuda técnica, datos y operación. Las demos de inteligencia artificial 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 aparecen solo 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, reversa y verdad última del hardware |
La inteligencia artificial no hace irrelevantes estos lenguajes. Los hace más accesibles para determinadas tareas, pero también aumenta la necesidad de profesionales que entiendan cuándo el código generado es correcto y cuándo solo parece correcto.
C y C++: donde el hardware todavía manda
C no está vivo por nostalgia. Está vivo porque el hardware sigue existiendo. Sistemas operativos, firmware, drivers, sistemas embebidos y software en tiempo real 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 o inteligencia artificial están escritas en C, C++ o usan extensiones nativas. La comodidad de Python se apoya a menudo en capas inferiores mucho menos cómodas.
C++ ocupa otro territorio. No es simplemente “C con clases”, ni conviene meterlo en el mismo saco como si C/C++ fuera un único lenguaje. C++ es una herramienta compleja, multiparadigma y llena 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.
| Lenguaje | Uso típico | Lo que la inteligencia artificial no decide sola |
|---|---|---|
| C | Kernel, firmware, drivers, embedded | Undefined behavior, memoria, interrupciones, arquitectura |
| C++ | Motores, navegadores, trading, BBDD | Cachés, concurrencia, ABI, latencia, lifetime |
| Assembly | Reversa, seguridad, compiladores | Qué ocurre realmente en CPU, registros y memoria |
La inteligencia artificial puede escribir C o C++. 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, el problema no es generar una solución plausible. El problema es asumir las consecuencias.
Rust: seguridad sin magia
Rust se ha convertido en uno de los lenguajes más discutidos del 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.
Su papel no es reemplazar todo lo anterior de golpe. Rust es especialmente atractivo en herramientas de infraestructura, servicios concurrentes, componentes de seguridad, blockchain, sistemas embebidos modernos y partes nuevas de proyectos grandes donde la seguridad de memoria compensa el coste de aprendizaje.
La inteligencia artificial puede ayudar a escribir Rust, pero Rust también expone las limitaciones de los asistentes de código. No basta con que la sintaxis parezca correcta. Hay que comprender 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.
También conviene rebajar el entusiasmo. 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 incluso trabajar sin biblioteca estándar. Su ventaja principal está en reducir riesgos sin renunciar a 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 glamourosos. Bancos, aseguradoras, administraciones públicas, aerolíneas y grandes empresas tienen millones de líneas en Java, equipos formados, frameworks probados, herramientas maduras y años de inversión. La JVM ofrece estabilidad, rendimiento predecible, compatibilidad hacia atrás y una base enorme de talento.
La inteligencia artificial 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 facilita la concurrencia para muchos casos prácticos.
| 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 inteligencia artificial puede generar Go con facilidad, pero el valor de Go no está solo en escribirlo rápido. Está en que un equipo humano pueda mantenerlo 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 inteligencia artificial intentan ocultarlo. Pero cuando los números no cuadran, alguien acaba abriendo la consulta.
Los datos viven en alguna parte. Y entender joins, índices, planes de ejecución, bloqueos, migraciones, agregaciones y consistencia sigue siendo una habilidad esencial. 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. También 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 inteligencia artificial puede escribir consultas y scripts. El problema es que no conoce de forma completa el entorno real, los permisos, las convenciones internas, la historia de producción o las consecuencias de borrar el directorio equivocado.
Assembly: no se usa todos los días, pero alguien debe entenderlo
Pocos desarrolladores escriben Assembly a diario. 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. Están los registros, la memoria, las instrucciones, las llamadas, la 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 humana de alto valor.
Su importancia no está en que todo el mundo deba dominarlo. Está en que los equipos serios necesitan personas capaces de bajar hasta esa capa cuando el problema lo exige.
Lo que la inteligencia artificial sí va a reemplazar
La inteligencia artificial 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. No entiende por sí sola una regulación sectorial. No sabe si una degradación de latencia es aceptable para un cliente. No se queda de guardia cuando una actualización rompe producción.
La habilidad importante no será memorizar sintaxis. Será entender dominios. Saber cuándo elegir C, cuándo usar Rust, cuándo mantener Java, cuándo escribir una consulta SQL directa, cuándo un script Bash es suficiente y cuándo la inteligencia artificial 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 no es “qué lenguaje me garantiza empleo”, sino “qué problemas quiero ser capaz de resolver”. Quien trabaje cerca del hardware deberá conocer C o Rust. Quien entre en grandes empresas probablemente encontrará Java. Quien viva en cloud e infraestructura verá Go y Bash. Quien toque datos tendrá que entender SQL. Quien quiera analizar seguridad a fondo acabará mirando Assembly.
La inteligencia artificial puede ayudar en todos ellos. Pero usarla sin comprender el terreno crea una habilidad frágil. Si una persona solo sabe programar cuando el asistente está disponible, no está construyendo criterio. Está delegando sin capacidad de revisión.
El futuro no pertenece a quien memorice más sintaxis, sino a quien entienda mejor los sistemas. La sintaxis se consulta. La responsabilidad no.
Preguntas frecuentes
¿La inteligencia artificial 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 inteligencia artificial?
Sí. La inteligencia artificial puede generar consultas, pero entender datos, índices, joins y planes de ejecución sigue siendo esencial cuando los resultados deben ser correctos y auditables.
