Cuándo NO hacer vibe coding: los casos en que el riesgo supera la velocidad
Cuándo no conviene hacer vibe coding: datos personales, pagos, login, software que debe durar o código que nadie revisa. Señales, alternativas y un ejemplo.
¿Qué significa “riesgo” en código?
Cuando un código falla, el daño depende de tres cosas: a quién afecta, qué datos toca y cuánto tiempo sigue en uso. Un script personal que falla molesta a una persona. Una app de pagos que falla afecta a clientes, a finanzas y a la reputación. Por eso la pregunta útil no es “¿puedo hacer vibe coding?”, sino “¿qué pasa si esto sale mal y a quién le pasa?”.
Simon Willison, que define el vibe coding como construir software con un LLM sin revisar el código que escribe, lo plantea igual: los proyectos deben ser de bajo riesgo (“low stakes”), y hay que pensar cuánto daño podría causar el código si tiene errores o vulnerabilidades, sobre todo si lo van a usar otras personas (Willison, marzo de 2025). Su regla personal es no subir a su repositorio código que no pueda explicarle a otra persona.
Hay además una razón medida para desconfiar. Un estudio de Veracode publicado en julio de 2025 evaluó más de 100 modelos de lenguaje en 80 tareas de programación: el código generado introdujo vulnerabilidades en el 45% de los casos (Veracode, julio de 2025). Son tareas controladas, no una medición de todo el código en producción, pero bastan para no dar por bueno un código solo porque funciona.
¿Qué señales indican que no conviene?
| Señal | Por qué importa | Qué hacer en cambio |
|---|---|---|
| Hay datos personales o de salud | Un error expone a personas reales | Diseñar el flujo y pedir revisión de privacidad |
| Hay pagos o dinero de terceros | Un cobro mal calculado no se corrige solo | Usar un proveedor de pagos probado |
| Usa una API que cobra por uso | Un bucle o una clave filtrada generan una factura alta | Poner un límite de gasto en el proveedor antes de probar |
| Hay login o permisos | Un error permite ver datos de otros | Usar un servicio de autenticación existente |
| Se va a usar por años | El código se vuelve difícil de cambiar | Escribir una especificación y revisar cada cambio |
| Otros dependen del resultado y nadie puede revisarlo | Nadie detecta los errores ni sabe qué hace el código | Conseguir una revisión humana antes de publicar |
Si aparece una sola de estas señales, el prototipo puede seguir siendo vibe coding, pero la versión que usan otras personas no. La señal del dinero se olvida con facilidad: Willison menciona casos de personas que acumularon miles de dólares en cargos por hacer vibe coding contra APIs que cobran por uso sin haber puesto un límite de facturación.
¿Cuándo sí está bien hacer vibe coding?
Sirve cuando el error es barato y lo paga quien lo construye. Andrej Karpathy, que acuñó el término en febrero de 2025, ya lo describía como algo “no tan malo para proyectos desechables de fin de semana”, según la cita que recoge Willison. Casos típicos:
- Prototipos para probar una idea con usuarios en una sesión moderada, con datos de mentira.
- Herramientas personales, como un script que renombra archivos o un tablero que solo ves tú.
- Aprender. Willison anima a los principiantes a probarlo, porque construir un proyecto es la mejor forma de aprender, y recomienda empezar en entornos aislados (sandbox) que limitan lo que el código puede tocar.
- Explorar interacciones: una animación, un flujo o un componente que después se rehace con revisión.
La línea no la marca la herramienta, sino el destino del código. Si el prototipo va a recibir datos reales o usuarios de fuera, cambia de categoría. La diferencia entre ambos modos de trabajo está en vibe coding vs. ingeniería asistida por IA.
¿Qué revisar antes de abrirlo al público?
Si un proyecto hecho con vibe coding va a pasar a manos de otras personas, la revisión mínima de seguridad (permisos, secretos, validación de datos y dependencias) está en seguridad básica para quien hace vibe coding. Addy Osmani lo resume con una frase en su guía Beyond Vibe Coding: el vibe coding es divertido hasta que empiezas a filtrar credenciales de la base de datos en el cliente (Osmani, Beyond Vibe Coding).
Más allá de la seguridad, hay dos preguntas propias de esta decisión. La primera: ¿alguien del equipo puede leer y cambiar este código dentro de seis meses? Si la respuesta es no, el proyecto depende de volver a pedirle todo a la IA. La segunda: ¿qué pasa si se cae un día? Si la respuesta es “un cliente no puede trabajar”, ya no es un prototipo. Willison sugiere algo simple para ese punto: si otras personas van a usarlo, pide antes una revisión (“vibe check”) a alguien con más experiencia.
Ejemplo
Ejemplo ilustrativo: una diseñadora arma con vibe coding una herramienta interna para que su equipo registre comentarios de pruebas de usabilidad. Para una tarde, funciona. Ocho meses después, tres equipos la usan, guarda nombres y correos de participantes, y se conecta a una API de IA que cobra por uso para resumir cada sesión. Un día deja de guardar datos y nadie sabe por qué, porque nadie leyó el código. Al pasarla por la tabla de señales, aparecen cuatro: datos personales, API con cobro por uso, uso prolongado y personas que dependen de ella. La diseñadora congela las funciones nuevas, pone un límite de gasto en el proveedor de la API y pide a un desarrollador que revise el acceso a los datos y documente cómo funciona antes de seguir.
¿Cómo lo aplicas mañana?
- Pasa tu próximo proyecto por la tabla de señales antes de empezar. Escribe sí o no en cada una y guarda la respuesta en el README o en la página del proyecto.
- Si al menos una señal dice sí, separa las partes. Por ejemplo: la pantalla puede ser vibe coding, el módulo de pagos no.
- Si el proyecto llama a una API que cobra por uso, configura un límite de gasto antes de la primera prueba.
- Antes de publicar, pide a alguien de ingeniería que revise dónde viven las claves y qué pasa cuando un usuario entra con una cuenta que no es suya.
- Pon una fecha de revisión en el calendario. Si en esa fecha el prototipo sigue en uso, trátalo como producto y revísalo como tal.
Decidir no hacer vibe coding también es una decisión de diseño: le pone límites claros al equipo y evita sorpresas en el lanzamiento. Si recién empiezas con el tema, lee primero qué es vibe coding.
Errores comunes
- Decidir que algo es “solo un prototipo” cuando ya tiene datos reales.
- Pensar que la IA no pondría una falla de seguridad porque el código “se ve bien”.
- Probar contra una API que cobra por uso sin límite de gasto.
- Confiar en que la demo funciona como prueba de seguridad.
- Dejar que un prototipo se convierta en producto sin que nadie lo decida.
- Usar vibe coding para reemplazar un servicio probado, como pagos o autenticación.
Fuentes
- Veracode, “AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks” (30 de julio de 2025): https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/
- Addy Osmani, “Beyond Vibe Coding” (guía en línea): https://beyond.addy.ie/
- Simon Willison, “Not all AI-assisted programming is vibe coding (but vibe coding rocks)” (19 de marzo de 2025): https://simonwillison.net/2025/Mar/19/vibe-coding/