Arregle una aplicación creada con vibe coding antes de que llegue a usuarios reales

¿Cuáles son las fases para arreglar una aplicación creada con vibe coding?

¿Puede comprobar usted mismo su aplicación? Una autocomprobación de diez puntos

No necesita leer código para la mayoría de ellos. Si alguna respuesta es “no” o “no lo sé”, la aplicación necesita una revisión antes del lanzamiento.

• Abra el código fuente de la página y busque “key” o “secret”: no debe aparecer ninguna clave de API privada
• Cada tabla de Supabase tiene Row Level Security activado, con políticas que se corresponden con quién debe ver qué
• Las reglas de seguridad de Firebase no están en modo de prueba y no permiten lecturas ni escrituras abiertas
• Un visitante sin sesión iniciada no puede abrir páginas de administración ni invocar acciones de administración adivinando la URL
• Un usuario no puede ver los datos de otro cambiando un ID en la barra de direcciones
• Los precios y los planes provienen del servidor o del proveedor de pagos, nunca del navegador
• Los webhooks de pago se verifican con el secreto de firma del proveedor
• Las claves secretas viven en variables de entorno, no en archivos subidos a Git
• Se avisa a alguien cuando la aplicación lanza errores, mediante una herramienta como Sentry
• La base de datos tiene copia de seguridad y usted ha probado a restaurarla

¿Por qué necesita revisión el código generado por IA?

Los modelos de IA escriben código que responde al prompt. Son mucho menos fiables en lo que nadie pidió: qué usuario debería poder hacer esto, qué ocurre con una entrada inesperada, qué pasa si llegan dos solicitudes a la vez. Veracode probó más de 100 modelos en 80 tareas de programación en 2025 y descubrió que el 45 % de los resultados introducía una clase conocida de fallo de seguridad, sin una mejora clara en los modelos más grandes o más recientes.

Las consecuencias son reales. En 2025 un investigador analizó 1645 aplicaciones del escaparate público de un constructor de aplicaciones con IA y encontró 170 cuyas tablas de base de datos podían leerse usando solo la clave pública que se envía a todos los navegadores, porque no se había activado Row Level Security. El problema se registró como CVE-2025-48757. La plataforma discutió su responsabilidad señalando que cada propietario de aplicación controla sus propias reglas de datos, que es justamente el punto: el propietario tiene que comprobarlo.

¿Qué problemas aparecen en qué herramientas de IA?

La herramienta importa menos que el stack que genera. Estos son los patrones que buscamos primero.

¿Cuándo conviene dejar de dar instrucciones a la IA y llamar a un desarrollador?

Una regla útil: si el mismo error ha sobrevivido a tres intentos, lo más probable es que la causa sea estructural. Cada nuevo prompt tiende a añadir un parche en lugar de corregir la raíz, y el código se vuelve más difícil de modificar con cada ronda. Ese es el momento de que alguien lea el código en lugar de describirlo.

Incorpore a un desarrollador antes del lanzamiento si la aplicación almacena datos personales, acepta pagos o la usa una empresa para gestionar sus operaciones. En esos casos, el coste de una brecha de seguridad no detectada es mucho mayor que el de una revisión.

Errores habituales al corregir código creado con IA

• Preguntar a la IA si el código es seguro

  Un modelo que revisa su propia salida tiende a darse la razón. Recurra a una persona o a un escáner especializado, idealmente a ambos.

• Corregir síntomas en la interfaz

  Ocultar un botón no detiene la petición que hay detrás. Los permisos deben aplicarse en el servidor y en la base de datos.

• Borrar claves sin rotarlas

  Una clave eliminada del código sigue siendo válida y sigue en el historial de Git. Sustitúyala en el proveedor.

• Añadir a ciegas los paquetes que sugiere la IA

  A veces los modelos sugieren paquetes que no existen o que están obsoletos. Compruebe cada uno antes de instalarlo.

Nuestra opinión