⚠️ Vibe coding es poderoso. También puede ser peligroso si no sabés qué está haciendo el agente bajo el capó.
Un caso real lo dice todo: Moltbook, una red social IA, sufrió un leak masivo por vibe coding — 1,5 millones de API keys y 35.000 emails expuestos. La causa: shortcuts que los agentes de código tomaron sin considerar seguridad.
¿Por qué los agentes fallan en seguridad?
Velocidad sobre seguridad: los LLMs optimizan para que el código corra, no para que sea seguro. Si hay un error, el agente lo “resuelve” aunque implique deshabilitar validaciones.
No conocen el contexto completo: al refactorizar un archivo, el agente puede romper controles de seguridad en otro archivo que no estaba viendo.
Pattern matching, no juicio: para un agente, un check de seguridad es solo otro bug que impide que el código ejecute.
3 bugs de seguridad reales generados por vibe coding:
❌ API Keys expuestas → el agente pone la key directamente en el frontend JS (visible en “Inspect Element”)
❌ Base de datos pública → para resolver “Permission Denied” en Supabase, agrega USING (true) → toda la DB queda pública
❌ XSS vulnerabilities → para renderizar HTML, usa dangerouslySetInnerHTML sin sanitizar
💡 Explicación en pocas palabras#
Los agentes de código son excelentes para generar lógica de negocio rápidamente, pero tienen un punto ciego crítico: no entienden las implicaciones de seguridad de lo que escriben. La solución no es dejar de usarlos, sino revisarlos activamente y agregar capas de revisión de seguridad en el proceso de desarrollo.
Más información en el link 👇
