Vibe Coding
Construir software pidiéndole a una herramienta de IA (Lovable, Cursor, Claude Code, Replit, Bolt, v0) y aceptando lo que genera sin leerlo. Rápido para llegar a un demo, peligroso en producción, porque el modelo optimiza para código que corre, no para código que sobrevive a un usuario real.
Vibe coding es la práctica de describirle a una herramienta de IA lo que quieres y lanzar lo que te devuelve, sin leer el código línea por línea. El término se popularizó a principios de 2025, pero el flujo es anterior al nombre: pides, lo corres, ves que funciona, vuelves a pedir. Herramientas como Lovable, Cursor, Claude Code, Replit, Bolt y v0 hacen posible que alguien sin perfil de ingeniería pase de la idea a una app clicable en una tarde. Esa parte es real, y es genuinamente útil para prototipos, herramientas internas y validar que una idea merece construirse.
El problema empieza en cuanto una app vibe-coded se topa con un usuario real, dinero real o datos reales. Un LLM optimiza para código que satisface el prompt y corre en el demo. No optimiza para lo que nadie pidió en el prompt: comprobaciones de autorización, validación de input, gestión de secretos, rate limiting, manejo de errores, la suite de regresión. Eso es exactamente lo que separa un demo de software listo para producción, y es exactamente lo que el modelo deja fuera salvo que sepas pedirlo, cosa que alguien sin perfil técnico por definición no sabe.
Ejemplo. Un founder vibe-codea un dashboard SaaS en un fin de semana. Tiene login, base de datos, una UI limpia y demostra de maravilla. Lo que no tiene es una comprobación del lado del servidor de que el usuario A no puede leer los registros del usuario B. El login funciona, así que se siente seguro. Pero cualquier usuario autenticado puede cambiar un ID en la URL y leer los datos de cualquier otro cliente. Nunca se le pidió al modelo que impusiera autorización por inquilino, así que no lo hizo, y nada en el demo dejó ver el hueco. Este es, con diferencia, el defecto grave más común en el software vibe-coded, y es invisible hasta que alguien, o algún regulador, lo encuentra.
El trade-off honesto: el vibe coding es genuinamente más rápido para llegar a un demo que funciona, y pretender lo contrario es deshonesto. El precio es que esa velocidad viene de saltarse las partes de la ingeniería que no tienen recompensa visible hasta que fallan. Es un buen trato para un prototipo desechable y uno pésimo para cualquier cosa que guarde datos de clientes. El error no es usar las herramientas. El error es confundir el demo con el producto y lanzarlo. El código generado por IA no es intrínsecamente peor que el escrito a mano, pero acumula deuda técnica en silencio y se salta el mismo trabajo de seguridad cada vez.
La postura de Wavect es simple: vibe-codea el prototipo, luego haz un pase estructurado de production-readiness antes de que lleguen usuarios reales. Ese pase no es un vibe. Es la misma disciplina que aplicamos a cualquier código: TDD en la lógica que importa, autorización en cada endpoint, secretos fuera del cliente y un pipeline de CI/CD que corre las comprobaciones en cada cambio. Lo hacemos bajo Software Quality Assurance. Las herramientas son buenas. Solo que no saben qué dejaron fuera, y tú tampoco, hasta que alguien lo lee.