¿La IA les quitará el trabajo a los programadores?

La respuesta corta para 2026: la IA no les quitará el trabajo a los programadores, pero sí se quedará con parte del trabajo de cada programador, y no de forma uniforme. Lo que desaparece es escribir código desde cero. Lo que se queda y gana valor es decidir qué construir, cómo debe comportarse bajo carga y quién responde cuando salta la alerta de guardia a las 3 de la madrugada. Quien te venda que “todo el mundo pierde su trabajo” o que “es solo un juguete, nada cambia” te está vendiendo consuelo, no la verdad.

Lo que la IA automatiza de verdad hoy

No es especulación: es lo que los modelos hacen bien ahora mismo, en el día a día de equipos reales:

• boilerplate: controladores CRUD, mappers de DTO, configuración, esquemas de validación, componentes de UI repetitivos;
• tests: cobertura del happy path, los casos límite que nunca te molestaste en enumerar, datos de prueba y fixtures;
• glue code: integraciones con API, transformaciones de datos, scripts de migración, parsers de formatos;
• primeros borradores: el esbozo de una función que vas a reescribir de todos modos, pero empezando desde el 60% en lugar de desde un archivo vacío;
• traducción: de un lenguaje a otro, de un framework legacy a uno nuevo, de código a documentación y viceversa;
• explicar código ajeno: “qué hace esta función y por qué” en un repositorio que no conoces.

No es una lista pequeña. Siendo realistas, es entre un 30 y un 50% del tiempo que antes se iba en teclear en lugar de pensar. Justo por eso el rol cambia en vez de desaparecer.

Lo que la IA no hace (ni hará en mucho tiempo)

La frontera no está donde la mayoría supone. No se trata de “código difícil”. Se trata de tareas en las que el problema es la ambigüedad y la responsabilidad, no la sintaxis:

• diseño de sistemas: dónde trazar los límites entre servicios, dónde necesitas consistencia y dónde disponibilidad, cómo debe degradarse el sistema ante un fallo. Decisiones cuyas consecuencias solo se ven un año después;
• requisitos ambiguos: el cliente dice “que sea rápido”, pero lo que quiere decir es que un informe concreto tarda 40 segundos en cargar. Sacar eso de una conversación es trabajo, no un prompt;
• responsabilidad: cuando los pagos fallan, una persona tiene que tomar la decisión, cargar con las consecuencias y dar la cara ante el equipo. Un modelo no va a asumir el riesgo;
• criterio entre equipos: si vale la pena romper una API de la que dependen otros tres equipos para ganar un 5% de rendimiento. Eso es negociación y política, no ingeniería;
• contexto que no está en el repo: por qué existe ese if tan raro (porque un cliente grande tiene un contrato peculiar), qué no debes tocar antes de las fiestas, a quién le importa qué.

La IA genera soluciones. La persona decide qué problema resolvemos en primer lugar y qué compromiso es aceptable. Lo segundo es más difícil, y es lo que se paga.

El cambio: de escribir código a dirigir y revisar

El cambio más importante no es que los programadores desaparezcan. Es que cambia la actividad por la que te pagan. Menos tiempo en el editor y más tiempo en el papel que antes solo desempeñaba un tech lead: definir la tarea, controlar la calidad, decidir qué sale a producción y qué no.

En la práctica, el día se parece cada vez más a esto: escribes una descripción precisa de lo que debe existir, un agente genera la implementación y tú la lees con tanto cuidado como si revisaras el trabajo de un junior que escribe muy rápido y con mucha seguridad, incluso cuando se equivoca. Esto exige más habilidad de ingeniería, no menos. Para juzgar si el código generado es bueno, tienes que ser capaz de escribirlo tú mismo. De lo contrario, eres solo una tubería por la que fluye código que no entiendes.

Esta es la trampa en la que caen muchos: confundir la velocidad de generación con la velocidad de entrega. Pero el código que nadie entiende no es un producto terminado: es deuda que solo se revelará en producción.

La compresión del rol junior y cómo responder a ella

Aquí no tiene sentido fingir. Las tareas clásicas con las que los juniors aprendían el oficio (tickets sencillos, boilerplate, “añade tests a este módulo”) son exactamente lo que mejor hace la IA. El peldaño más bajo de la escalera está comprimido de verdad, y sería un optimismo ingenuo afirmar lo contrario.

Pero “comprimido” no es “eliminado”. Lo que cambia es lo que el mercado espera de un junior desde el primer día. Los consejos que considero honestos:

1. Aprende a leer código más rápido de lo que lo escribes. La revisión se convierte en una habilidad básica, no en algo que llega después de cinco años.
2. Construye cosas completas, no fragmentos. Un proyecto end-to-end que funciona y está desplegado enseña más que cien tickets cerrados, porque te enseña los límites que el modelo no conoce.
3. Profundiza en un dominio. Pagos, datos médicos, logística: el contexto del dominio es una ventaja que la IA no tiene, porque no estaba en los datos de entrenamiento.
4. Usa la IA de forma agresiva, pero verifícalo todo. Un junior que trata al modelo como un oráculo infalible es más peligroso que un junior sin IA.
5. Apunta a estar tomando decisiones dentro de 18 meses, no solo ejecutándolas. El valor se está desplazando hacia el criterio: corre hacia donde corre el valor.

El argumento de la paradoja de Jevons

La paradoja de Jevons dice que, cuando un recurso se abarata, consumimos más de él, no menos. Cuando las máquinas de vapor se volvieron más eficientes, el consumo de carbón aumentó, porque pasó a compensar usarlo en todas partes. Si escribir software acaba de abaratarse en un orden de magnitud, la consecuencia lógica no es que necesitemos menos programadores, sino que de repente compensa construir software que nadie tocaba antes porque costaba demasiado.

¿Una herramienta interna para un departamento de diez personas? Antes era injustificable. Hoy, una tarde de trabajo. ¿Una app para un nicho que nunca salía rentable? De repente, lo es. El backlog de “estaría bien, pero nunca hay tiempo” de cualquier empresa es enorme. Una entrega más barata no agota la demanda: la deja al descubierto.

Una advertencia honesta: la paradoja de Jevons no es una ley de la naturaleza y no garantiza el mismo número de puestos de trabajo. Garantiza más trabajo por hacer. Que eso se traduzca en número de empleados depende de cuántos ingenieros hacen falta por unidad de valor entregado, y esa cifra está bajando. Mi apuesta: la demanda crece más rápido de lo que baja el número de manos necesarias, pero la ventaja pasa a quienes saben dirigir, no solo teclear.

Las analogías históricas y dónde se rompen

Ya lo has oído: los compiladores iban a acabar con los programadores de ensamblador, los IDE iban a acabar con la programación “de verdad”, el no-code iba a acabar con los desarrolladores. Cada vez ocurrió lo contrario: la abstracción subió el listón y amplió el mercado. El número de programadores no bajó tras la aparición de los compiladores; se disparó.

Pero las analogías son cómodas, y eso las hace peligrosas. ¿Dónde se rompe esta? Un compilador es determinista: la misma entrada produce siempre la misma salida, así que dejaste de revisar el ensamblador que generaba. Un LLM es probabilístico y puede mostrarse muy seguro mientras se equivoca, así que la capa de verificación no desaparece: crece. Eso cambia el equilibrio: el compilador se llevó trabajo y no te devolvió responsabilidad a cambio. La IA se lleva el tecleo, pero añade supervisión. La segunda diferencia: las abstracciones anteriores subían a la persona un nivel. Esta la lleva del papel de ejecutor al de revisor y responsable de las decisiones: cambia la naturaleza del trabajo, no solo su nivel.

Consejos concretos: cómo seguir siendo valioso

Sea cual sea tu nivel, en 2026 el valor se concentra en unos pocos sitios. Estas son las cosas en las que vale la pena invertir de forma deliberada:

• criterio arquitectónico: la capacidad de decir “esto funcionará ahora, pero dentro de un año nos va a matar” es exactamente lo que le falta al modelo;
• la revisión como oficio: leer código buscando bugs sutiles, no solo problemas de estilo. Esto pasa a ser una competencia central, no secundaria;
• profundidad en el dominio: entender el negocio, la normativa, la física del problema que estás programando. Ahí vive el contexto que falta en el entrenamiento;
• comunicación y traducción de la ambigüedad: convertir un vago “mejóralo” en una especificación que se pueda construir y defender;
• asumir la responsabilidad: estar dispuesto a decir “yo respondo por esto” y cargar con las consecuencias. Eso no se puede automatizar, porque no es una tarea técnica.

Lo que conviene evitar: una identidad construida en torno a la pura velocidad de tecleo o a un único framework. Si tu ventaja es “escribo React rápido”, esa ventaja es justo lo que se está convirtiendo en una commodity. Si tu ventaja es “sé qué construir y me hago responsable de ello”, estás en el lado correcto del cambio.

En resumen

La IA no les quitará el trabajo a los programadores, pero cambiará en qué consiste, y rápido. Automatiza el boilerplate, los tests, el glue code y los primeros borradores; no automatiza el diseño de sistemas, los requisitos ambiguos, la responsabilidad ni el criterio entre equipos. El rol pasa de escribir código a dirigir y revisar, así que exige más ingeniería, no menos. Los juniors son los más comprimidos, y su respuesta es leer código, hacer proyectos end-to-end y profundizar en un dominio. La paradoja de Jevons sugiere que un código más barato deja al descubierto una enorme cantidad de demanda nueva, aunque no garantiza un número fijo de empleados. Las analogías con los compiladores tranquilizan, pero se rompen ante el hecho de que un LLM es probabilístico, así que la supervisión crece en lugar de desaparecer. Sé quien decide y responde, no quien teclea más rápido.