Qué no puede construir un builder con IA: los límites reales
Qué no puede construir un builder con IA
Un builder con IA no falla en lo difícil, falla en lo que exige infraestructura propia. Quedan fuera las apps nativas de móvil, los juegos 3D y el multijugador en tiempo real, los sistemas regulados con auditoría y las integraciones con software que no tiene conector. Zugo construye sitios, aplicaciones web y juegos 2D de navegador.
La frontera no es una cuestión de tamaño ni de ambición del proyecto. Es una cuestión de qué se puede expresar como una página de navegador apoyada en servicios externos, y qué necesita algo distinto por debajo.
¿Dónde está la frontera de verdad?
Pasa por el navegador. Todo lo que Zugo genera se ejecuta ahí: marcado, estilos y comportamiento, con base de datos, pagos y correo delegados a servicios que ya existen. Mientras tu proyecto quepa en esa forma, la generación funciona; en cuanto necesita salir de ella, la herramienta deja de ser la adecuada.
Eso descarta cosas concretas y no descarta la complejidad. Un panel interno con roles, datos propios y varias pantallas cabe perfectamente. Una aplicación que necesita leer sensores del teléfono, o correr sin conexión durante días, no cabe, por sencilla que parezca su interfaz.
La segunda frontera es el catálogo de conectores. Supabase cubre base de datos, acceso y archivos. Stripe cubre pagos y suscripciones. Resend cubre el correo. GitHub exporta el código, Vercel despliega en tu cuenta y Google Analytics mide el tráfico. Lo que no está en esa lista se genera dentro de la página o no existe.
¿Qué queda claramente fuera?
Conviene tener la lista delante antes de empezar, porque descubrirla a mitad del proyecto es lo que hace perder una semana.
| Lo que quieres | Situación | Por qué |
|---|---|---|
| App nativa para App Store o Google Play | Fuera | La salida es web, no un paquete de tienda |
| Juego 3D o multijugador en tiempo real | Fuera | Los juegos son 2D y de navegador |
| Sistema con auditoría y certificación sectorial | Fuera | El cumplimiento no es una función que se genere |
| Conexión con un ERP o software propietario | Fuera del catálogo | No hay conector, y hacerlo a medida es desarrollo |
| Envío de mensajes al móvil | Fuera del catálogo | La mensajería no está entre los conectores |
| Panel interno con roles y datos propios | Dentro | Supabase cubre datos, acceso y archivos |
| Tienda que cobra de verdad | Dentro | Stripe cubre pagos y suscripciones |
| Juego 2D de navegador | Dentro | Es un camino nativo, con 5 plantillas de juego |
La columna del medio importa más que la de la izquierda. Fuera del catálogo no significa imposible: significa que sale del proyecto generado, se exporta a GitHub y lo continúa alguien con las herramientas habituales. Cómo funciona esa salida está en exportar el código.
¿Por qué un prompt mejor escrito no cambia el resultado?
Porque el límite no está en la comprensión, está en la superficie. Describir con precisión una aplicación nativa no convierte la salida web en un paquete instalable, igual que describir con precisión un plato no lo cocina. La instrucción se entiende y sigue sin haber dónde ejecutarla.
Esto se confunde a menudo con otra cosa distinta, que sí mejora escribiendo mejor: la lógica de negocio muy específica. Reglas de descuento con excepciones, cálculos con casos particulares o flujos de aprobación con varios estados sí salen, pero llegan con ediciones sucesivas, no con un solo mensaje bien redactado.
La diferencia práctica es que en el primer caso conviene cambiar de herramienta y en el segundo conviene presupuestar créditos. Un flujo con muchas reglas puede costar seis o siete ediciones, a 3 créditos cada una, y saberlo antes evita la sensación de que algo va mal cuando en realidad va según lo previsto.
¿Qué pasa con los juegos?
Los juegos son un camino nativo, con 5 plantillas de juego dentro de un catálogo de 25. Salen puzles, plataformas, arcade de conducción, disparos con vista cenital y emparejar piezas, todo en dos dimensiones y ejecutándose en el navegador.
Fuera quedan tres cosas que la gente pide a menudo. El 3D, porque la salida no es un motor tridimensional. El multijugador en tiempo real, porque necesita servidores de estado compartido que no forman parte del producto. Y la publicación en tiendas de móvil, porque un juego de navegador es una dirección web, no un paquete firmado.
Eso deja un espacio amplio y honesto: juegos para una campaña, para un evento, para enseñar algo o para acompañar a un producto. Lo que cabe y lo que no se detalla en si la IA puede crear un juego.
¿Qué sale, pero no de una sola vez?
Hay una zona intermedia que decide la experiencia de mucha gente, y casi nadie la explica antes de tiempo.
Interfaces con muchos estados. Un panel con filtros combinados, vistas guardadas y permisos por rol es alcanzable, y llega en capas. Se pide el esqueleto, se prueba, se piden los estados que faltan.
Reglas de negocio con excepciones. Tarifas por tramos, festivos, cupos y anulaciones se describen mejor una por una que todas juntas. Un mensaje enorme produce un resultado que hay que deshacer.
Migraciones de contenido. Traer cientos de fichas desde otro sitio es trabajo de datos, no de generación, y conviene resolverlo antes de construir la página que las muestra.
Trabajo fino de accesibilidad y rendimiento. Sale bastante por defecto y el ajuste último es artesanía, con medición y varias pasadas.
En estos cuatro casos la herramienta no está fallando, está haciendo lo que hace: avanzar por pasos. La comprobación en el entorno aislado se ocupa de que cada paso se entregue funcionando, no de que el primer intento sea el definitivo.
¿Cómo saber de antemano en qué lado cae tu proyecto?
Con tres preguntas, en este orden.
La primera: ¿puede vivir en una dirección web que se abre en el navegador? Si la respuesta obliga a hablar de instalación, notificaciones del sistema o funcionamiento sin conexión, ya estás fuera y es mejor saberlo ahora.
La segunda: ¿los servicios que necesita están en el catálogo de conectores? Base de datos, acceso, archivos, pagos, correo, despliegue y analítica están cubiertos. Si tu proyecto depende de un sistema interno de la empresa, esa pieza es desarrollo.
La tercera: ¿las reglas particulares se pueden enumerar? Si puedes escribirlas en una lista, saldrán con ediciones. Si nadie en tu equipo sabe enunciarlas del todo, ningún generador va a adivinarlas, y eso es un problema de especificación, no de herramienta.
¿Qué haces cuando el proyecto cruza el límite?
Lo mismo que harías con cualquier prototipo que funcionó: llevártelo. La exportación a GitHub deja un repositorio real, y el conector de Vercel despliega en tu propia cuenta, así que continuar no significa reconstruir desde capturas de pantalla.
A partir de ahí entra gente. Zugo no sustituye a un equipo de desarrollo en un producto complejo, y en el punto donde tu proyecto lo necesita, tener ya una versión que funciona y que se puede enseñar vale más que un documento de requisitos. Cómo es esa transición está en contratar a un desarrollador después.
También es válido quedarse a este lado de la frontera a propósito. Muchos proyectos no necesitan cruzarla nunca: una landing, una tienda pequeña, un panel interno o un juego de campaña viven perfectamente en lo que un builder genera, y gastar en desarrollo a medida sería pagar por capacidad que no se usa.
La forma de averiguarlo es barata. Describe tu proyecto tal cual en zugo.dev, sin simplificarlo para que quepa, y mira dónde se rompe. El punto exacto donde el resultado deja de parecerse a lo que pediste es tu frontera real, y saberla con precisión vale más que cualquier lista general, incluida esta.