Llevo treinta años viendo repetirse el mismo patrón en las organizaciones de ingeniería. Una práctica empieza como experimento en un puñado de empresas visionarias. Luego se convierte en algo que “las organizaciones serias están explorando”. Después, casi sin que nadie note el momento exacto en que sucedió, se vuelve la expectativa por defecto — y la pregunta deja de ser si hacerlo para convertirse en qué tan bien lo estás haciendo.
DevOps pasó por este arco. Los microservicios también. El CI/CD también.
Platform Engineering está ahora en la recta final de ese mismo arco — y los datos analíticos están confirmando lo que los mejores líderes de ingeniería ya intuían.
Los Números que Cerraron el Debate
La proyección de Gartner es la señal más clara: para finales de 2026, el 80% de las grandes organizaciones de ingeniería de software tendrán equipos de platform engineering dedicados — contra el 45% en 2022. Eso no es crecimiento incremental. Es una categoría que cruza de mayoría temprana a adopción casi universal en menos de cinco años.
La investigación de DORA lo respalda desde otro ángulo: las organizaciones con plataformas internas de desarrollo maduras superan consistentemente a sus pares en todas las métricas clave de entrega — frecuencia de despliegue, lead time, tasa de fallas en cambios y tiempo de recuperación. Ya no es correlación. El argumento causal es lo suficientemente sólido como para que “deberíamos considerar construir una plataforma” haya dejado de ser una posición defendible para cualquier organización de ingeniería mediana o grande.
El paralelismo con la maduración de DevOps es preciso. Durante años, la pregunta fue filosófica — ¿realmente deberían estar tan integrados el desarrollo y las operaciones? A mediados de los 2010, ese debate había terminado. La pregunta pasó a ser: ¿qué tan buena es tu práctica de DevOps? Platform Engineering está llegando al mismo punto de inflexión ahora mismo.
Qué Es Realmente un IDP (y Qué No Es)
El malentendido más común que veo es tratar una Internal Developer Platform como un portal. No lo es. Un portal — Backstage, Port, Cortex — es la puerta de entrada. El IDP es la casa.
El valor real de una plataforma está en la capa de abajo: golden paths estandarizados para aprovisionamiento, pipelines de CI/CD preconfigurados, guardrails automáticos de seguridad y compliance, templates de servicios, y acceso self-service a infraestructura — todo armado de manera que la forma segura y correcta de hacer algo sea también la más fácil. Cuando eso funciona, los desarrolladores dejan de quemar tiempo en trabajo de infraestructura no diferenciado y empiezan a entregar producto.
Backstage — construido originalmente en Spotify y ahora un proyecto de la CNCF — se ha consolidado como la capa de portal dominante, con aproximadamente el 89% del market share entre las organizaciones que adoptaron un IDP. Su arquitectura de plugins y su modelo de catálogo de software se convirtieron en el estándar de facto. Pero la elección del portal es secundaria. La plataforma que hay debajo es lo que determina si obtenés ganancias reales de productividad o simplemente una nueva superficie administrativa.
El Error que Cometen los que Llegan Tarde
Las organizaciones que recién están pensando en platform engineering en 2026 tienden a cometer un error de secuencia: construyen el portal primero. Es visible, parece progreso, y es fácil de demostrar ante el liderazgo. Pero un portal bonito encima de una capa de infraestructura fragmentada no reduce la fricción del desarrollador — agrega otra herramienta al stack.
Los equipos que más aprovechan sus IDPs empiezan desde el lado opuesto. Identifican las partes de mayor fricción en el flujo de trabajo del desarrollador — aprovisionamiento de entornos, aprobaciones de despliegue, revisiones de seguridad — y construyen caminos automatizados para eso primero. El portal viene después, cuando hay algo que vale la pena surfacear a través de él.
El otro error es tratar la plataforma como un proyecto de infraestructura en lugar de un producto. El equipo de plataforma tiene clientes internos: los desarrolladores que usan la plataforma todos los días. Los equipos que gestionan sus IDPs con mentalidad de producto — roadmaps, loops de feedback, métricas de adopción, medición de developer experience — superan consistentemente a los que lo tratan como una preocupación de mantenimiento de backend.
La Capa que Cambia Todo: AI Meets the IDP
Acá es donde la historia se pone interesante para los líderes de ingeniería que siguen el espacio de IA.
La Internal Developer Platform está convirtiéndose rápidamente en la capa de entrega a través de la cual el tooling de IA llega a los desarrolladores de manera gobernada y estandarizada. Las organizaciones con IDPs maduros están incorporando capacidades potenciadas por IA directamente en sus golden paths: selección inteligente de tests, scoring de riesgo en cambios, detección de anomalías, forecasting automatizado de costos al momento del despliegue.
Más significativamente, el Model Context Protocol está empezando a aparecer en la capa de plataforma. Los equipos están comenzando a exponer sus capacidades de plataforma — aprovisionamiento de infraestructura, consultas al catálogo de servicios, pipelines de despliegue — como servidores MCP. Esto significa que los desarrolladores pueden interactuar con la plataforma en lenguaje natural a través de sus asistentes de IA, en lugar de navegar una UI de portal. En lugar de hacer click en Backstage para aprovisionar un nuevo servicio, el desarrollador describe lo que necesita en Claude Code, y la plataforma se encarga del resto.
Esto no es ciencia ficción. Es uso en producción en etapa temprana en 2026. Y cambia el cálculo estratégico: las organizaciones con IDPs maduros están posicionadas para absorber los flujos de trabajo de desarrollo nativos de IA. Las organizaciones sin ellos van a encontrar que el tooling de IA agrega complejidad en lugar de eliminarla.
Qué Significa Esto si Estás Tomando Decisiones Ahora
Si liderás ingeniería en una organización mediana o grande y no tenés un equipo de plataforma, la pregunta ya no es si lo necesitás. La pregunta es cuál es tu camino.
La buena noticia es que la barra para un MVP útil es más baja de lo que la mayoría de los equipos asume. Ocho semanas para una primera plataforma interna funcional es alcanzable si el scope está bien definido: identificá el flujo de trabajo de mayor fricción para tus desarrolladores, construí un golden path para ese caso, medí la adopción. Empezá por ahí. No intentes hervir el océano el día uno.
La mala noticia es que las organizaciones que empezaron esto hace dos años ya tienen una ventaja compuesta. Sus desarrolladores gastan menos tiempo en infraestructura. Sus despliegues son más consistentes. Su postura de seguridad es mejor por diseño. Y están mejor posicionadas para absorber la ola de tooling de IA.
El paralelismo con DevOps es instructivo también en este punto. Las organizaciones que se movieron temprano en DevOps no solo obtuvieron ganancias de productividad — construyeron un músculo organizacional que hizo cada cambio subsiguiente más fácil de absorber. Platform Engineering es ese mismo tipo de inversión estructural.
El debate sobre si hacer esto terminó. La conversación ahora es sobre qué tan bien lo hacés, y qué tan rápido empezás.
¿Tu organización ya tiene un equipo de platform engineering? ¿Están construyendo un IDP propio o adoptando una solución existente como Backstage? Contame en los comentarios 