Qué es el vibe coding
El término se popularizó en 2025 y describe una forma de programar en la que se le dice a un modelo lo que se quiere, se prueba el resultado y se acepta sin leer todo el código que ha escrito. La gracia está en la velocidad: en una tarde hay algo funcionando y demostrable.
Eso no es un problema en sí. Lo es cuando ese código pasa de la demostración a producción sin que nadie con experiencia haya mirado qué datos toca, qué deja abierto y qué pasa cuando entran mil personas en vez de tres.
¿Es bueno o malo el vibe coding?
Ninguna de las dos cosas: es una herramienta, y sirve según para qué. Para una maqueta, una prueba de concepto o una herramienta interna es de lo más rápido que hay. Para algo que guarda datos de clientes, cobra o recibe tráfico real, esa velocidad se convierte en riesgo si nadie revisa lo que se ha escrito.
Las ventajas son reales: una idea se prueba en horas, quien no programa puede enseñar lo que quiere y el equipo técnico parte de algo que ya funciona. Los riesgos también: código que nadie entiende del todo, permisos abiertos por defecto, dependencias elegidas al azar y errores que no avisan. La diferencia la marca lo que pasa entre la demostración y producción.
Dónde falla el código que escribe la IA
La IA escribe código que funciona en el camino feliz, que es el que se prueba en la demostración. Lo que falta suele ser lo que no se ve: la comprobación del dato que llega mal, el permiso que nadie revisó, la consulta que tarda cuando la tabla crece y el secreto que se quedó escrito en el repositorio.
Está medido. El 45% del código generado por IA en laboratorio traía vulnerabilidades conocidas cuando no se le daban instrucciones de seguridad.
Herramientas de vibe coding y qué cambia entre ellas
Hay dos familias. Los editores y asistentes que trabajan dentro del código, como Cursor, GitHub Copilot o Claude Code, y las plataformas que generan una aplicación entera a partir de una descripción, como Lovable, Bolt, Replit o Google AI Studio. Los primeros dejan el código a la vista de un equipo técnico; las segundas lo esconden más y a menudo lo publican solas.
Para revisarlo, la herramienta cambia dónde se mira primero, no lo que hay que mirar. En las plataformas que publican solas, lo primero son las claves y los permisos de la base de datos; en los editores, las dependencias y las rutas que se añadieron sin que nadie las pidiera.
Qué revisar antes de publicar
Seis cosas, por este orden: secretos y credenciales fuera del código; rutas y permisos, para que nadie vea lo que no le toca; datos personales, en las respuestas y en los registros; rendimiento con el volumen real, no con tres filas de prueba; dependencias y versiones; y qué pasa cuando algo falla, que es donde se ve si el sistema avisa o se calla.
Ninguna de las seis se comprueba leyendo el código por encima: se miden. Por eso una revisión sirve y una lectura rápida no.
Cómo lo revisamos nosotros
Con herramientas de IA que se adaptan a tu desarrollo y miran primero los puntos donde sabemos que la IA falla, y con una persona con experiencia revisando cada hallazgo. No dejamos ninguna herramienta trabajando sola: lo que se entrega lleva evidencia de cada punto, con la medición al lado.
Si el desarrollo es una web, esa revisión es la de sitios web; si es una app, la de apps móviles; si es la parte de servidor, la del backend y su API.