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

En febrero de 2025, Andrej Karpathy describió una forma de crear software a la que llamó vibe coding. En su publicación escribió que pulsaba «Accept All» (aceptar todo) 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 «nada mal para proyectos desechables de fin de semana». Si usted creó una app compleja de esta manera y ahora tiene, o está a punto de tener, usuarios, datos o dinero reales detrás, ya no es ese tipo de proyecto.

A continuación encontrará 60 minutos de comprobaciones de solo lectura que conviene hacer antes de que los ingenieros vean la app, y una lista de una página para entregarles. 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.

El primer paso seguro: una copia, solo lectura, 60 minutos

Fije las 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ó.

Lo que dijo la publicación y lo que no dijo

Karpathy describió su propio hábito en sus propios proyectos. En esa publicación aceptaba cada cambio sin leer los diffs y volvía a pegar los mensajes de error sin ningún comentario. 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 entenderlo. 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 propio 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.

Simon Willison trazó la línea en una publicación del 19 de marzo de 2025. Para él, el vibe coding consiste en crear software con un LLM 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 comprobaciones de abajo son una primera pasada de revisión que no exige leer el código línea a línea. No sustituyen la revisión de un ingeniero.

Dos informes públicos que conviene conocer

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 un registro en disputa sobre tablas de base de datos abiertas. 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.

Un borrado de base de datos notificado (julio de 2025)

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 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. El informe de The Register se basa en relatos públicos.

Un registro en disputa sobre tablas de base de datos abiertas (mayo de 2025)

Un registro público de vulnerabilidades, 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 (row-level security) 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. La seguridad a nivel de fila es una regla de la base de datos que decide qué filas puede leer o escribir un usuario.

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.

Cinco comprobaciones

Dedique a cada comprobación unos 10 minutos y pare cuando se acabe el tiempo. Anote lo que vea en la página descrita en «Revise hoy».

1. Secretos: encuentre cada clave y contraseña. 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. Willison aconsejaba tener cuidado de no exponerlos por accidente, lo que implica entender cómo funciona el código.

• Qué hacer: 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.
• Trampa: 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.

2. Acceso a los datos: ¿quién puede leer y escribir cada tabla?

• Qué hacer: 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 pida a su herramienta que enumere cada tabla de la base de datos y diga si la seguridad a nivel de fila está activada. 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.
• Trampa: 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.

3. Inicios de sesión y roles: ¿puede un usuario llegar a lo que no es suyo?

• Qué hacer: 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.
• Trampa: 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.

4. Datos de prueba y datos reales por separado, y una vía de vuelta atrás.

• Qué hacer: 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. Restaure una en una copia.
• Trampa: trate una copia de seguridad que nadie ha restaurado como una suposición, y restaure una en una copia para comprobarlo. Aquí se aplican dos puntos de los informes anteriores: el blog de Replit, tal como lo cita The Register, decía que sus apps habían usado una base de datos para el desarrollo y los datos en producción, y Lemkin aconsejaba aprender el sistema de reversión (rollback) desde el primer día.

5. Gasto: un límite en cada servicio de pago.

• Qué hacer: 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.
• Trampa: 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.

Qué hacer con cada hallazgo

Cada hallazgo de las cinco comprobaciones 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, 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.

Hasta dónde llegan estas comprobaciones

Las cinco 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.

• Las comprobaciones 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.

Revise 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

COMPROBACIÓN 2 ACCESO A LOS DATOS
REVISADO:
VISTO:
ESTADO: OK | ABIERTO | NO COMPROBADO

COMPROBACIÓN 3 INICIOS DE SESIÓN Y ROLES
REVISADO:
VISTO:
ESTADO: OK | ABIERTO | NO COMPROBADO

COMPROBACIÓN 4 DATOS DE PRUEBA Y REALES, COPIAS DE SEGURIDAD
REVISADO:
VISTO:
ESTADO: OK | ABIERTO | NO COMPROBADO

COMPROBACIÓN 5 LÍMITES DE GASTO
REVISADO:
VISTO:
ESTADO: OK | ABIERTO | NO COMPROBADO

COSAS QUE NO PUDE EXPLICAR EN UNA FRASE:

Para obtener las primeras respuestas más rápido, pegue esto en su herramienta de IA, dentro de la copia del proyecto. Trate la respuesta como una lista de pistas. La herramienta puede equivocarse, así que abra cada archivo que nombre.

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.
Para cada respuesta escriba: lo que encontró, el nombre del archivo y «no comprobado» si no pudo saberlo. No adivine.

Siguiente paso

Fuentes

Comprobadas el 16 de octubre de 2026. Todos los enlaces abren la página que leímos.

• 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.