Hace unas semanas dije en Twitter que el rol de los especialistas de un lenguaje o framework está en las últimas y, como era de esperar, hubo gente llamándome de todo.
Normal.
No es una idea cómoda. A nadie le gusta escuchar que está perdiendo valor a toda velocidad. Pero cuanto más miro el mercado, más claro tengo que me quedé corto.
Hoy vengo a expandir ese post de 280 caracteres con mi opinión completa. Ya visteis una pequeña introducción en el vídeo donde mencionaba que los picateclas tienen los días contados en enero de 2026. Si no lo has visto o leído, no hace falta, en este post vamos a recapitular y continuar.
Respecto a lo que menciono en aquel vídeo, mantengo cada palabra. Y no solo eso: lo que está pasando en el mercado últimamente apunta a un cambio mucho más profundo de lo que yo mismo pensaba.
Tabla de contenidos
1 - Recapitulando: Me quedé corto
En aquel post dije que la IA podría incrementar entre un 30% y un 40% la cantidad de código que producimos. También expliqué que, en muchos casos, el 70% del trabajo no es escribir código, sino entender el problema, hablar con gente y operar en un entorno real.
Esa parte sigue siendo muy similar.
Inicialmente pensaba que la IA solo iba a modificar el rol del picateclas: el de aquella persona que únicamente traduce Jira a código. Y sinceramente, me equivocaba.
La IA está modificando el rol entero. Y no solo eso: está empujando la aparición de una posición nueva, o al menos de una versión moderna de algo que ya existía.
2 - El analista programador ha vuelto, y viene con IA
Si te metes corriendo al estercolero que es LinkedIn y filtras por puestos senior en empresas tech de cierto nivel, vas a empezar a ver nombres que hasta hace nada no eran tan comunes: Forward Deployed Engineer, Product Engineer, Product Builder, Full Stack Builder...
No son exactamente el mismo puesto en todas las empresas, pero todos apuntan hacia la misma dirección: perfiles que entienden el problema, hablan con clientes o negocio, construyen, despliegan e iteran.
Y cuando lees esas ofertas, lo gracioso es que la descripción te suena muchísimo.
Es el analista programador de toda la vida. Pero con IA.
Sí, ese rol que en la gran mayoría del mercado español, o bueno mundial, murió hace 15 años. Ese rol que existía antes de que decidiéramos especializarnos en frontend, backend, devops, SRE, mobile y otros 50 títulos que nos hemos inventado para así no pisarnos los unos a los otros está de vuelta, y vuelve fuerte y sin frenos.
En este tipo de ofertas te piden que hables con clientes, que tú mismo decidas qué hay que construir, por supuesto el diseño, programación y despliegue se dan por hecho que los vas a hacer, sean en la tecnología o con las características que pidan.
Todo ello sin nadie de producto, sin un diseñador que haga mockups o sin un scrum master que te dé tickets como si fueras un niño pequeño, tú solito, end-to-end.
En este punto es donde mi predicción de hace unos meses se queda corta, mi visión era que saldríamos “reforzados como ingenieros”, y pese a que sigue siendo verdad, hay que añadir otra capa, vamos a salir reforzados como personas que entienden el producto, el negocio y saben comunicar fuera de un círculo puramente técnico.
3 - La realidad del mercado
En aquel post yo trabajaba con IA pero no la llevaba al máximo, tenía claro que iba a ser una herramienta, y que el reemplazo del 100% de los ingenieros no lo veía viable, y sigue sin serlo, pero ojo porque he visto algo que me ha cambiado el chip.
En las ofertas de trabajo senior de empresas top, en el apartado de requisitos ya no se valora de forma positiva si tienes experiencia con IA, ha pasado a ser un requisito obligatorio para entrar en dichas empresas.
Y antes de que alguien salte con lo de siempre, que la IA alucina, que genera código malo, que “yo lo hago mejor a mano”, te diré una cosa: eso ya no es un argumento suficiente.
Claro que la IA se equivoca. También se equivoca un junior, también se equivoca un senior y también se equivoca el arquitecto que lleva diez años en la empresa. La diferencia es que a una persona no la juzgas por no acertar a la primera, sino por cómo la diriges, qué contexto le das, cómo revisas su trabajo y cómo integras el resultado.
Con la IA pasa lo mismo. Si tu única conclusión después de usarla es “alucina”, puede que el problema no sea solo la herramienta. Puede que el problema sea que no sabes pedirle, acotarla, verificarla ni convertirla en parte de tu flujo de trabajo.
Esto no significa que desaparezcan los especialistas. Significa que el especialista medio, el que solo sabe moverse dentro de una cajita muy estrecha, va a tener cada vez menos margen.
3.1 - Las cuentas de la empresa
En aquel post hablé del cambio cualitativo: cómo cambia la forma de programar. Hoy quiero hablaros del cambio cuantitativo, del que duele, por lo menos a mi. Matemáticas puras.
Un equipo tradicional consiste en lo siguiente
- 1 Product owner
- 1 Designer
- 3-4 Backend developers
- 1-2 Front end developers
- 1 QA
- 1 DevOps
- 1 Manager
En algunas organizaciones el rol de QA, así como el de DevOps en verdad es alguien del equipo, ya sea uno de front o de back el que se encarga. En los equipos que he trabajado últimamente siempre he sido yo, por ejemplo, quien se ha encargado de montar pipelines de despliegue, etc. Alguna vez te falta acceso, lo pides, o pides lo que sea concreto, te lo dan y arreando.
Desde el punto de vista de la empresa, esto es muchísimo overhead. Un equipo tradicional puede tener 7, 8 o 9 personas entre producto, diseño, backend, frontend, QA, DevOps y management. Entre salarios, impuestos, coordinación, reuniones y handoffs, la factura es enorme.
Si una parte de esas funciones se absorbe en perfiles más autónomos, apoyados por IA, el incentivo económico es evidente: menos gente para coordinar, menos tiempo esperando a otros equipos, menos reuniones y más velocidad de entrega.
¿De verdad pensabas que los CFOs del mundo iban a ignorar este ahorro? Venga ya.
3.2 - El tema de los especialistas
Es obvio que con el uso de la IA como herramienta de trabajo el listón de calidad sube, quien era un desarrollador “medio”, por llamarlo de alguna forma, una vez dominaba el uso de la IA (Skills, agentes, harness, etc) se convertía en un buen desarrollador, en algunos casos en uno muy bueno.
Lo que no expliqué bien es que la IA no solo sube el listón en profundidad, sino también en amplitud.
A muchos desarrolladores junior y mid se les ha vendido la moto durante los últimos años con la hiperespecialización "Yo soy frontend React con TypeScript y Next.js". Vale, perfecto. ¿Y qué más?
En las ofertas de trabajo de hoy en día hay que saber un poco de todo, integraciones con apis, sincronización de datos, gestión de identidad entre sistemas, pipelines de datos, despliegues, observabilidad, como usar la IA, conocimientos básicos de front end, etc.
No tienes que ser el mejor del mundo en React, ni en C#, ni en Java. Pero tienes que tener criterio suficiente en varias áreas para avanzar sin bloquearte cada dos horas y para saber cuándo la IA te está ayudando y cuándo te está vendiendo humo con mucha seguridad.
Esto, amigos míos, no mata al especialista excelente. Mata al especialista cómodo.
El top 1% que sabe muchísimo de algo seguirá teniendo sitio. El problema lo tiene el que ha confundido especialización con no querer aprender nada más.
3.3 - De T-Shaped a M-Shaped developers
Durante años se habló del perfil T-Shaped: alguien con profundidad en un área y conocimientos generales en otras. Eso tenía sentido en equipos grandes, donde podías ser muy bueno o incluso una referencia en frontend y apoyarte en backend, DevOps, QA, producto o diseño.
Pero la IA empuja hacia algo más parecido a un perfil M-Shaped: varias columnas de profundidad razonable. No necesitas ser top 1% en cinco disciplinas, pero sí tener suficiente criterio en varias para poder dirigir a la IA, revisar lo que genera y tomar decisiones sin depender constantemente de otra persona.
4 - Qué significa esto para tí
Es mi blog y hago lo que quiero, en concreto, voy a dar mi opinión sobre lo que hay que hacer.
De primeras, empieza a usar la IA en serio, HOY, no mañana, ni “cuando tenga tiempo”, HOY. ya bien sea cursor, claude, copilot, codex o lo que te dé la santa gana. Usa la IA a diario en proyectos reales hasta que esta sea una extensión de tu cerebro, no le dejes ir a lo loco, define reglas, dirigela, revisala e itera.
Aprende de producto. Lo he dicho muchas veces: mucho programador entra al curro, lee los tickets de Jira, cambia el código y, tres años después, no sabe ni qué vende la empresa. En el mundo al que vamos, si no entiendes el negocio, eres reemplazable.
Ensancha tu stack. Si solo sabes frontend, aprende backend. Si solo has trabajado en backend, aprende cosillas de DevOps. Si no has hecho una integración con un sistema externo en tu vida, ponte a ello.
El T-Shaped Developer ha evolucionado a M-Shaped Developer, y esto es obligatorio, no opcional para tu futuro.
Aprende a hablar con humanos, no tiene mucho misterio, si se te achica el chinchulín hablando en una reunión tienes un problema serio.
No creo que cualquiera con Claude vaya a sustituir a un buen ingeniero. Esa no es la idea.
Lo que sí creo es que cualquiera con criterio de producto, contexto de negocio y una IA bien usada va a poder hacer muchas de las tareas que antes justificaban tener a una persona únicamente picando tickets.
Y ahí está el problema: si tu valor profesional era solo traducir una historia de Jira a código, tu margen se va a reducir muchísimo. Las empresas no buscan simplemente manos que ejecuten. Quieren perfiles que entiendan problemas, tomen decisiones y usen la IA como músculo.
Si tú eres solo manos, estas jodido. Si eres cerebro + criterio de producto + capacidad técnica + IA, el futuro pinta bastante mejor.
