Sustituir el rol o ser mejor en él: lo que los despidos tech no están contando

Llevamos meses oyendo que la IA va a acabar con los programadores. Los despidos masivos, los titulares sobre agentes que escriben código solos, los CEOs que dicen que contratarán menos ingenieros. Llevo más de un año trabajando con agentes en proyectos reales y lo que he visto no es lo que se cuenta.

Sustituir el rol o ser mejor en él: lo que los despidos tech no están contando

Llevamos meses oyendo lo mismo: la IA va a acabar con los programadores. Los despidos masivos en grandes tecnológicas, los titulares sobre agentes que escriben código solos, los CEOs que dicen que contratarán menos ingenieros. La narrativa está instalada. Y como cualquier narrativa que se repite mucho, tiene algo de verdad y mucho de foco equivocado.

Llevo más de un año trabajando con Claude Code en proyectos reales. No demos. No experimentos de fin de semana. Proyectos con CI/CD, con tests E2E, con arquitectura hexagonal, con deploys automáticos a producción. En ese tiempo he pasado por tres formas completamente distintas de trabajar con agentes IA: agentes sueltos, equipos coordinados y, finalmente, rules que orquestan todo lo anterior. Y en ese recorrido, sin ir a buscarlo, encontré la respuesta a la pregunta que todo el mundo se está haciendo sobre los despidos. La diferencia entre sustituir un rol y volverte mejor en él es exactamente la misma que hay entre un agente y una rule. Y esa diferencia es la que separa los puestos que van a desaparecer de los que no.

Agentes vs rules en mis propias carnes

El punto de partida fue lo más natural del mundo: un agente por tipo de problema. Necesito revisar arquitectura, llamo al architect-reviewer. Necesito montar tests E2E, llamo al playwright-expert. Necesito implementar un endpoint, llamo al backend-developer. Cada uno con su system prompt, su foco, sus herramientas restringidas. El contexto del hilo principal no se contamina con logs de exploración que no voy a necesitar. La calidad mejora porque cada agente sabe exactamente para qué está ahí.

Al principio no lo vi. La coordinación la ponía yo sin darme cuenta: yo recordaba a quién llamar, yo decidía el momento, yo pasaba el contexto de un agente a otro cuando hacía falta. Mientras las tareas eran simples, ese coste era invisible. Cuando el flujo se volvió complejo, apareció el problema real: si ese día no me acordaba de invocar al reviewer, no había review. El sistema no se activaba solo.

La respuesta fue escalar. Con TLOTP llegaron los equipos coordinados. San Patricio de 2026 fue la primera prueba real: una feature completa con SDD previo —requisitos, diseño, tareas— y varios agentes en paralelo, cada uno con su dominio, trabajando en oleadas donde nadie avanzaba hasta que la anterior estaba cerrada. Los requisitos eran la ley. Lo que no estaba escrito no existía. Lo que estaba, no era negociable. Si quieres ver cómo funciona en detalle, aquí están los 6 patrones que destilé de esa experiencia. Funcionó.

Funcionó. Pero el coste de entrada era alto. Generar el SDD, montar el equipo, definir las waves, asignar roles. Para una feature grande, perfecto. Para el flujo diario de trabajo, demasiado ritual. Y seguía siendo yo quien decidía cuándo merecía la pena montar el equipo y cuándo no. El sistema no lo sabía solo. Yo lo activaba o no lo activaba.

El techo era el mismo en los dos casos: la coordinación siempre la ponía yo.

¿Quieres sustituir el rol o ser excelente en él?

Aquí es donde el enfoque cambió. No hacia más agentes, sino hacia una pregunta distinta: ¿quiero que la IA ocupe el rol, o quiero que la IA me haga mejor en ese rol?

Imagina un administrativo que gestiona incidencias de clientes y responde correos. Puedes montarlo como agente: le das el acceso, le defines el protocolo, él procesa las incidencias y te trae el resumen. Tú no participas en la ejecución. Recibes el resultado. El agente sustituye al administrativo.

O puedes tener una rule que define cómo responder, cuándo escalar, qué información pedir antes de cerrar una incidencia, qué tono usar según el tipo de cliente. Esa rule no sustituye a nadie. Te convierte a ti —o a Claude trabajando contigo— en un administrativo que nunca olvida el protocolo. Sin que tengas que pensar en ello. Sin que tengas que activar nada.

Son dos decisiones completamente distintas. Ninguna es mejor. Dependen de una sola cosa: si quieres estar dentro de la ejecución o solo al final.

El CEO sí lo sustituyo

El rol de coordinación es diferente. Quien decide qué agente hace qué, en qué orden, con qué input, qué se valida antes de continuar — ese rol no quiero ejercerlo yo. No porque no pueda, sino porque es exactamente el tipo de trabajo que se puede delegar sin perder nada. El CEO de mi flujo es un agente o un team. Yo entro cuando hay una decisión que solo yo puedo tomar. El resultado me llega. El proceso no me importa.

Rules que saben cuándo quiero un agente, cuándo un equipo y cuándo solo protocolo

El estado en el que trabajo ahora es la combinación de todo lo anterior. Las rules más interesantes que tengo no describen comportamiento directamente. Describen criterios: si la tarea es de este tipo, monta el equipo con estos roles y este SDD. Si es de este otro, delega solo al especialista. Si es esto otro, aplica el protocolo directamente sin agentes.

La rule decide sola. No tengo que recordar cuándo merece la pena el ritual del team agent y cuándo es suficiente un especialista puntual. No tengo que pensar si el administrativo debería ser agente o protocolo. El criterio está escrito, siempre activo, siempre aplicado. Cero overhead cognitivo. Yo entro cuando hay algo que decidir que nadie más puede decidir.

Entonces, ¿quién desaparece primero?

Todo esto no es solo una preferencia técnica. Es la misma pregunta aplicada a las personas: ¿estás usando la IA para ser más experto en lo que haces, o para que ella haga lo que tú hacías? Después de meses trabajando con agentes, la respuesta se ve sola. Los que sobreviven son los que usan la IA como una rule: se vuelven más rápidos, más precisos, sin perder el criterio. Los que desaparecen son los que ya eran un agente: ejecutaban un protocolo que ahora se puede escribir en un fichero de texto.

Y ese protocolo no es el de los programadores. Programar —en el sentido real— es pensar en abstracciones, diseñar soluciones, tomar decisiones con consecuencias. Es exactamente lo que los agentes no hacen solos. Necesitan que alguien defina el problema, valide el resultado, detecte cuándo el camino es incorrecto.

Los que desaparecen primero son los que solo coordinan, solo clasifican, solo reportan hacia arriba. Los roles cuya función es mover información de un sitio a otro sin transformarla. Los que delegan sin pensar, los que escalan sin criterio, los que generan reportes que nadie lee pero que alguien tiene que producir. Esos roles se pueden robotizar completamente sin perder humanidad ni calidad humana — porque en esos roles la humanidad ya había desaparecido antes de que llegara la IA.

La pregunta que me hago —y que le haría a cualquier programador que tenga miedo— no es si la IA va a sustituirle. Es si está en el lugar donde la IA le hace más experto o en el lugar donde la IA le puede reemplazar sin que nadie lo note. Mover el culo antes de que te muevan es la única estrategia que tiene sentido. No huir de la IA. Ir hacia donde la IA amplifica lo que sabes hacer, no hacia donde lo sustituye.

Los despidos que están pasando no son el inicio del fin de los programadores. Son el inicio del fin de los roles que nunca deberían haber existido como están definidos.