App hecha con vibe coding: qué pasa cuando llegan usuarios reales

Una app hecha con vibe coding es una app construida principalmente dándole prompts a una herramienta de IA y aceptando lo que genera. Puede verse terminada y aun así comportarse mal cuando desconocidos la usan, pagan por ella y la exigen de formas que nunca probaste.

Este artículo trata sobre lo que suele fallar cuando llegan usuarios reales, por qué el código se vuelve frágil y cómo decidir entre arreglar y reescribir. Soy un ingeniero sénior brasileño, y esto es lo que busco cuando leo estas bases de código.

¿Qué es una app hecha con vibe coding?

Es software en el que quien dirige la construcción es la persona que describe la funcionalidad, no un desarrollador que lee cada línea. Herramientas como Lovable, Bolt y Base44, a menudo combinadas con Supabase, producen un front-end funcional, una base de datos y algo de lógica a partir de prompts.

Eso es realmente útil para prototipos y validación temprana. El problema es que la herramienta optimiza para algo que funcione en el camino feliz. Nadie ha revisado los casos límite, los permisos ni los modos de falla, salvo que lo hayas hecho tú.

También ayuda saber quién es responsable de qué. El constructor protege su propia infraestructura y sus cuentas. Tú, como dueño de la app, eres responsable de quién puede leer qué datos, de las claves en el navegador, de confirmar los pagos y de los backups.

¿Qué suele fallar primero con usuarios reales?

En mi experiencia, rara vez es la interfaz. Cuatro revisiones cubren la mayor parte del riesgo antes de que lleguen los usuarios reales.

1. Reglas de acceso a datos

Las apps construidas con Lovable han mostrado un patrón de reglas débiles de row level security (RLS) en Supabase. Si las reglas faltan o son demasiado permisivas, un usuario con sesión iniciada puede llegar a leer o editar los registros de otro usuario con solo cambiar una solicitud. Funciona perfecto en tus propias pruebas, porque solo ves tus propios datos.

Un ejemplo público relacionado: en julio de 2025, investigadores de Wiz descubrieron que Base44, el constructor propiedad de Wix, permitía a un atacante registrarse en apps que debían ser privadas usando solo el ID de la app. Se corrigió en un día, pero muestra por qué el control de acceso merece tu propia atención.

2. Claves expuestas

Las claves secretas colocadas en el código del front-end son visibles para cualquiera que abra las herramientas del navegador. Todo lo que deba seguir siendo secreto pertenece a un servidor, no al bundle del cliente.

3. Confirmación de pagos

Un patrón común es confiar en la redirección del navegador después del checkout como prueba de pago. La fuente confiable es un webhook de Stripe verificado en tu servidor. Sin eso tienes pedidos pagados que nunca se activan, o pedidos activados que nunca se pagaron, y los eventos duplicados pueden crear pedidos duplicados.

4. Backups

Pregúntate si puedes restaurar tu base de datos al estado de ayer, y si alguna vez lo has intentado. Muchos fundadores descubren la respuesta durante un incidente.

El rendimiento es el quinto problema, más silencioso. Las consultas que traen todo y filtran en el navegador se sienten rápidas con diez filas y lentas con diez mil.

¿Por qué los cambios pequeños empiezan a romper otras funcionalidades?

Este es el síntoma que más describen los fundadores: le pides a la IA que ajuste una cosa y algo sin relación deja de funcionar. Normalmente hay algunas causas.

• Sin pruebas. Nada te avisa que un cambio rompió un flujo existente hasta que un usuario lo encuentra.
• Lógica duplicada. La misma regla, como un cálculo de precio, está copiada en varios componentes. Corriges una copia y las demás siguen mal.
• Archivos enredados. Los componentes grandes mezclan visualización, obtención de datos y reglas de negocio, así que cualquier edición toca las tres cosas.
• Pérdida de contexto. La IA ve solo una parte del proyecto cada vez, así que puede crear un nuevo helper en lugar de reutilizar el existente, o reescribir código sin saber que otras partes dependen de él.

Nada de esto significa que la herramienta sea mala. Significa que el código no tiene red de seguridad, y cada prompt es una apuesta sobre un sistema que nadie entiende por completo.

¿Debo arreglar la app hecha con vibe coding o reescribirla?

Empieza por la regla que sigo: el código generado por IA es un primer borrador. Vale la pena editar un borrador antes de tirarlo. Corregir los problemas de mayor riesgo en el código existente va antes de cualquier reescritura.

Una reescritura tira a la basura comportamientos que ya funcionan, incluidas pequeñas decisiones que olvidaste y de las que dependen los usuarios. Además tarda más de lo que parece y retrasa todo lo demás.

Quedarse en el constructor a veces es la decisión correcta, sobre todo mientras todavía estás probando la demanda y no manejas datos sensibles ni pagos. Sal cuando necesites control, no por una sensación vaga de que los productos de verdad viven en otro lugar.

También he visto el caso a mayor escala. Lideré la migración completa de una plataforma en vivo de postulación automática a empleos, de un stack legado a uno nuevo, mientras los usuarios la seguían usando. La lección que me dejó es evitar detener todo para reconstruir. El mismo razonamiento incremental aplica a una app hecha con vibe coding.

¿Cómo hago que un desarrollador pueda mantener el código?

El objetivo es que un ingeniero nuevo pueda abrir el repositorio, ejecutarlo y cambiarlo sin miedo. Un orden práctico:

1. Mueve el código a GitHub. El código construido en Lovable se puede mover a GitHub y a tu propio hosting, lo que te da historial, ramas y propiedad.
2. Separa los entornos. Mantén desarrollo y producción separados, con los secretos en variables de entorno, nunca en el repositorio.
3. Corrige los cuatro riesgos. Ajusta las reglas de datos, pasa los secretos al servidor, confirma los pagos mediante webhooks verificados y configura backups probados.
4. Agrega pruebas donde viven el dinero y los permisos. Primero checkout, registro y control de acceso. No persigas la cobertura total.
5. Consolida la lógica duplicada. Pon las reglas de negocio en un solo lugar y reutilízalas.
6. Escribe un README corto. Cómo ejecutarla, dónde está desplegada, qué hace cada servicio.

Pedirle al constructor con IA que haga todo esto no basta por sí solo. Las reglas de datos, las claves y los flujos de pago son justo lo que estas herramientas tienden a hacer mal, y un escáner de seguridad genérico tampoco detecta lógica de negocio como el manejo de webhooks de Stripe y los pedidos duplicados. Una persona tiene que leer esos flujos.

¿Cuándo debe tomar el control un ingeniero humano?

Mi regla práctica, que es una estimación y no un límite estricto, es involucrar a un ingeniero antes de que ocurra cualquiera de estas cosas:

• Empiezas a cobrar dinero real.
• Almacenas datos personales o sensibles de personas reales.
• Cada corrección por prompt causa una nueva regresión.
• No puedes explicar dónde viven tus datos ni cómo restaurarlos.
• Un cliente o un inversionista pregunta por seguridad o due diligence.

La mayor parte del riesgo se encuentra con unas pocas revisiones enfocadas, no con una auditoría completa, y el costo de corregir crece una vez que los usuarios y los pagos están en producción. Una revisión corta y temprana suele ser más barata que un incidente después.

¿Quieres una segunda opinión sobre tu app?

Si tienes una app hecha con vibe coding a punto de recibir usuarios reales, escribe a me@filipeeduardo.dev con el enlace y una línea sobre lo que hace, y te diré qué revisaría primero.