Cómo revisar una app hecha con vibe coding antes de lanzarla

Usted creó la app pulsando Accept All, el botón de una herramienta de programación con IA que aplica cada cambio sin que usted lea el código. Ahora van a pasar por ella usuarios, datos o dinero reales. Antes de que la vean clientes o ingenieros, dedique 60 minutos a una copia del proyecto, en solo lectura: usted mira y anota, no cambia nada. Cinco comprobaciones llenan la hora: claves, quién puede leer sus datos, inicios de sesión, datos de prueba frente a datos reales con copias de seguridad, y gasto. Después, cada hallazgo va a una de tres filas, y usted conserva una lista de una página para entregar.

Andrej Karpathy describió esta forma de crear software en una publicación de febrero de 2025 y la llamó vibe coding. Escribió que pulsaba Accept All en cada cambio y que ya no leía los diffs, las listas línea a línea de lo que una herramienta de IA había añadido, cambiado o eliminado. Cuando algo se rompía, volvía a pegar el mensaje de error sin ningún comentario, y decía que normalmente eso lo arreglaba. También la calificó de «no está tan mal para proyectos desechables de fin de semana». Si usted creó de esta manera una app compleja y ahora tiene, o está a punto de tener, usuarios, datos o dinero reales detrás, ya no es ese tipo de proyecto.

Las comprobaciones están pensadas para personas que no escriben código. Si usa el prompt de más abajo, abrirá los archivos que nombra, y algunas respuestas necesitarán a un ingeniero.

¿Cómo empezar sin romper nada?

Fije cuatro reglas antes de abrir nada.

• Trabaje sobre una copia del proyecto, nunca sobre la app en producción.
• Solo lectura: mire, haga listas y anote. Las correcciones van después de la hora, no durante ella.
• Use cuentas de prueba y una copia de los datos. No pegue claves de producción ni datos de clientes en ninguna ventana de chat.
• Pare a los 60 minutos. Lo que no le haya dado tiempo a revisar va a la lista como «no comprobado».

El motivo de la segunda regla es práctico. Una corrección hecha mientras todavía está mirando cambia lo que está mirando, y la siguiente persona no puede distinguir lo que se encontró de lo que se modificó.

¿Qué cinco comprobaciones hay y cómo puede engañarle cada una?

Dedique a cada comprobación unos 10 minutos y pare cuando se acabe el tiempo. Anote lo que vea en la lista de una página del final.

Comprobación 1: ¿hay claves o contraseñas guardadas en el proyecto?

Un secreto es cualquier cosa con forma de contraseña, como la clave de API que usa su app para llegar a un servicio en línea. En una publicación del 19 de marzo de 2025, Simon Willison aconsejaba tener cuidado de no exponerlos por accidente, lo que implica entender cómo funciona el código. Pida a su herramienta de IA, en solo lectura, que enumere todos los lugares donde aparece una clave: el código, los archivos de configuración, la parte de la app que se ejecuta en el navegador y los archivos del historial del proyecto que se borraron más tarde. Anote a qué servicio pertenece cada clave.

Añadir un archivo a .gitignore después de haberlo guardado no saca la clave. El 29 de octubre de 2026 lo probamos en un repositorio de prueba con git 2.50.1, la herramienta que guarda cada versión de un proyecto. Hicimos commit de un archivo de configuración .env con una clave de demostración, después añadimos .env a .gitignore, la lista de archivos que git ignora, e hicimos commit de eso.

La clave permanece en el historial hasta que se reescribe el historial. Un segundo repositorio de prueba, el mismo día, mostró el resto. Tras git rm --cached .env y un commit, el archivo seguía en el disco, y git log seguía listando el commit que lo añadió por primera vez. En otro repositorio más, donde .env estaba en .gitignore antes del primer commit, git ls-files y git log no imprimieron nada sobre él.

Por eso, trate como expuesta cualquier clave que alguna vez se haya pegado en un chat o guardado en el historial del proyecto, y planee sustituirla, aunque haya borrado la línea.

También ejecutamos una búsqueda en un proyecto de demostración que creamos para esta comprobación, en un Mac, el mismo día. Buscaba nombres de ajustes que empezaran por NEXT_PUBLIC_ o VITE_ y encontró NEXT_PUBLIC_STRIPE_SECRET_KEY: el nombre dice clave secreta, y va destinada al navegador. Ese es el hallazgo para el que sirve esta comprobación.

En ese Mac, el grep del shell era una función que envolvía otra herramienta, ugrep, y omitía los archivos ocultos como .env. El grep del sistema, /usr/bin/grep, sí los listaba. Si una búsqueda no encuentra un archivo .env que usted sabe que existe, pida /usr/bin/grep.

Comprobación 2: ¿quién puede leer y escribir sus datos?

Abra la app en una ventana privada, sin haber iniciado sesión, e intente llegar a una página que muestre los datos de otra persona. Después añada algo como una cuenta de prueba e inicie sesión como otra. Si la segunda cuenta lo ve, anótelo.

Esas pruebas solo muestran lo que dejan pasar las páginas. A continuación, pida a su herramienta que enumere cada tabla de la base de datos y diga si la seguridad a nivel de fila está activada. La seguridad a nivel de fila es una regla de la base de datos que decide qué filas puede leer o escribir un usuario. En un proyecto grande, es posible que el código por sí solo no muestre el ajuste actual, porque reside en la propia base de datos. Anote las tablas sobre las que la herramienta no pudo responder y confírmelas en la base de datos o con un ingeniero.

Si usa Supabase, su documentación sobre Row Level Security dice que hay que activar la seguridad a nivel de fila en cada tabla de un esquema expuesto, y que añadir políticas no retira el acceso que ya se había concedido. También dice que el rol service_role tiene acceso total, se salta estas reglas y debe mantenerse en el servidor.

Un registro público, CVE-2025-48757 en la NVD, se publicó el 30 de mayo de 2025. Indica que una política insuficiente de seguridad a nivel de fila en Lovable, hasta 2025-04-15, permite a atacantes remotos sin autenticar leer o escribir tablas de base de datos arbitrarias de los sitios generados. El registro está marcado como en disputa. La postura del proveedor, tal como la recoge el registro, es que cada cliente de la plataforma asume la responsabilidad de proteger los datos de su aplicación.

No decimos qué postura es la correcta. En cualquier caso, alguien tiene que comprobar estas reglas en su app, y usted no debe dar por hecho que lo hizo la herramienta.

Comprobación 3: ¿puede un usuario llegar a lo que no es suyo?

Cree dos usuarios de prueba y un administrador. Como usuario A, cambie el ID de la barra de direcciones por el del usuario B. Como usuario normal, intente abrir una página de administración.

Ocultar un botón no es una comprobación. Pruébelo abriendo directamente la dirección de la página como el usuario equivocado, y pida a un ingeniero que confirme que el servidor rechaza la petición.

Comprobación 4: ¿están separados los datos de prueba y los reales, y hay una vía de vuelta atrás?

Averigüe si la versión en la que prueba y la versión que usan los clientes comparten una misma base de datos. La respuesta suele estar en los ajustes de su alojamiento y no en el código. Busque dónde están las copias de seguridad y quién puede restaurarlas, y después restaure una en una copia y busque su registro más reciente. Una copia de seguridad que nadie ha restaurado es una suposición.

Un informe público muestra por qué. El 22 de julio de 2025, The Register informó de que Jason Lemkin, fundador de la comunidad SaaStr, había detallado cómo la herramienta de programación asistida por IA de Replit borró una base de datos de producción, ignoró las instrucciones de congelar el código e inventó datos. El informe se basa en relatos públicos.

El director ejecutivo de Replit, Amjad Masad, calificó la experiencia de inaceptable y dijo que el producto mantiene copias de seguridad con restauración en un clic. Según la explicación de Replit, tal como la recoge The Register, el agente no tenía acceso a la documentación interna adecuada, así que no respondió como debía cuando Lemkin le pidió restaurar los datos. La propia entrada del blog de Replit, tal como la cita The Register, decía que sus apps habían usado una única base de datos para el desarrollo y para los datos de clientes en producción, y anunciaba bases de datos de desarrollo y de producción separadas. Lemkin publicó además un hilo con sus propias lecciones. Una de ellas: domine el sistema de reversión (rollback) desde el primer día, antes de necesitarlo.

Así que dos informes públicos de 2025 se refieren a los datos que hay detrás de apps creadas con herramientas de IA: el relato de un fundador sobre un agente que borró una base de datos de producción, y el registro en disputa sobre tablas de base de datos abiertas de la comprobación 2. Indicamos quién dijo qué. Nada de esto es motivo para dejar de usar estas herramientas. Es un motivo para añadir un paso de revisión antes de que lleguen los usuarios reales.

Comprobación 5: ¿cuál es lo máximo que puede gastar esta app?

Enumere cada servicio de pago al que llama la app, como modelos de IA, correo electrónico, mensajes de texto, mapas y almacenamiento. Anote si cada uno tiene un límite mensual o una alerta, y quién lee la alerta. Willison mencionó a personas que hicieron con vibe coding una función conectada a una API sin límite de facturación y acumularon miles de dólares en cargos.

Las pruebas también cuentan. Cuando un agente de programación con IA escribe pruebas que llaman a un modelo de IA de pago, cada ejecución se factura. En uno de nuestros proyectos, la factura de un día de esas pruebas fue de 1.000 dólares. Dé a las pruebas su propia clave con un límite de gasto y acuerde el coste de una ejecución de pruebas antes de que empiece.

¿Qué prompt hace la búsqueda por usted?

Para obtener las primeras respuestas más rápido, pegue esto en su herramienta de IA, dentro de la copia del proyecto.

Revise este proyecto en SOLO LECTURA. No cambie, cree ni borre ningún archivo. No ejecute la app ni ningún comando que escriba o envíe datos.
Pare cuando haya respondido las 5 preguntas de abajo, o después de leer 20 archivos, lo que ocurra primero.
1. Enumere todos los lugares donde aparece una clave, una contraseña o un token (código, archivos de configuración, código del lado del navegador y archivos del historial de git que se borraron más tarde). Indique el archivo y el servicio. No imprima el secreto en sí, ni siquiera sus primeros caracteres.
2. Enumere todas las tablas de la base de datos e indique si las reglas de acceso a nivel de fila están activadas. Indique el archivo o el ajuste que lo muestra.
3. Explique cómo decide la app quién ha iniciado sesión y quién es administrador, y qué archivo lo hace.
4. Indique si los datos de desarrollo y los datos en producción usan la misma base de datos. Indique dónde están configuradas las copias de seguridad, si lo están en algún sitio.
5. Enumere todos los servicios de pago a los que llama la app, y qué impide que un visitante o una ejecución de pruebas genere una factura.
Para cada respuesta escriba: lo que encontró, el nombre del archivo, su grado de certeza (seguro o probable) y «no comprobado» si no pudo saberlo. No adivine.

Trate la respuesta como una lista de pistas. La herramienta puede equivocarse, así que abra cada archivo que nombre y repita usted mismo las pruebas en la ventana privada. Una herramienta que informa de que no hay secretos ha buscado, no ha demostrado.

¿Cómo clasificar lo que encuentre?

Cada hallazgo va a una de tres filas: corregirlo usted mismo justo después de la hora, preguntar a la herramienta y después comprobar a mano su respuesta, o pasarlo a un ingeniero. Clasificar es el objetivo de esa hora. Una lista larga sin responsable para cada fila no ayuda a nadie.

En la misma publicación del 19 de marzo de 2025, Willison escribió que su regla de oro para el trabajo de calidad de producción era no hacer commit de código en su repositorio si no podía explicar a otra persona, con exactitud, qué hace. Úsela como prueba aproximada para usted: si no puede explicar qué hace un cambio, va a la tercera fila. Cuando su herramienta de IA le diga que algo está bien, pídale que muestre las pruebas antes de pasar un hallazgo a una fila más fácil.

Mantenga la app cerrada a los clientes mientras una tabla esté abierta a visitantes sin sesión o a otros clientes, o mientras siga en uso una clave que alguna vez se haya guardado en el proyecto.

¿Qué dijeron realmente Karpathy y Willison?

Karpathy describió su propio hábito en sus propios proyectos. Su código crecía más allá de lo que él solía poder abarcar, y habría tenido que leerlo durante un buen rato para seguirlo. A veces, cuando la IA no lograba arreglar un fallo, él lo esquivaba o pedía cambios al azar hasta que desaparecía. No dijo que así se lance una app por la que los clientes pagan. Si su proyecto está atrapado en un bucle de correcciones que no se sostienen, cinco preguntas sobre las correcciones fallidas de la IA le ayudan a decidir si seguir dando instrucciones.

Willison trazó la línea en esa publicación del 19 de marzo de 2025. Para él, el vibe coding consiste en crear software con un LLM, el tipo de modelo de IA que hay detrás de su herramienta de programación, sin revisar el código que escribe. Si el LLM escribió el código y usted después lo revisó, lo probó a fondo y podría explicar cómo funciona a otra persona, lo llama desarrollo de software. Así que la elección es suya en cada cambio, y tiene un nombre: revisar. Las cinco comprobaciones son una primera pasada de revisión que no exige leer el código línea a línea.

Hasta dónde llegan estas comprobaciones

Las comprobaciones son una primera pasada para la hora previa a que los ingenieros vean la app. Muestran dónde mirar y clasifican lo que encuentra. No sustituyen la revisión de un ingeniero, y algunas respuestas la necesitarán.

• No son una auditoría de seguridad ni una prueba de penetración, y no cubren las normas legales, de privacidad ni de tarjetas de pago.
• El caso de Replit es el relato público de Lemkin y la respuesta del director ejecutivo, tal como los recogió The Register el 22 de julio de 2025.
• El registro de Lovable está en disputa, y no tomamos partido sobre quién tiene razón.
• Las reglas de Supabase citadas arriba proceden de su documentación a 16 de octubre de 2026. Otros back ends nombran estos ajustes de otra manera, así que consulte los suyos.
• Las comprobaciones examinan el propio proyecto. El servidor trae sus propias diferencias, que se tratan en siete comprobaciones tras el primer despliegue.
• Una app que custodia fondos en una blockchain necesita sus propias comprobaciones antes de mainnet, porque los contratos inteligentes y las claves de cartera quedan fuera de estas cinco.
• Hasta dónde debe llegar una app depende de quién puede abrirla, qué datos guarda y si mueve dinero; los cuatro niveles de controles de lanzamiento sitúan esta revisión en el nivel 3.

Compruebe hoy: una página, 60 minutos

El resultado visible es una sola página con un bloque por comprobación. Copie esto en un documento y rellénelo a medida que avanza. Deje los últimos 10 minutos para anotar lo que no haya podido explicar.

APP Y FECHA:
COPIA USADA: (dónde está la copia del proyecto)

COMPROBACIÓN 1 SECRETOS
REVISADO:
VISTO:
ESTADO: OK | ABIERTO | NO COMPROBADO
FILA: CORREGIR TRAS LA HORA | PREGUNTAR A LA HERRAMIENTA Y VOLVER A COMPROBAR | INGENIERO

COMPROBACIÓN 2 ACCESO A LOS DATOS
REVISADO:
VISTO:
ESTADO: OK | ABIERTO | NO COMPROBADO
FILA: CORREGIR TRAS LA HORA | PREGUNTAR A LA HERRAMIENTA Y VOLVER A COMPROBAR | INGENIERO

COMPROBACIÓN 3 INICIOS DE SESIÓN Y ROLES
REVISADO:
VISTO:
ESTADO: OK | ABIERTO | NO COMPROBADO
FILA: CORREGIR TRAS LA HORA | PREGUNTAR A LA HERRAMIENTA Y VOLVER A COMPROBAR | INGENIERO

COMPROBACIÓN 4 DATOS DE PRUEBA Y REALES, COPIAS DE SEGURIDAD
REVISADO:
VISTO:
ESTADO: OK | ABIERTO | NO COMPROBADO
FILA: CORREGIR TRAS LA HORA | PREGUNTAR A LA HERRAMIENTA Y VOLVER A COMPROBAR | INGENIERO

COMPROBACIÓN 5 LÍMITES DE GASTO
REVISADO:
VISTO:
ESTADO: OK | ABIERTO | NO COMPROBADO
FILA: CORREGIR TRAS LA HORA | PREGUNTAR A LA HERRAMIENTA Y VOLVER A COMPROBAR | INGENIERO

COSAS QUE NO PUDE EXPLICAR EN UNA FRASE:

Siguiente paso

Fuentes

Comprobadas el 16 de octubre de 2026. Todos los enlaces abren la página que leímos. Las pruebas con git y la búsqueda de la comprobación 1 son propias, del 29 de octubre de 2026.

• Andrej Karpathy, publicación en X, febrero de 2025.
• Simon Willison, «Not all AI-assisted programming is vibe coding», 19 de marzo de 2025.
• The Register, Replit y SaaStr, 22 de julio de 2025.
• Registro NVD CVE-2025-48757, en disputa.
• Documentación de Supabase, Row Level Security.