Escribir software conversando con un modelo se volvió normal. Le describes lo que quieres, aparece código que funciona, lo despliegas. La velocidad es real y no pienso discutirla.
El problema es otro: el código que funciona y el código que es seguro no son lo mismo, y un modelo optimiza lo primero.
Lo que un modelo te da por defecto
Cuando pides "un panel de administración", el resultado suele traer autenticación. Técnicamente. En la práctica he visto aparecer cosas como esta:
if (!authHeader || !authHeader.includes('Bearer')) {
return unauthorized()
}
Eso no valida nada. Cualquier cabecera que contenga la palabra "Bearer" pasa. El código parece seguro, pasa una revisión rápida, y deja la puerta abierta.
El patrón se repite con variantes:
- Tokens que son
base64(email)en vez de una firma. Cualquiera los fabrica. - Endpoints de "setup" o "fix" que resetean credenciales sin pedir nada, creados para arrancar el proyecto y nunca eliminados.
- Secretos con valor por defecto —
process.env.SECRET || 'dev-secret'— que en producción firman sesiones reales con una cadena pública. - Borradores accesibles por su URL porque la consulta nunca filtró por estado.
Ninguno es un error exótico. Son atajos razonables mientras construyes, que nadie volvió a mirar.
Por qué pasa
No es que el modelo sea descuidado. Es que le pediste que funcionara, no que resistiera.
Un endpoint que resetea la contraseña del admin es exactamente lo que necesitas el primer día. El modelo te lo da. Lo que no te dice es que ese endpoint debe morir antes de que el sitio vea internet, porque esa parte no estaba en la pregunta.
Y cuando pides "arregla el error de autenticación", el modelo arregla el error. No audita las otras siete rutas.
Qué hacer
Pregunta por el atacante, no por la función. "¿Qué puede hacer alguien sin sesión contra este endpoint?" produce respuestas muy distintas a "¿funciona el login?".
Inventaría los endpoints periódicamente. Listar cada ruta y responder quién puede llamarla toma diez minutos y encuentra lo que se acumuló sin que nadie lo decidiera.
Desconfía de lo que se llama setup, fix, debug o test. Son andamios. Si siguen en producción, son superficie de ataque.
Revisa las dependencias. Un framework desactualizado puede acumular decenas de vulnerabilidades conocidas, incluida ejecución remota de código. Una actualización de parche suele cerrarlas sin romper nada.
Que los secretos fallen ruidosamente. Si falta una variable de entorno, mejor que la aplicación no arranque a que use un valor por defecto que alguien puede leer en GitHub.
Lo que no cambia
La velocidad del vibe coding es genuina y no hay que renunciar a ella. Pero la seguridad no emerge sola de una conversación fluida: hay que pedirla explícitamente, y hay que volver a mirar.
Lo interesante es que el mismo modelo que escribió el atajo suele encontrarlo cuando le preguntas bien. La herramienta no es el problema. La pregunta sí.