De Software Engineer a Product Engineer

Durante todo 2026, la forma que tenía de trabajar está dando un vuelco vertiginoso. Estamos iterando nuevas features más rápido que nunca, mejorando las existentes casi sin pestañear y, en general, evolucionando todo el ecosistema que hace esto posible a un ritmo frenético. Esto ha hecho que me deje de considerar un desarrollador que se fija en cada línea que escribe, tratando de encontrar el mejor balance entre legibilidad y performance y haya subido unas cuantas capas (muchas) hasta estar en una posición desde la que ver qué aporta más valor al usuario y poder enfocarme en ello. He pasado a considerarme un ingeniero de producto.

El cambio de paradigma que ya está aquí

No voy a explicar lo que ya todos estamos viviendo, en mayor o menor medida, cada día: el desarrollo agéntico (término terrible, si me preguntas) ha irrumpido con fuerza y está aquí para quedarse. Depende de cada uno (y de su empresa, en buena medida) hasta qué nivel lo incorpora en su día a día. Lo que está claro es que mi forma de trabajar no se parece en nada a la de hace exactamente un año. Y esto es bueno.

Necesito dedicar menos tiempo a pensar cómo desarrollar una nueva feature y dedico más tiempo a describir cómo se relaciona con las ya existentes, su scope y lo que puede fallar a su alrededor. El resultado es un producto más robusto y seguro.

Además, esto abre la puerta a pequeños detalles a los que antes nunca prestábamos atención, normalmente por el ratio tiempo invertido / retorno de la inversión: transiciones, animaciones y otros detalles de UI que solo aportan valor si todo lo que hay por debajo es útil y funcional.

Cómo me adapto a ello

Mi forma preferida de aprender siempre ha sido mediante vídeos y cursos, nunca libros. Para mí, es la forma más dinámica y visual de aprender. Ahora, basta con ver los principales creadores de contenido en YouTube para confirmar que todo ha pasado a centrarse en IA: cómo desarrollar con ella, qué harneses usar, benchmarks y comparaciones entre modelos…

En realidad no ha cambiado mucho si lo comparamos con la época pre-IA: cómo desarrollar en X/Y/Z, qué frameworks y librerías usar, comparaciones entre las mismas (sí, me refiero al típico Vue vs React, Java vs Ruby, etc.).

Admito que esta sigue siendo la vía que más me gusta para mantenerme al tanto de todo lo que sale, que no es poco. En lo que llevamos de año hemos pasado por:

• Desarrollar con planes
• Loop engineering
• Harness engineering

Y seguro que me dejo muchos. Honestamente, hay mucho ruido que filtrar últimamente, y hace falta que pase el tiempo para que se asiente una forma de desarrollar. O quizá no, porque no me imagino en qué punto los modelos dejarán de evolucionar y, con ellos, la forma de trabajar. Tenemos años muy interesantes por delante.

Mi descripción de Product Engineer

Hasta ahora he hablado de cómo la IA ha cambiado mi forma de trabajar, pero merece la pena que explique qué considero yo ser un Ingeniero de producto, pues, como muchos otros términos en esta industria, puede que tenga diferente significado en función de la persona o empresa en la que te encuentres.

• Product first: lo más importante (creo que siempre lo ha sido) es la calidad del producto final que entregas. Antes dedicábamos mucho tiempo a cuidar aspectos como la calidad, legibilidad y escalabilidad del código. Esos puntos siguen siendo muy importantes, pero ya no dependen tanto de nosotros: se los delegamos a agentes de IA. Nuestro tiempo pasa, ahora, a estar más ocupado en conversaciones sobre qué construir, más que cómo hacerlo.
• Contexto: ahora que podemos abstraernos más del código y tenemos más tiempo para mirar de forma más panorámica aquello que construimos, veo que es extremadamente importante que nosotros pasemos a ser un contexto andante. Leyendo innumerables hilos de Slack, escuchando conversaciones entre managers y probando nuestro producto continuamente conseguimos tener siempre información actualizada sobre en qué punto está el proyecto y hacia dónde va, por qué se tomaron ciertas decisiones arquitectónicas y en qué están trabajando el resto de equipos de la empresa. Esto permite dar un contexto mucho mejor a los agentes, guiándolos para que extraigan información de una PR específica o apunten a cierta conversación de Slack.
• Métricas: se acabó el ship and forget, o, mejor dicho, el ship and que lo valide el PM. Ahora soy yo quien define qué significa que una feature funcione, instrumento los eventos necesarios para medirlo y reviso los números días después de haberla lanzado. La métrica deja de ser un informe que me entregan y pasa a ser una herramienta de trabajo más.
• La observabilidad: si soy responsable de que una feature funcione en producción, necesito poder ver qué está pasando sin depender de que alguien más me avise. Logs, trazas y dashboards dejan de ser cosa exclusiva del equipo de plataforma y pasan a formar parte del propio desarrollo: si no puedo observarlo, no lo he terminado de construir.

High agency

Creo que una de las habilidades más valiosas de un ingeniero, ahora y siempre, es la agencia: ser proactivo dentro del equipo y la compañía, no esperar a que un manager te asigne una tarea o que el equipo entre dentro de un nuevo sprint.

Dado que el coste de llevar una feature desde la fase de ideación hasta la puesta en producción (con su consiguiente monitorización), ha caído en picado, la capacidad para encontrar, por iniciativa propia, qué puede aportar valor al producto se ha vuelto una de las principales características de un product engineer.

Y esto no necesariamente significa que debamos embarcarnos en la refactorización en Rust de nuestro servicio core o de saltarnos las capas de jerarquía que puedan existir. A veces, simplemente, basta con utilizar el producto que tú mismo estás desarrollando, encontrar un bug y decidir solventarlo, sin necesitar un ticket de JIRA para ello.

Los roles tradicionales se difuminan

Hasta ahora, en cualquier empresa de producto, encontrábamos tres roles principales: el software engineer, el product designer y el product manager. Antes de la IA, las tareas de estos tres perfiles estaban claramente delimitadas: uno definía unas tareas y tiempos de entrega, otro las adaptaba al producto y refinaba, y el último transformaba esos PRD y tickets de JIRA en código. El esfuerzo conjunto de estos perfiles era el que creaba el producto.

Ahora, dónde empieza y dónde acaba el trabajo de cada uno de estos perfiles no podría estar más difuminado. Mis compañeros managers son capaces de lanzar fixes o crear métricas dentro del código. Los designers implementar features enteras en el frontend del proyecto. Los ingenieros creamos nuevos diseños desde cero y definimos el success criteria, pudiendo validar end to end la adopción e impacto de lo que hemos hecho.

No sé cómo evolucionarán dichos roles, si seguirán fusionándose hasta que una sola persona acabe desempeñando los tres roles (y quizá alguno más por el camino) o seguiremos, cada uno, aportando en lo que mejor se nos da hacer y colaborando más estrechamente que antes.

¿Adaptarse o morir?

Mientras nos adaptamos a este nuevo paradigma y desarrollamos las skills necesarias para ello (recordemos que absolutamente todo se puede entrenar y desarrollar), me gusta recordar una frase que he escuchado muchas veces a lo largo de mi carrera: este trabajo es una carrera de fondo.

No sé a qué ritmo adoptará la gran mayoría de empresas este incremento de responsabilidades para sus ingenieros, pero estoy seguro de que llegará, en mayor o menor medida. Me cuesta imaginarme, dentro de cinco años, que una empresa siga ofertando puestos de frontend, con una metodología agile, en un proyecto «estable y con perspectivas de futuro», y que el sector lo vea como algo bueno. Al final, quieres estar del lado ganador (el que más empleabilidad tenga a futuro) y ese es el de un ingeniero de producto.