Software Vibe-Coded

El software vibe-coded es el resultado del vibe coding : una aplicación construida mayormente por herramientas de IA donde ningún humano ha leído las partes que importan para la seguridad. No se define por ser generado por IA. Se define por la ausencia de una revisión humana en los caminos donde equivocarse cuesta dinero real, datos reales o una brecha real. Mucho código generado por IA está revisado, endurecido y es perfectamente seguro. El software vibe-coded es el subconjunto que no lo está.

El rasgo que lo define es que demostra limpio y se rompe de forma predecible. Demostra limpio porque el modelo es muy bueno haciendo funcionar el happy path, el camino que recorres en el demo. Se rompe de forma predecible porque los fallos se agrupan siempre en el mismo puñado de sitios: autorización que comprueba que estás logueado pero no si tienes permiso para ver este registro concreto, input en el que se confía en vez de validarse, secretos hardcodeados o enviados al navegador, sin rate limiting, sin manejo de errores más allá de un catch genérico. Quien ha auditado una app vibe-coded puede adivinar los hallazgos de la siguiente antes de abrirla.

Ejemplo, el canónico. Una app de reservas tiene un login limpio. Una vez dentro, la app obtiene tus reservas de /api/bookings/1234. Cambia 1234 por 1235 y ves la reserva de otra persona, su nombre, su dirección, su referencia de pago. El login se sentía seguro, así que nadie lo comprobó. El servidor nunca verificó que el usuario logueado fuera dueño de la reserva 1235. A esto se le llama un bug de broken object level authorization, y es, con diferencia, el defecto grave más común en el software vibe-coded, porque el demo nunca ejercita el caso de un usuario alcanzando los datos de otro.

El trade-off honesto: el software vibe-coded es genuinamente más barato y rápido de producir, y para un prototipo eso es justo lo correcto. El precio es que el ahorro está adelantado y la factura llega después, como una brecha, un incidente de RGPD o una reescritura. Señalarlo no es esnobismo anti-IA. El código puede ser perfectamente bueno una vez que se añade el 10 % que falta. El error es lanzar el 90 % y asumir que el demo demostró que el otro 10 % existe.

Wavect audita software vibe-coded buscando exactamente este perfil bajo Software Quality Assurance . Leemos primero los caminos de autorización, porque ahí vive el bug peor y más común, luego validación de input, secretos y manejo de errores, y después añadimos la suite de regresión y el gate de CI/CD que impide que el siguiente cambio vuelva a abrir el hueco. No es una reescritura. Es hacer visible la deuda técnica que dejaron las herramientas, y luego pagar la parte que puede hacerte daño.

Cuándo importa esto en un proyecto de software. Cuando tienes una app que demostraba limpio y nadie ha leído los caminos de autorización. El riesgo definitorio no es código malo, es la ausencia de una revisión humana donde equivocarse cuesta dinero, datos o una brecha.

Qué suelen hacer mal los founders. Envían el 90 por ciento que la demo probó y asumen que la demo probó también el otro 10 por ciento. El 10 por ciento que falta, auth, validación, secretos, es justo la parte que la demo nunca ejercita.

Cómo lo maneja Wavect. Auditamos buscando el perfil de fallo predecible, autorización primero porque ahí vive el peor bug, y luego añadimos la suite de regresión y el gate de CI/CD que impide que el hueco se reabra. La guía de prototipo vibe-coded a producción muestra qué se conserva y qué se reconstruye.