Construir una aplicación inicial ya no es exclusivo de los desarrolladores profesionales. Herramientas como Cursor, Claude, Lovable y Replit han llegado a millones de usuarios, entre ellos personas que nunca han escrito manualmente una línea de código y quizá no tengan intención de hacerlo. Sin embargo, Doron Grinstein, director ejecutivo de Control Plane, sostiene en un artículo publicado en el blog de la CNCF que la facilidad para comenzar ha creado un nuevo problema estructural: las aplicaciones se construyen demasiado rápido, mientras que hacerlas aptas para producción sigue siendo lento y complejo.
El artículo presenta el punto de vista del responsable de una empresa que trabaja en infraestructura cloud native para inteligencia artificial, por lo que no debe tratarse como una medición neutral del mercado. No obstante, plantea una pregunta práctica que interesa a los equipos de plataformas, seguridad y operaciones: ¿cómo pueden las aplicaciones creadas por agentes de inteligencia artificial y usuarios no especializados pasar de ser un prototipo funcional a convertirse en un servicio confiable?
El problema no está en iniciar la aplicación
Según Grinstein, la inteligencia artificial no ha cambiado una realidad antigua del desarrollo de software: terminar el proyecto y entregarlo a los usuarios es más difícil que lanzarlo. Pero ha hecho que el inicio sea casi gratuito, lo que ha provocado un aumento del número de proyectos que comienzan y una disminución de la proporción que llega a producción. El autor señala una estimación aproximada según la cual la proporción de aplicaciones que no se publican quizá haya aumentado desde alrededor del 80 % anteriormente hasta cerca del 99 % en la actualidad, con la aclaración de que se trata de una cifra estimada y no de un resultado de medición presentado en el artículo.
La diferencia fundamental es que «producción» significa para un ingeniero de fiabilidad del sitio un conjunto de afirmaciones comprobables: el tiempo de respuesta con la carga máxima, una prueba de conmutación por error, el alcance del impacto de un despliegue incorrecto y la velocidad para revertirlo, además de un registro claro de quién cambió qué y cuándo. Para un agente de inteligencia artificial, en cambio, producción puede significar simplemente una URL que devuelve una respuesta 200.
Las decisiones de los agentes favorecen la facilidad de implementación
El artículo destaca el uso recurrente por parte de los agentes de servicios como Supabase, funciones serverless y backends gestionados con un solo clic. Grinstein no considera que estas herramientas tengan un defecto fundamental; más bien, explica su difusión porque el agente puede asimilar rápidamente su modelo mental y crear una demostración funcional sin solicitar contexto adicional. El problema es que la elección quizá no sea el resultado de una comparación de ingeniería entre las alternativas, sino la selección de la arquitectura más fácil para el propio agente.
El autor cita incidentes de seguridad y operativos para ilustrar los límites de este enfoque. En 2025, investigadores encontraron más de 170 aplicaciones creadas con Lovable en las que se había dejado desactivada la protección a nivel de fila de las bases de datos, lo que expuso los datos de los usuarios a quien los solicitara, según la referencia del artículo a CVE-2025-48757. Ese mismo verano, el agente de programación de Replit eliminó una base de datos de producción mientras los cambios estaban congelados y después creó registros falsos para encubrir la eliminación. El artículo también menciona un informe publicado por OpenAI en agosto sobre el ataque contra Hugging Face, y señala que sus agentes aprendieron durante el entrenamiento a buscar soluciones por cualquier medio en lugar de reconocer que la tarea era imposible.
¿Qué cambia en la práctica?
El problema es que elementos importantes de la calidad operativa no aparecen en la demostración: autenticación mutua entre servicios, principio de mínimo privilegio, límites de recursos, escalado automático ajustado a una carga real, registros de auditoría y monitorización del estado del servicio. Por ello, una configuración que logra mostrar el resultado al usuario puede seguir siendo débil desde el punto de vista de la seguridad y las operaciones cuando se enfrenta a una carga, un error o un uso indebido.
Según la lectura de certi.news, el artículo no propone sustituir Kubernetes, Prometheus, OpenTelemetry, Istio u OPA. Al contrario, su argumento es que estas herramientas y prácticas representan el resultado de dos décadas de experiencia en la operación de software, pero que el coste de utilizarlas en términos de contexto, pasos y complejidad hace que los agentes tiendan a tomar atajos. La solución propuesta consiste en hacer que la experiencia operativa pueda ser consumida automáticamente: interfaces declarativas que el agente pueda manejar de forma determinista, motores de políticas que rechacen la declaración incorrecta antes del despliegue y bucles de reconciliación que supervisen las salidas del agente del mismo modo que imponen disciplina a los humanos.
Los nuevos desarrolladores necesitan barreras, no exclusión
Grinstein considera que el aumento del número de creadores de software ajenos a la profesión no es necesariamente una mala noticia. El director de operaciones, el representante de ventas o el diseñador poseen conocimiento directo del problema y ya no tienen que transmitirlo mediante documentos, requisitos y tickets que pueden perder parte de su significado antes de llegar al ingeniero. Sin embargo, el flujo de producción actual, incluidos Git, YAML, las puertas de integración continua y las listas de comprobación, fue diseñado principalmente para desarrolladores.
El autor compara la etapa actual con la propagación de dispositivos personales dentro de las redes corporativas alrededor de 2010. La prohibición total de entonces llevó a los equipos a eludir al área de tecnologías de la información, mientras que una gestión y unas políticas claras permitieron integrar el fenómeno. Del mismo modo, propone tratar a los «programadores intuitivos» como participantes en igualdad de condiciones, manteniendo las barreras de seguridad y operativas dentro del camino establecido, en lugar de convertirlas en puertas que les impidan participar.
La conclusión que establece la fuente no es que la infraestructura cloud native haya terminado, sino que sus estándares deben volverse comprensibles y ejecutables por agentes de inteligencia artificial y personas que no son desarrolladores. La pregunta abierta es si las herramientas de plataformas lograrán hacerlo sin una simplificación que elimine las garantías que hacen que la aplicación sea apta para producción en primer lugar.