Tu prototipo construido con IA funciona. ¿Está listo para usuarios reales?
¿Hiciste tu app con Lovable, Bolt o Cursor? Qué suele fallar en el código de IA, diez revisiones antes de lanzar y cuándo reconstruir en vez de corregir.
En esta página · 5 secciones
Puntos clave
- Los constructores de apps con IA producen prototipos convincentes rápido, pero en pruebas independientes cerca del 45% del código generado por IA contenía fallas de seguridad.
- Las brechas son predecibles: reglas de acceso a la base de datos, claves expuestas, confianza en la entrada del cliente, pagos y backups.
- Corrige el prototipo cuando su modelo de datos es sólido; reconstruye el núcleo y conserva la interfaz cuando no lo es.
Los constructores de apps con IA cambiaron lo que un fundador puede hacer solo. Con Lovable, Bolt, Replit o Cursor, puedes pasar de una idea a un producto funcional en un fin de semana, recorrerlo, mostrárselo a clientes e incluso cobrarles. Es una ventaja real, y deberías aprovecharla.
El problema es el paso siguiente. Un prototipo que funciona en una demo y un producto que guarda datos de usuarios reales son cosas distintas, y la diferencia es casi invisible hasta que algo sale mal. Este post cubre lo que el código generado por IA suele hacer mal, las diez revisiones que debes hacer antes del lanzamiento y cómo decidir entre corregir y reconstruir.
¿Qué tan seguro es el código generado por IA?
Menos de lo que parece. En el estudio de 2025 de Veracode sobre más de 100 modelos de lenguaje en 80 tareas de programación, el código generado por IA introdujo vulnerabilidades de seguridad en el 45% de los casos. Los modelos no protegieron contra cross-site scripting en el 86% de las tareas relevantes ni contra log injection en el 88%. Un seguimiento en marzo de 2026 encontró que la tasa de aprobación en seguridad seguía estancada en cerca del 55% (Veracode).
Las fallas no son teóricas. En 2025, un investigador divulgó la CVE-2025-48757: los proyectos generados con Lovable hasta el 15 de abril de 2025 podían salir a producción con reglas de acceso a la base de datos ausentes o insuficientes, lo que permitía a usuarios no autenticados leer datos personales, claves de API y registros de pagos directamente desde el navegador.
Nada de esto significa que las herramientas de IA sean malas. Significa que optimizan para “funciona cuando hago clic”, y la seguridad trata sobre todo de lo que pasa cuando alguien hace clic en cosas que tú no previste.
¿Qué suele romperse primero?
Las mismas cinco brechas aparecen en casi todas las apps construidas con IA, porque son invisibles en una demo:
- Reglas de acceso a la base de datos. Las apps construidas sobre Supabase o Firebase hablan con la base de datos directamente desde el navegador. Sin row level security o reglas estrictas, cualquier usuario con sesión iniciada, a veces cualquier visitante, puede leer o cambiar todas las filas.
- Secretos en el frontend. Las claves de API de servicios pagos o de acceso de administrador terminan en el bundle de JavaScript, donde cualquiera puede copiarlas.
- Confiar en el cliente. Los precios, roles y permisos que se deciden en el navegador se pueden editar en el navegador. Un usuario se vuelve administrador cambiando un solo campo.
- Pagos sin verificación. La app marca un pedido como pagado porque el frontend lo dijo, en lugar de confirmarlo con el webhook del proveedor de pagos.
- Sin backups ni monitoreo. Nadie se entera cuando algo falla, y no hay forma de volver atrás cuando se pierden datos.
Las 10 revisiones antes de tener usuarios reales
Puedes hacer la mayoría tú mismo en pocos minutos cada una. Si alguna falla, corrígela antes del lanzamiento:
| # | Revisión | Cómo probarla |
|---|---|---|
| 1 | Los usuarios solo ven sus propios datos | Inicia sesión como el usuario A, copia el ID de un registro del usuario B e intenta abrirlo |
| 2 | Las reglas de la base de datos están activas en todas las tablas | En Supabase, confirma que row level security está habilitado y tiene políticas en cada tabla |
| 3 | No hay claves secretas en el navegador | Busca en el JavaScript del sitio (herramientas de desarrollo del navegador) “key”, “secret” y “token” |
| 4 | Los roles se aplican en el servidor | Cambia tu rol en el almacenamiento del navegador o en la solicitud y mira si aparecen opciones nuevas |
| 5 | Los pagos se confirman por webhook | Verifica que los pedidos solo pasen a “pagado” después de que el proveedor de pagos llame a tu servidor |
| 6 | Las entradas se validan en el servidor | Envía formularios con valores vacíos, enormes o que parezcan scripts |
| 7 | Hay límites de intentos en el login y el registro | Prueba veinte contraseñas incorrectas seguidas |
| 8 | Los backups existen y se pueden restaurar | Restaura el backup de ayer en una base de datos separada |
| 9 | Los errores se registran | Provoca un error y confirma que alguien recibe una notificación |
| 10 | Eres dueño de todas las cuentas | Código, hosting, base de datos, dominio y cuentas de pago a nombre de tu empresa |
Si las cuatro primeras pasan, estás por delante de la mayoría de las apps construidas con IA. Si alguna de ellas falla, tienes un riesgo real de exposición de datos, no un problema de calidad de código.
¿Deberías corregir el prototipo o reconstruirlo?
Depende del modelo de datos, no de cómo se ve el código. El código generado por IA suele ser verboso y repetitivo; eso por sí solo no es razón para reconstruir.
Corrígelo cuando:
- Puedes explicar el modelo de datos en pocas frases, y coincide con cómo funciona el negocio.
- Los problemas son las revisiones de arriba: reglas faltantes, claves expuestas, confianza en el lado del cliente.
- Hay un puñado de hallazgos críticos, no decenas.
Reconstruye el núcleo cuando:
- Los mismos datos viven en varios lugares y nadie sabe qué copia es la verdadera.
- Cada cambio rompe algo que no tiene relación, y no hay pruebas que te digan qué.
- La seguridad depende de que el frontend se comporte, y arreglarlo implica reescribir la mayor parte del backend.
Aun así, rara vez necesitas tirar todo. El camino habitual es conservar la interfaz, en la que las herramientas de IA son buenas, y reconstruir bien el backend y la capa de datos detrás de ella.
¿Qué hace un ingeniero en las primeras dos semanas?
Endurecer una app construida con IA sigue el mismo orden que cualquier traspaso. Primero, asegura los accesos y las cuentas. Luego, haz que el build y el despliegue sean reproducibles. Después, mapea los flujos que manejan dinero y datos personales, y corrige primero las brechas de seguridad en esos flujos. Para un MVP típico construido con IA, la parte crítica cabe en unas dos semanas.
Preguntas frecuentes
¿Es seguro lanzar software hecho con vibe coding?
No sin revisión. En las pruebas de Veracode, cerca del 45% del código generado por IA contenía fallas de seguridad, y hay incidentes reales que han expuesto datos de usuarios de apps construidas con herramientas de IA. Un prototipo está bien para demos y entrevistas; antes de tener usuarios reales y pagos, revisa las reglas de acceso a la base de datos, los secretos, la validación en el servidor y los backups.
¿Puedo lanzar una app construida con Lovable o Bolt?
Sí, muchos fundadores lo hacen, pero trata el resultado como un primer borrador. Confirma que row level security está habilitado con políticas en todas las tablas, que ninguna clave secreta llega al navegador y que los pagos se verifican en el servidor. Esas tres revisiones cierran las brechas más comunes y más dañinas.
¿Cuánto cuesta dejar un prototipo hecho con IA listo para producción?
Para un MVP típico, una revisión de seguridad y las correcciones críticas le toman a un ingeniero sénior de una a dos semanas. Si hay que reconstruir el modelo de datos, cuenta con varias semanas más. La propia revisión te dice en qué caso estás, así que empieza por ahí antes de comprometerte con un presupuesto.