Resumen. Hace dos años las voces más ruidosas del sector te aseguraban que a estas alturas los ingenieros de software serían una curiosidad histórica. Prompt a la entrada, producto a la salida. Estamos en agosto de 2026 y el empleo en desarrollo no se hundió. Pero la misma ola que no logró eliminar a los desarrolladores sí eliminó otra cosa, y de esa mitad de la historia casi nadie habla como corresponde: borró el trabajo rutinario que convertía a los principiantes en séniors. El empleo de desarrolladores de 22 a 25 años ha caído alrededor de un 20 % desde finales de 2022, mientras que el de los ingenieros mayores en esas mismas ocupaciones se mantuvo estable o creció. La computación cuántica repite ahora ese ciclo una vuelta por detrás, con un hito genuinamente histórico del que nadie habla fuera del campo y uno falso que está en todas partes.
Dos cosas que son ciertas a la vez
Si te has graduado en informática este año, compites con cientos de candidatos por una oferta que dice júnior y luego pide discretamente tres años de experiencia.
Y a la profesión en conjunto le va bien.
Ambas cosas son ciertas al mismo tiempo. La mayoría de los análisis eligen una y fingen que la otra no existe, y por eso el debate ha sido tan inútil. La pregunta interesante no es si la IA se llevó los empleos —claramente no lo hizo—, sino por qué el daño cayó con tanta precisión sobre quienes intentan entrar.
Por qué la IA no se ha llevado los empleos de desarrollo
Empecemos por lo que sí es cierto, porque las expectativas sobre la IA no son humo. La asistencia de un modelo ya no es un flujo de trabajo marginal, es el flujo por defecto, y buena parte del código nuevo se escribe con un modelo de por medio. Entonces, ¿por qué no desaparecieron los empleos?
Escribir código nunca fue el cuello de botella
Piensa en lo que realmente haces en una semana de trabajo. ¿Cuánto de eso es teclear código nuevo? Un veinte por ciento, quizá, en una buena semana. El resto es averiguar qué hay que construir, entender un sistema que otra persona escribió hace cinco años, discutir compromisos y ser quien responde cuando algo se rompe a las 3 de la madrugada.
BCG lo formuló bien en su análisis de 2026: la IA puede acelerar enormemente la generación de código y de pruebas, pero no puede hacerse cargo de un resultado de principio a fin. Y el trabajo no se puede partir limpiamente en «el modelo pone el código» y «el ingeniero pone el criterio», porque en software real esas dos cosas son la misma actividad. El criterio se expresa como código.
El impuesto de verificación
Esta es la parte contraintuitiva, y es el hallazgo que señalaríamos primero.
METR —Model Evaluation and Threat Research, una organización sin ánimo de lucro que estudia lo que estos modelos pueden hacer de verdad— realizó un ensayo controlado en el que desarrolladores de código abierto con experiencia trabajaron en sus propias bases de código, la mitad de las tareas con herramientas de IA y la otra mitad sin ellas. Con IA fueron un 19 % más lentos.
Lo que debería preocuparte no es la cifra. Es que creían haber ido más rápido. Estimaron una aceleración que no existía.
Esa es la forma del problema entero. El tiempo que ahorras generando lo devuelves en revisión, depuración y mantenimiento. No desaparece: se traslada, y se traslada a un sitio donde cuesta más verlo. Pasamos buena parte de la semana dentro de bases de código donde esa factura ya venció; es la mayor parte de lo que encuentra una auditoría de código IA.
La velocidad que se siente no es la velocidad que se mide
El resultado de METR incomoda precisamente porque los desarrolladores tenían experiencia, trabajaban en código conocido y declararon con total sinceridad lo contrario de lo que marcó el cronómetro. La velocidad percibida y la real se separaron. Cualquier equipo que decida su estrategia de IA por lo rápido que se siente el trabajo está leyendo un instrumento que ya sabemos que está roto.
Software más barato significa más software
El backlog de cualquier empresa es un cementerio de cosas para las que nadie tuvo tiempo. Abarata la construcción y no despedirás a los constructores: por fin empezarás a vaciar el cementerio. Esa ha sido la historia de todas las revoluciones de herramientas desde el compilador, y no hay ninguna razón especial para pensar que esta vaya a invertirla.
Muchos «despidos por IA» no fueron despidos por IA
Las empresas recortan por motivos financieros y lo atribuyen a la IA, porque «lideramos la transformación con IA» les suena mejor a los accionistas que «contratamos de más en 2021 y luego subieron los tipos». Ya hay un término para esto: «AI washing». La pista está en las marchas atrás: organizaciones que recortaron ruidosamente bajo un relato de IA y después reanudaron discretamente la contratación de perfiles de entrada cuando el balance se recuperó.
Así que la IA no eliminó desarrolladores. Eliminó una capa de tareas.
Quédate con esa frase, porque esa capa era el campo de entrenamiento.
El embudo del desarrollador júnior
Aquí está la cifra que importa. El Digital Economy Lab de Stanford, que trabajó con registros de nóminas de ADP —Automatic Data Processing, uno de los mayores procesadores de nóminas de Estados Unidos— sobre millones de trabajadores, encontró que el empleo de desarrolladores de software de 22 a 25 años ha caído alrededor de un 20 % desde finales de 2022.
Ahora mira una fila más abajo en el mismo conjunto de datos. En todas las ocupaciones expuestas a la IA, el empleo cayó un 0,2 % interanual. Los trabajadores mayores en esas mismas ocupaciones se mantuvieron estables o crecieron.
El daño no está repartido por la profesión. Está concentrado casi por completo en quienes intentan entrar.
Por qué ocurrió no tiene tanto que ver con que la IA sea lista
El camino tradicional hacia esta industria era un aprendizaje disfrazado. Te contrataban y durante un año hacías el trabajo que ningún sénior quería: arreglar bugs pequeños, escribir pruebas, actualizar documentación, montar la aburrida pantalla CRUD. No eras rentable. Todo el mundo sabía que no eras rentable. Y estaba bien, porque en doce meses conocerías la base de código y serías útil.
La IA se comió exactamente ese trabajo. No el interesante. El de entrenamiento.
Así que las empresas se enfrentan ahora a una pregunta que no han respondido: ¿cómo incorporas a un júnior cuando no queda nada rutinario que darle?
Y se agrava de tres maneras
Las ofertas mienten. Los anuncios etiquetados como «nivel de entrada» han crecido mientras la contratación real de perfiles de entrada caía: la empresa publica un puesto júnior y lo cubre con alguien que tiene cinco años de experiencia.
No compites con otros júniors. Los despidos de 2024 y 2025 lanzaron al mercado a un gran número de perfiles intermedios, y muchos aceptarán un puesto etiquetado como júnior.
Sostener a un júnior salió más caro. Los séniors declaran dedicar bastante más tiempo a revisar cuando los júniors se apoyan mucho en asistentes de IA. El coste de un júnior subió justo en el momento en que su valor evidente bajaba. Esa es la parte cruel.
Qué hacer al respecto
Deja de optimizar para lo que se ha automatizado. Nadie te va a contratar en 2026 porque sepas producir un componente de React: el modelo lo hace gratis. El argumento para contratarte es el trabajo que está demostrado que el modelo no puede hacer:
- Leer una base de código grande y desconocida y explicar por qué tiene la forma que tiene
- Depurar algo en producción cuando los registros te engañan
- Reconocer cuándo la IA se equivoca con total aplomo; hoy esa es la diferencia, y es justo la habilidad más débil en los júniors
- Responder por un resultado, no por un ticket
Y sé estratégico con el dónde. Las puertas abiertas no son las de tu feed. Empresas grandes, tecnología sanitaria, fintech, sector público, defensa, SaaS de tamaño medio, pequeñas empresas: sitios con bases de código antiguas, requisitos de cumplimiento y dolor real. Quienes hicieron prácticas reciben bastante más ofertas que quienes no las hicieron, y esa diferencia vale más que cualquier framework que puedas aprender este mes.
Difícil no es lo mismo que cerrado. Pero tienes que leer el mercado que hay, y la mayoría de quienes envían candidaturas ahora mismo siguen enviándolas a 2019.
Computación cuántica: qué esperar de verdad
La misma maquinaria de las expectativas ya se está calentando para la segunda vuelta, así que conviene inmunizarse por adelantado.
El resultado que de verdad importa
El chip Willow de Google demostró corrección de errores por debajo del umbral. En términos llanos: durante décadas, añadir cúbits añadía más errores de los que se podían corregir, así que escalar empeoraba las cosas. Willow mostró lo contrario: añades cúbits físicos y la tasa de error lógico baja, exponencialmente.
Ese único resultado saca la computación cuántica de la física y la mete en la ingeniería. Y los problemas de ingeniería se resuelven.
IBM avanza por una hoja de ruta pública hacia una máquina tolerante a fallos, Starling, para 2029, con su procesador actual, Nighthawk, de 120 cúbits, que ejecuta circuitos con miles de puertas de entrelazamiento y el objetivo de demostrar ventaja cuántica verificada antes de que acabe este año, respaldada además por un registro público de seguimiento para que terceros puedan atacar las afirmaciones. Microsoft y Quantinuum tienen cúbits lógicos funcionando con tasas de error mejores que las del hardware subyacente. Progreso real, no humo.
Lo que no significa
No significa que un ordenador cuántico sustituya a tu portátil. Las máquinas cuánticas no son «ordenadores más rápidos». Son un acelerador especializado que gana al hardware clásico en un conjunto reducido de problemas: simular sistemas cuánticos —es decir, química y ciencia de materiales— además de ciertos problemas de optimización y muestreo. Tu app web jamás se ejecutará en una. No existe ventaja cuántica para una API REST.
No significa que el cifrado se rompa el año que viene. Romper RSA-2048 —Rivest–Shamir–Adleman, el algoritmo de clave pública sobre el que funciona casi todo internet, con una clave de 2048 bits— necesita miles de cúbits lógicos, lo que con las tasas de error actuales significa millones de cúbits físicos. Los sistemas actuales tienen cientos de cúbits físicos. Esa distancia no se cierra en un buen trimestre. La encuesta de expertos del Global Risk Institute sitúa la probabilidad de una máquina criptográficamente relevante en diez años en torno al 17-22 %.
La única parte que llega hasta tu trabajo
«Cosecha ahora, descifra después». Un adversario puede grabar tráfico cifrado hoy y descifrarlo en 2035. Así que para todo lo que tenga una confidencialidad de larga duración —historiales médicos, secretos de Estado, archivos legales— la fecha límite de migración es ahora, no cuando exista la máquina. La mecánica de esa amenaza —el algoritmo de Shor, qué le hace a RSA y ECC y por qué las agencias ya guardan tráfico que todavía no pueden leer— la explicamos en nuestra guía sobre el cifrado.
El NIST, el Instituto Nacional de Estándares y Tecnología de Estados Unidos, ha aprobado la versión definitiva de los estándares de criptografía poscuántica, las agencias federales trabajan con un horizonte cercano a 2030 y el trabajo práctico es poco lucido: inventariar dónde está tu criptografía y pasar a intercambio de claves híbrido. Si todavía estás revisando dónde termina TLS en tu infraestructura, ese inventario es exactamente la misma tarea.
Eso es todo lo que la computación cuántica exige de un desarrollador normal en 2026. No necesitas aprender Qiskit para conservar tu empleo.
Y cuando leas el próximo titular, mira la métrica correcta. El número de cúbits físicos es marketing. El número de cúbits lógicos, la tasa de error y la profundidad del circuito son ingeniería. Trata cualquier afirmación de «ventaja cuántica» como provisional hasta que los investigadores clásicos hayan pasado seis meses intentando superarla en un portátil, porque históricamente muchos lo consiguen.
¿Y la IA ejecutada en ordenadores cuánticos?
Es lo menos real de toda esta discusión, y la flecha apunta en sentido contrario.
El problema de la entrada. Para ejecutar un algoritmo cuántico sobre datos ordinarios, primero hay que cargar esos datos en un estado cuántico, y para datos genéricos la carga puede costar tanto como el cálculo. Entrenar un modelo de lenguaje es, sobre todo, mover datos de un lado a otro. Lo cuántico es peor justo en aquello que domina la tarea.
El entrenamiento no escala. Existe un fenómeno llamado mesetas áridas: a medida que añades cúbits a un circuito parametrizado profundo, los gradientes se encogen exponencialmente. El paisaje de la función de pérdida se aplana y no queda nada por lo que descender. Eso no es una nota al pie: es el problema abierto central del campo.
Descuantización. Desde el resultado de Ewin Tang en 2018 —era una estudiante de grado y liquidó una famosa aceleración cuántica escribiendo un algoritmo clásico que la igualaba—, los investigadores encuentran una y otra vez lo mismo. Dale a un algoritmo clásico el mismo acceso a los datos que la versión cuántica da por supuesto en silencio, y la ventaja se evapora. La descuantización no mató el aprendizaje automático cuántico: dibujó su frontera.
Lo que queda dentro de esa frontera es real pero estrecho: datos que ya son cuánticos de partida, además de un puñado de métodos kernel con una separación demostrada. Nada que se parezca a un modelo de lenguaje.
Y aquí está la parte que nos resulta genuinamente divertida. En abril, NVIDIA publicó una familia de modelos abiertos llamada Ising. ¿A qué se dedican? A calibrar procesadores cuánticos y decodificar la corrección cuántica de errores, bastante más rápido y con más precisión que los enfoques tradicionales.
Léelo otra vez. La IA se está usando para construir ordenadores cuánticos, no al revés.
La previsión de Gartner a corto plazo es tajante: ninguna carga de trabajo de IA empresarial funcionando a escala sobre hardware cuántico hasta 2028, y ni siquiera los sistemas tolerantes a fallos tendrán los cúbits lógicos necesarios para una IA de extremo a extremo económicamente viable en 2030.
Una advertencia: «quantum-inspired» es un término de marketing para un algoritmo clásico que se ejecuta en hardware clásico. Cuando un proveedor prometa entrenar IA veinte veces más rápido gracias a la optimización cuántica, comprueba si intervino un solo cúbit. Normalmente, ninguno.
El patrón
Las expectativas sobre la IA se equivocaron al declarar obsoletos a los desarrolladores, y casi nadie se dio cuenta de que acertaron en algo peor y más silencioso: rompimos la escalera que convierte a los principiantes en séniors. Resolvimos el problema del trabajo de entrenamiento borrando el trabajo de entrenamiento.
Lo cuántico está repitiendo la misma jugada. El hito real —la corrección de errores por debajo del umbral— es histórico, y fuera del campo casi nadie habla de él. El hito falso —el cifrado muere el año que viene— está en todas partes.
Aprende a distinguir uno del otro y acertarás sobre tecnología más veces que la mayoría de quienes trabajan en ella.
Si tienes una base de código donde el código llegó más rápido de lo que nadie podía revisar, esa es exactamente la situación que describe el impuesto de verificación, y es para lo que existe una auditoría de código IA. También hemos escrito sobre cómo construimos con IA y sobre los once problemas que encontramos en casi todas las bases de código hechas con IA.
Y si eres tú quien intenta entrar ahora mismo: la escalera está rota, pero el edificio no. Apunta al trabajo que un modelo no puede hacer, y a las empresas cuyos problemas son antiguos, poco lucidos y reales.
Ilya Nixan es fundador y lead developer en Nerdy Production, una agencia Flutter-first que construye y mantiene apps para fintech, salud y retail.
