Guía
¿Es malo el vibe coding? Qué sale mal y cómo revisar tu código
El vibe coding no es malo en sí. El riesgo es publicar código que nadie leyó. Los errores que repiten los asistentes de IA, cuándo importan y cómo detectarlos.
· 7 min de lectura · Por el equipo de vetkit
La respuesta corta
No, el vibe coding no es malo en sí mismo. Es una forma rápida de conseguir software que funciona, y para prototipos, herramientas internas y aprendizaje suele ser la opción correcta. Se convierte en un problema en un punto concreto: cuando código que nadie ha leído empieza a manejar usuarios reales, datos reales o dinero real. El riesgo no es que una IA haya escrito el código. El riesgo es que nadie lo haya revisado.
Así que la pregunta útil no es «¿es malo el vibe coding?», sino «¿qué tengo que revisar antes de que esto salga a producción?». El resto de esta guía responde a eso.
Qué significa vibe coding
Hacer vibe coding significa crear software describiéndole a un asistente de IA lo que quieres y aceptando el código que escribe, casi siempre sin leerlo. El término lo acuñó Andrej Karpathy a principios de 2025 para describir una forma de trabajar en la que te dejas llevar por las «vibes» y olvidas incluso que el código existe. Juzgas el resultado ejecutando la aplicación, no revisando los cambios.
Eso es distinto del desarrollo asistido por IA, en el que un desarrollador usa las mismas herramientas pero sigue leyendo, probando y asumiendo la responsabilidad de cada cambio. La mayoría de los proyectos reales están en algún punto intermedio, y se deslizan hacia el vibe coding cuando los plazos aprietan.
Qué sale mal
Los asistentes de IA son buenos produciendo código que se ejecuta. Son menos fiables en lo que no aparece cuando recorres la aplicación una sola vez. Los mismos errores aparecen una y otra vez:
| Problema | Cómo se manifiesta | Por qué no lo notas |
|---|---|---|
| Secretos en el lugar equivocado | Una API key commiteada en el repositorio o incluida en el bundle del navegador | La aplicación funciona exactamente igual en ambos casos |
| Faltan controles de acceso | Cualquier usuario con sesión iniciada puede leer los registros de otro usuario; tablas de base de datos sin reglas a nivel de fila | Solo pruebas con tu propia cuenta |
| Paquetes que no existen | El asistente inventa un nombre de paquete verosímil, y puede que otra persona lo haya registrado | El comando de instalación termina sin errores |
| Código a medio terminar | Funciones de relleno, ramas TODO y errores silenciados que quedan en el flujo principal | El camino feliz sigue funcionando |
| Entrada no confiable usada directamente | Datos de la petición insertados en SQL, comandos de shell, rutas de archivo o HTML | Con una entrada normal, todo se comporta con normalidad |
| Nada previsto para los fallos | Llamadas HTTP sin timeouts, consultas dentro de bucles, sin reporte de errores | Va rápido con diez filas y un usuario |
Nada de esto es nuevo. Los desarrolladores cometían todos estos errores antes de que existieran los asistentes de IA. Lo que cambia con el vibe coding es el volumen y la falta del paso de revisión: llega más código y más rápido, y la persona que habría detectado el problema nunca lo lee. Tres de ellos se tratan en detalle en otras páginas de este sitio: API keys en el navegador, paquetes inventados y secretos filtrados.
Cuándo importa y cuándo no
El vibe coding es una opción razonable cuando un error sale barato:
- Un prototipo o una demo que se va a tirar o reescribir.
- Un script personal o una herramienta interna sin datos sensibles.
- Aprender un framework nuevo o explorar una idea.
Necesita una revisión antes de publicarse cuando un error sale caro:
- La aplicación tiene cuentas de usuario, pagos o datos personales.
- Guarda credenciales de otros servicios, como un proveedor de LLM o una base de datos.
- Otras personas dependerán de que siga funcionando, o alguien más tendrá que mantenerla.
La línea no la marca cómo se escribió el código, sino qué pasa si el código está mal. Muchos proyectos cruzan esa línea sin que nadie lo decida: la demo consigue sus primeros usuarios reales y nadie vuelve atrás para leerla.
Cómo mantener la velocidad sin el riesgo
No tienes que renunciar a la velocidad. Tienes que recuperar la revisión que el vibe coding se salta.
- Lee los cambios que tocan dinero, login y datos. Puedes saltarte el código de maquetación. No puedes saltarte la autenticación, la autorización, los pagos ni nada que escriba en la base de datos. La checklist de revisión de código generado por IA enumera qué buscar.
- Prueba con dos cuentas. Inicia sesión como un usuario e intenta leer o modificar los registros de otro. Esta sola prueba encuentra la clase de bug más dañina en las aplicaciones hechas con vibe coding.
- Revisa cada dependencia nueva. Confirma que el paquete existe, que es el que querías y que no se publicó la semana pasada.
- Escanea el repositorio antes de publicar. Una auditoría automatizada encuentra los problemas mecánicos más rápido que una persona: secretos commiteados, dependencias vulnerables o inexistentes, timeouts ausentes y manejo inseguro de la entrada. El catálogo de checks de vetkit muestra las reglas que ejecuta, y el Security Quick Scan gratuito cubre secretos, vulnerabilidades conocidas en dependencias y la configuración de seguridad básica.
- Pide al asistente que corrija lo que encuentre el escaneo. Conecta el escáner a tu agente de programación para que los hallazgos vuelvan a la misma conversación. La guía de MCP explica cómo.
Cuando estés listo para publicar, la checklist de seguridad antes de publicar una aplicación hecha con vibe coding recorre la decisión de lanzamiento paso a paso.
Fuentes y límites
La lista de problemas habituales refleja las categorías que cubren las reglas propias de vetkit para riesgos del código generado por IA, seguridad, resiliencia y acceso a datos, revisadas el 10 de noviembre de 2026. Es una descripción de patrones recurrentes, no una medición de con qué frecuencia ocurren. El término «vibe coding» procede de la publicación de Andrej Karpathy de febrero de 2025.
Un escaneo automatizado es evidencia que hay que revisar, no una prueba de que una aplicación sea segura. Lee el código fuente; no prueba los permisos de tu despliegue, la configuración de tu hosting ni tus reglas de negocio. La prueba con dos cuentas y la revisión manual descritas arriba siguen siendo tu trabajo.