Después de DevOps viene la ingeniería de producto
Durante buena parte de mi carrera me he definido como desarrollador .NET y como alguien que trabaja en DevOps. Pero si miro cómo ha cambiado mi trabajo en los últimos años, la balanza se inclina cada vez menos hacia una tecnología concreta y cada vez más hacia una responsabilidad completa sobre lo que entregamos.
Para mí, esa es la conversación importante sobre la inteligencia artificial.
Se habla mucho de cuánto código puede generar, si hay que revisarlo y si un agente reemplazará a un programador. Todo eso forma parte del cambio, pero ya hay demasiadas discusiones centradas en el código. Lo interesante es lo que viene después: cuando producir software se vuelve más barato, el valor se mueve hacia entender el producto, operar el sistema y responder por el resultado.
Mi lectura es que DevOps fue una transición en esa dirección. El ingeniero de producto será el perfil que termine de juntar esas piezas.
El cambio ya se veía antes de la IA
Cuando empecé a trabajar como desarrollador, gran parte de mi identidad profesional estaba ligada al stack. Era desarrollador .NET. Otros eran programadores Java, PHP o JavaScript. La tecnología decía bastante sobre el trabajo que hacíamos y sobre las vacantes a las que podíamos aplicar.
Con el tiempo empecé a participar más en despliegues, infraestructura, seguridad, observabilidad y automatización. No fue un cambio de profesión. Fue una consecuencia natural de llevar el software hasta producción.
Ahí entendí que completar una funcionalidad no era terminar el trabajo. También había que conseguir que se desplegara de forma segura, saber qué hacer cuando fallara, vigilar sus costos y comprobar que realmente resolviera el problema.
Por eso la balanza se fue inclinando hacia DevOps. No porque programar dejara de importar, sino porque el código era una parte cada vez más pequeña de la responsabilidad completa.
La IA acelera esa tendencia. Hoy puede ayudar a escribir una clase, preparar un pipeline, generar infraestructura o investigar un error. Mañana hará más. Pero el cambio de fondo ya había empezado: las empresas no necesitan código por el código mismo. Necesitan productos que funcionen, que se puedan operar y que produzcan algún resultado.
DevOps tampoco es el destino final
DevOps ganó valor porque eliminó una separación artificial. Durante años actuamos como si desarrollo terminara cuando el código llegaba a un repositorio y desde ahí comenzara el problema de otra persona.
Eso nunca funcionó demasiado bien.
Un equipo podía entregar una aplicación técnicamente correcta que fuera difícil de desplegar, imposible de observar o demasiado costosa de mantener. DevOps nos obligó a mirar el ciclo completo y a entender que construir y operar no eran dos trabajos aislados.
Pero ahora corremos el riesgo de convertir DevOps en otra especialidad cerrada. Si pensamos que consiste en escribir YAML, administrar pipelines, preparar manifiestos o levantar infraestructura, la IA también reducirá buena parte de ese trabajo. Igual que ocurre con el código, el artefacto se vuelve más fácil de producir.
Ya escribí sobre por qué la IA no acaba con DevOps, sino que lo obliga a volver a la entrega de valor. Este artículo parte de ahí y da un paso más: incluso el término DevOps puede quedarse corto cuando la persona todavía recibe decisiones de producto tomadas por otros y solo se responsabiliza por ejecutarlas bien.
La siguiente frontera no está entre desarrollo y operaciones. Está entre tecnología y producto.
La IA reduce las fronteras entre especialidades
Antes necesitábamos repartir muchas tareas porque cada una consumía bastante tiempo y exigía herramientas distintas. Una persona escribía el backend, otra preparaba la interfaz, otra configuraba el pipeline y otra analizaba lo que pedía el negocio.
La especialización seguirá existiendo. Un sistema financiero no deja de necesitar seguridad, ni una plataforma de gran escala deja de necesitar personas con profundidad en redes, datos o rendimiento. El punto no es que ahora todos sepamos de todo.
El cambio es que la IA permite que una persona cubra una porción más amplia del proceso sin quedarse atrapada en cada detalle mecánico. Puede entender un repositorio que no conoce, crear una primera versión, automatizar parte del despliegue, consultar la telemetría y ajustar la solución. Lo que antes pasaba por varias colas de trabajo puede ocurrir dentro de un mismo ciclo.
Eso no elimina al equipo. Lo vuelve más importante. La diferencia es que las personas ya no necesitan organizarse alrededor de cada herramienta, sino alrededor del problema que intentan resolver.
Aquí también aparece una responsabilidad nueva: construir los mecanismos que permitan usar la IA con confianza. Reglas, pruebas, permisos, observabilidad y límites operativos forman parte del trabajo. Pero no son el centro del artículo ni deberían convertirse en otro fin técnico. Sirven para que podamos delegar ejecución sin perder control sobre el producto.
La investigación de DORA sobre desarrollo asistido por IA usa una idea que resume bien este punto: la IA actúa como un amplificador. Una organización con objetivos claros, buenos ciclos de feedback y una plataforma confiable puede avanzar más rápido. Una organización desordenada solo produce desorden con mayor velocidad.
Qué entiendo por ingeniero de producto
Un ingeniero de producto es un perfil técnico que no mide su trabajo por la cantidad de código, tickets o despliegues que completa. Se responsabiliza por resolver un problema y cerrar el ciclo.
Eso significa entender qué necesita el usuario, participar en la decisión de qué construir, elegir una solución técnica razonable, llevarla a producción y mirar qué ocurrió después. Si la funcionalidad se desplegó perfectamente pero nadie la usa, el trabajo no fue exitoso.
No es un product manager que aprendió a programar. Tampoco es un desarrollador full stack con un título nuevo. La diferencia está en el tipo de responsabilidad.
El ingeniero de producto combina:
- Conocimiento técnico, para construir soluciones que se puedan mantener y operar.
- Criterio de producto, para distinguir una necesidad real de una lista de funcionalidades.
- Lectura del negocio, para entender qué resultado justifica el esfuerzo y el costo.
- Capacidad operativa, para desplegar, observar y corregir lo que ocurre en producción.
- Comunicación, para trabajar directamente con usuarios, producto, diseño y otras especialidades.
No tiene que ser la persona más profunda en cada área. De hecho, pretender que una sola persona reemplace a todo el equipo sería una mala interpretación. Necesita profundidad suficiente en algunas capacidades y amplitud para conectar las demás.
Para mí, el cambio más importante es dejar de pensar: “mi parte ya está lista”. El ingeniero de producto puede pedir ayuda a especialistas, pero no entrega la responsabilidad junto con el ticket.
Las vacantes cambiarán después que el trabajo
Creo que veremos menos perfiles definidos solamente por una tecnología y más búsquedas que mezclen ingeniería, producto y negocio. No estoy seguro de que en un año desaparezcan las vacantes de desarrollador .NET, JavaScript o PHP. Las empresas y sus títulos cambian más lento que las herramientas.
Pero el trabajo detrás de esas vacantes sí está cambiando.
Una empresa puede seguir publicando una posición para desarrollador .NET, aunque espere que esa persona use IA, converse con usuarios, entienda el despliegue, mire métricas y participe en decisiones que antes pertenecían a otras funciones. El nombre será el mismo durante un tiempo. La expectativa no.
También seguirán existiendo especialistas. No todo producto necesita el mismo nivel de amplitud y no todo sistema permite que una sola persona recorra el ciclo completo. En organizaciones grandes habrá equipos de plataforma, seguridad, datos y confiabilidad. La ingeniería de producto no elimina esas disciplinas; evita que el producto se pierda entre ellas.
El riesgo está en el otro extremo: convertir “ingeniero de producto” en una forma elegante de pedir que una persona haga cinco trabajos. Si el cambio solo sirve para reducir equipo y acumular responsabilidades, no estamos creando un perfil mejor. Estamos creando agotamiento.
La idea tiene sentido cuando la IA y la plataforma reducen de verdad la carga mecánica, el equipo conserva apoyo especializado y la persona gana capacidad para tomar decisiones. Sin eso, el título es solo marketing para una vacante.
Ya no quiero definirme por la herramienta
Sigo siendo desarrollador .NET. Sigo trabajando con DevOps. Esa experiencia no desaparece ni pierde valor.
Lo que cambia es dónde pongo la identidad profesional. .NET es una capacidad. DevOps me enseñó a llevar una solución hasta producción. La ingeniería de producto junta esa base técnica con la pregunta que siempre debió estar primero: ¿qué problema estamos resolviendo y cómo sabemos que lo resolvimos?
La IA hará más corta una parte importante del camino. Nos ayudará con código, infraestructura, pruebas, análisis y operación. No creo que eso reduzca el trabajo a escribir prompts. Al contrario, nos obliga a ampliar el campo de visión.
El perfil que gana valor no es el que compite con la IA para producir más artefactos. Es el que entiende al usuario, usa la tecnología disponible, conecta las piezas y se responsabiliza por el resultado.
Para mí, DevOps no desaparece. Se integra. Y el lugar donde termina integrándose es la ingeniería de producto.
Si quieres seguir aprendiendo sobre estos temas te invito a ver mis otras publicaciones.
