Los gerentes de producto despliegan código con IA y redefinen organigramas de software

La inteligencia artificial no solo está cambiando la forma en que se crea elsoftware; está redefiniendo quién puede crearlo y, con ello, los cimientos de las organizaciones tecnológicas. Un fenómeno que, aunque iniciado en las trincheras de la ingeniería, ya ha traspasado las fronteras de los departamentos de producto y diseño, y cuyas implicaciones para la industria son profundas.

El punto de inflexión se alcanzó cuando el coste de implementación de una idea colapsó. La irrupción de agentes autónomos de IA asumió tareas repetitivas: el andamiaje del código, la generación de pruebas y ese «código de pega» que historically absorbía una porción sustancial de los ciclos de desarrollo. Los tiempos de entrega, que antes se medían en semanas, se comprimieron a días y, posteriormente, a horas. Este cambio-forzó a los ingenieros a evolucionar su rol, desplazando el foco desde la sintaxis y los archivos hacia la arquitectura de alto nivel, las restricciones del sistema y los planes de ejecución.

Sin embargo, un nuevo cuello de botella emergió con fuerza. Cuando la capacidad de ingeniería dejó de ser el factor limitante, la velocidad de decisión se convirtió en el verdadero freno. Todos los mecanismos de coordinación concebidos para proteger el tiempo de los técnicos —especificaciones exhaustivas, tickets detallados, reuniones de alineación, sesiones de priorización del backlog— se revelaron como los eslabones más lentos de la cadena. La organización había optimizado para una restricción que, literalmente, ya no existía.

Esto ha desencadenado un desplazamiento paradigmático: para una categoría significativa de tareas, resultaba más rápido construir directamente la solución que describirla con precisión para que otro la construyera. La barrera de entrada para «construir» se derrumbó.roles tradicionalmente alejados de la codificación, como los jefes de producto (PMs) y los diseñadores, encontraron que el coste de traducir su visión a software funcional había descendido hasta su nivel de competencia natural. No tuvieron que «aprender a programar»; la implementación se abarató hasta volverse accesible.

Un ejemplo ilustrativo procede de un equipo de producto. Un manager, durante los minutos de espera mientras un agente generaba tareas en su sistema de flujo de trabajo (Zenflow), tuvo una idea simple: un mini-juego interactivo para amenizar esa pausa. En el paradigma anterior, esta idea, por su falta de impacto en métricas clave (KPIs), habría sido enterrada en una hoja de cálculo de priorización, archivada como «no urgente» y luego olvidada. El coste de desarrollo la hacía irracional. Hoy, la construyó en un día.

Otro caso es el de un diseñador que, al identificar una deriva visual en los plugins de un IDE respecto al sistema de diseño establecido, optó por la vía directa. En lugar de capturar pantallas, abrir un ticket, redactar una explicación y esperar un hueco en el sprint, actuó. Modificó la interfaz a través de un agente, experimentó en tiempo real, iteró y desplegó la corrección. La persona con mayor intuición de diseño pudo ejercerla sin intermediarios, sin capas de traducción.

Este movimiento no es una anécdota aislada; es un efecto compuesto. Cuando los managers de producto construyen sus propias ideas, sus especificaciones se afilan de forma orgánica, pues comprenden de primera mano loque el agente necesita para ejecutar con precisión. Especificaciones más nítidas generan outputs de IA de mayor calidad, lo que reduce los ciclos de iteración. La curva de aprendizaje se vuelve más empinada y la velocidad de entrega se acelera semana tras semana, no solo por la mejora de los modelos, sino por la creciente familiaridad de los usuarios con el sistema.

Un segundo efecto, más difícil de cuantificar pero palpable, es el de la apropiación. El comportamiento «constructor» deja de ser una etiqueta de puesto y se convierte en el modo por defecto. Las personas dejan de esperar y de generar tickets para cosas que pueden arreglar ellas mismas. Se rompe la inercia del «no es mi trabajo».

Las implicaciones para el sector son vastas. El discurso del «todos pueden programar» del año pasado sonaba a utopía para equipos pequeños. La realidad que se está viviendo es en organizaciones complejas, con bases de código heredadas (brownfield), múltiples lenguajes y sistemas de producción en plena carga. No se trata de un experimento en un garaje, sino de la transformación de la operativa diaria en una empresa tecnológica madura.

El proceso es irreversible. Con cada nueva generación de modelos, la brecha entre quien puede construir y quien no se reduce a un ritmo que la mayoría de organizaciones aún no han dimensionado. Cada compañía de software está a punto de descubrir que sus managers de producto y diseñadores albergan una capacidad de construcción latente, bloqueada no por una falta de habilidad, sino por el coste histórico de implementación. A medida que ese coste se aproxima a cero, la arquitectura organizacional tradicional se vuelve anacrónica.

Lo que comenzó como una iniciativa para acelerar la ingeniería de software ha derivado en algo más profundo: la creación de organizaciones donde el acto de «lanzar» (shipping) está democratizado. El futuro ya no pertenece solo a quienes pueden escribir código, sino a quienes pueden definir intenciones con claridad. El organigrama, como lo conocíamos, se ha reconfigurado desde el interior.