Crear una herramienta interna mediante agentes de programación se ha vuelto mucho más rápido, pero los datos del informe Future of Platform Engineering 2026 indican que la facilidad de construcción no implica necesariamente tener una visión clara. De los 379 especialistas en ingeniería de plataformas, los equipos que construían desde cero la mayoría de sus funcionalidades eran aproximadamente 3,5 veces más propensos a considerar la ausencia de una estrategia clara un obstáculo.
Este resultado no demuestra que construir desde cero sea una decisión equivocada, pero revela una relación entre la forma de proporcionar capacidades de la plataforma y el nivel de claridad de la dirección conforme a la cual trabajan los equipos.
Las herramientas listas para usar son la opción más común
El 51,3% de los participantes afirmó que utilizar una herramienta básica lista para usar era su enfoque principal para respaldar las funcionalidades de la plataforma, frente al 31,2% que dependía de plantillas existentes y el 17,5% que construía desde cero. La dependencia de herramientas era mayor entre los equipos clasificados como de alto rendimiento, con un 58,8%, frente al 47,8% de las plantillas y el 33,3% de la construcción desde cero.
Las excepciones aparecen en entornos directamente vinculados a una trayectoria técnica específica, como los entornos de desarrollo locales, los proyectos que se crean con un clic y los entornos temporales. En estos casos, las plantillas pueden ofrecer compatibilidad con las trayectorias aprobadas que las herramientas generales no proporcionan fácilmente.
Los entornos temporales son un indicador de madurez de la plataforma
Los equipos que proporcionaban entornos temporales eran más propensos a informar de un impacto positivo de la inteligencia artificial en la velocidad y la estabilidad de la entrega de software, así como en la cobertura del código y el control de costes. Entre los equipos que describieron el impacto como muy positivo, más de tres cuartas partes utilizaban entornos temporales.
Sin embargo, esta relación no significa necesariamente que el entorno temporal por sí solo haya causado la mejora. Los equipos que los proporcionan suelen trabajar dentro de plataformas más amplias que incluyen múltiples capacidades automatizadas, por lo que la amplitud y la madurez de la plataforma pueden ser factores más importantes para absorber el volumen de cambios que produce la inteligencia artificial sin sacrificar la estabilidad.
¿Por qué importa esta noticia?
El cambio práctico más importante es que la inteligencia artificial reduce el coste de escribir código, pero no elimina el coste de poseerlo. La herramienta que se construye rápidamente necesita mantenimiento, actualizaciones y gobernanza, y puede aumentar la carga operativa a medida que crece el volumen de cambios en la trayectoria de desarrollo.
Los datos respaldan esta distinción: el 57,9% de los equipos en los que predominaba la construcción desde cero afirmó que la ausencia de una estrategia clara era un obstáculo, frente al 15,6% de los equipos que dependían de plantillas y el 16,7% de los equipos que utilizaban herramientas básicas. Además, los equipos que construían desde cero utilizaban más la inteligencia artificial para actualizar sistemas antiguos y migrar lenguajes, lo que sugiere que parte de este uso se destina al mantenimiento de complejidades creadas por los propios equipos.
La cuestión no es solo construir o comprar
El análisis de costes y beneficios fue la razón más común para las decisiones de construir o comprar, con un 29,6%, seguido de la preferencia por el código abierto, con un 28,6%; la evaluación de la adecuación y los requisitos, con un 22,4%; la preferencia por herramientas comerciales, con un 22,4%; y la construcción para lograr una diferenciación fundamental, con un 16,3%.
El artículo plantea dos posibles interpretaciones entre las que los datos no permiten decidir: quizá la estrategia precede a la decisión de construir o comprar, o quizá la construcción se convierte en una alternativa temporal a una estrategia que aún no se ha definido. Pero la conclusión editorial más clara es que el problema no está en construir desde cero, sino en adoptarlo por defecto sin una razón concreta. Las capacidades únicas deben construirse en torno al contexto de la organización, mientras que las herramientas que resuelven problemas estándar de manera eficiente deben comprarse o adoptarse, teniendo en cuenta el coste del mantenimiento y de la dependencia a largo plazo.