Qué es el vibe coding y por qué todo el mundo habla de ello

Vibe coding es construir software describiendo lo que quieres, sin leer el código que sale.

Le dices a una IA "quiero una web donde la gente apunte su correo y me llegue un aviso", ella lo escribe, tú lo miras funcionando y, si algo no te gusta, se lo dices con palabras. No abres los archivos.

Esa última parte es la clave y la que casi nadie menciona: si estás revisando el código, no es vibe coding. Es programar con ayuda, que es otra cosa y bastante más sensata.

¿Qué significa vibe coding?

El término lo popularizó Andrej Karpathy a principios de 2025, y la gracia estaba en que era medio broma. Describía una forma de trabajar donde te dejas llevar, aceptas lo que la IA propone y vas corrigiendo por sensaciones. Vibes.

De ahí saltó a todas partes y perdió el matiz irónico por el camino. Hoy se usa para cualquier cosa donde hay una IA escribiendo código, que es justo lo que hace que el término no sirva para nada.

Vamos a fijarlo bien, porque la distinción importa:

Vibe coding de verdad: describes, aceptas, pruebas, describes otra vez. No lees lo que se ha escrito. Tu única señal es si funciona o no.

Programar con IA: describes, lees lo que ha hecho, lo corriges, decides cómo debería estar montado. Vas mucho más rápido que a mano, pero sigues al mando.

Lo primero es rapidísimo y tiene techo. Lo segundo es más lento y no lo tiene.

Un ejemplo, para que se vea

Un sábado por la tarde quieres una herramienta que te calcule algo y te la enseñe bonita. Un conversor, una calculadora de presupuestos, lo que sea.

Abres una de estas herramientas. Escribes: "una página con tres campos, que calcule el precio final aplicando el IVA y un descuento por volumen, con el resultado grande en el centro".

En un par de minutos lo tienes en pantalla. Funcionando. Con su diseño.

Le dices "el botón que sea verde y añade un campo para el nombre del cliente". Y cambia.

Le dices "quiero poder guardar los presupuestos". Y monta una base de datos por detrás sin que tú sepas ni qué base de datos es.

Eso es vibe coding. Y la primera vez que lo haces te quedas mirando la pantalla un rato, porque hace tres años eso era una semana de trabajo.

¿Con qué se hace?

Hay dos familias.

Las que generan una aplicación completa desde el navegador. Escribes lo que quieres y te devuelven algo publicado, con su base de datos y sus usuarios. Lovable (enlace de afiliado: así me ayudas a seguir creando contenido) es de las más conocidas de este grupo y es la vía más rápida para pasar de idea a algo que se puede enseñar.

Las que trabajan sobre un proyecto de verdad. Emergent va por aquí: en lugar de una aplicación cerrada, te construye un proyecto que luego puedes llevarte, tocar y desplegar donde quieras. Es un paso más de control a cambio de un poco más de fricción. El paso a paso completo lo tengo en el tutorial de vibe coding con Emergent.

Casi todas tienen un plan gratuito con el que puedes montar dos o tres cosas pequeñas, y los planes de pago van en el orden de magnitud de las decenas de euros al mes. Cambian a menudo, así que confirma en la web oficial de la que elijas.

Para qué funciona de verdad

Para probar una idea rápido. Antes de decidir si algo merece semanas de trabajo, montarlo en dos horas y enseñárselo a cinco personas es lo mejor que puedes hacer. La mitad de las ideas mueren ahí, y eso es una victoria.

Para herramientas de uso propio. Cosas que usas tú, o tu equipo de tres personas. Si se rompe, lo arreglas o lo rehaces. El riesgo es cero.

Para aprender. Montar algo y luego pedirle que te explique qué ha hecho y por qué es la forma más rápida que conozco de entender cómo funciona una aplicación por dentro. Y encima estás mirando código de algo que te importa, no ejercicios.

Para dejar de tener miedo. Este es el efecto más subestimado. Gente que llevaba años pensando "yo esto no lo sé hacer" monta algo en una tarde y cambia la relación entera con la tecnología.

Dónde revienta

Aquí es donde se acaba la fiesta, y conviene saberlo antes de comerse el golpe.

En cuanto hay usuarios de verdad. Un fallo de seguridad en algo que solo usas tú es una anécdota. En algo con clientes dentro y datos suyos, es un problema serio. Y estas herramientas dejan agujeros, porque nadie está revisando.

Cuando algo se rompe y no sabes describir el problema. Le dices "no funciona" y te pregunta qué falla exactamente. Si no puedes leer el código ni entender el error, entras en un bucle donde le pides que lo arregle, cambia cosas al azar y cada vez está peor. Este bucle lo ha vivido todo el que ha probado esto más de un rato.

Cuando el proyecto crece. Las primeras diez peticiones van de maravilla. En la número cincuenta, el proyecto tiene una estructura que nadie ha diseñado y cada cambio nuevo rompe dos cosas viejas. No porque la IA sea mala, sino porque nadie ha estado tomando decisiones de cómo debía estar montado aquello.

Cuando quieres que otra persona lo continúe. Nadie sabe cómo funciona. Ni tú, ni el siguiente. La única documentación es la conversación que tuviste.

Tres cosas que ayudan muchísimo y no cuestan nada

Si vas a probarlo este fin de semana, con esto vas a tener bastante mejor experiencia que la media.

Pídelo por trozos. La tentación es describir la aplicación entera de una vez. Sale un churro. Pide la primera pantalla, compruébala, y luego la siguiente. Cada trozo que funciona es terreno ganado que ya no se pierde.

Guarda una copia cuando algo funcione. Antes de pedir el siguiente cambio grande, quédate con la versión que va bien. Estas herramientas suelen tener historial, pero no siempre te devuelve exactamente donde estabas. Una copia manual cuesta diez segundos y te salva la tarde.

Cuando entres en bucle, para. Si llevas cinco intentos y cada vez está peor, no sigas pidiendo. Vuelve a la última versión que funcionaba y describe el cambio de otra manera, más pequeño. Insistir con la misma frase es la forma más rápida de destrozar un proyecto que iba bien.

Mi regla, después de haberme comido lo anterior

Vibe coding para lo desechable, revisión para lo que dure.

Si lo que montas es una prueba, un juguete, una herramienta interna que puedes tirar, adelante y sin complejos. Es una manera fantástica de trabajar y ha abierto la puerta a muchísima gente que antes se quedaba fuera.

Si lo que montas va a tener usuarios, dinero o datos de otros, alguien tiene que leer lo que hay ahí. No hace falta que seas programador. Hace falta que sepas leer lo suficiente para revisar, que es una habilidad mucho más corta de aprender de lo que parece.

Y hay un punto intermedio que es donde yo vivo la mayor parte del tiempo: dejar que la IA escriba casi todo, pero decidir yo cómo está estructurado y leer los cambios antes de aceptarlos. Vas casi tan rápido y el proyecto no se te convierte en un edificio sin planos.

Si quieres ver cómo encaja esto con las herramientas donde no se escribe código en absoluto, la comparación está en no-code vs vibe coding. Y el mapa entero de opciones, en crear apps sin programar. Si no tienes claro qué conviene montar tú y qué no, tengo un test corto que te orienta en dos minutos.

Hacer el test de IA