Vibe coding: qué es, de dónde viene y cuándo tiene sentido

El vibe coding es crear software pidiéndoselo a una IA sin leer el código. De dónde viene, cuándo funciona, casos reales de fallos y cómo hacerlo bien.

10 min

El vibe coding es una forma de crear software en la que describes lo que quieres a una IA, aceptas el código que escribe sin leerlo y juzgas el resultado solo por si funciona. El término lo acuñó Andrej Karpathy en febrero de 2025 y en noviembre ya era la palabra del año del diccionario Collins. Tiene sentido para prototipos, herramientas personales y proyectos de usar y tirar; es peligroso en cuanto hay datos de otras personas, dinero o usuarios reales, como demuestran varios casos documentados que repasamos aquí.

De dónde viene el término

El 2 de febrero de 2025, Andrej Karpathy (cofundador de OpenAI y exdirector de IA de Tesla) publicó este mensaje en X. Traducido:

«Hay un nuevo tipo de programación que llamo “vibe coding”, en el que te dejas llevar por completo por las sensaciones, abrazas los exponenciales y olvidas que el código siquiera existe. […] Siempre le doy a “Aceptar todo”, ya no leo los diffs. Cuando me salen mensajes de error, los copio y pego sin comentarios, y normalmente eso lo arregla. El código crece más allá de lo que suelo entender. […] No está mal para proyectos desechables de fin de semana, pero sigue siendo bastante divertido».

Fíjate en lo que dice el propio autor: proyectos desechables de fin de semana. La definición original ya traía su límite.

El término se extendió muy rápido. Merriam-Webster lo recogió en marzo de 2025 en su sección de jerga y tendencias, Collins lo eligió palabra del año 2025 y en septiembre de 2026 Merriam-Webster lo incorporó a su diccionario general. En español no hay traducción asentada: a 8 de octubre de 2026, la FundéuRAE no ha emitido recomendación, y se usa en inglés.

Un año después, Karpathy hizo balance. Recordó que aquel mensaje fue una ocurrencia «sin pensar», que entonces los modelos solo daban para proyectos de diversión, demos y exploraciones, y que en 2026 programar con agentes se está convirtiendo en el flujo habitual de los profesionales, «pero con más supervisión y escrutinio». Para eso propuso otro nombre, agentic engineering: orquestar agentes que escriben el código mientras tú supervisas, con oficio y criterio. Es decir, lo contrario de olvidar que el código existe.

Qué es exactamente (y qué no)

La definición más útil es la del programador y divulgador Simon Willison: vibe coding es «construir software con un modelo de lenguaje sin revisar el código que escribe». Y añade el matiz importante: si la IA escribe el código pero tú lo revisas, lo pruebas y puedes explicar cómo funciona, eso no es vibe coding, es desarrollo de software.

Vibe codingProgramar con IA
¿Quién escribe el código?La IASobre todo la IA
¿Lees lo que cambia?NoSí, cada diff
¿Cómo sabes si está bien?Lo usas y miras si funcionaTests, revisión y comprobaciones
¿Quién entiende el código?Nadie, en rigorTú
¿Para qué sirve?Prototipos y herramientas de usar y tirarCualquier proyecto, también en producción

Las herramientas pueden ser las mismas. Lo que cambia es la actitud. Si quieres el método del lado derecho de la tabla, lo tienes en la guía para programar con IA.

¿Cuánta gente lo hace en el trabajo? Poca, según la encuesta de Stack Overflow de 2025: el 72 % de los desarrolladores dice que el vibe coding no forma parte de su trabajo profesional, y otro 5 % lo niega con énfasis. Eso sí, el 84 % usa o piensa usar herramientas de IA. La IA se ha normalizado en el oficio; aceptar código sin leerlo, no.

Cuándo tiene sentido

El vibe coding funciona cuando equivocarse sale casi gratis. Willison lo resume en un consejo: los proyectos tienen que ser de bajo riesgo. Algunos casos claros:

  • Prototipos para enseñar una idea en una reunión o validarla con cuatro usuarios de confianza.
  • Herramientas personales: un script que renombra fotos, una página que calcula la hipoteca, un panel con tus propios datos.
  • Explorar: ver qué se puede hacer con una librería o una API antes de decidir si merece la pena.
  • Cosas de usar y tirar: la web de un cumpleaños, una demo para un evento.

En todos estos casos da igual que el código sea feo o frágil. Lo que importa es tener algo funcionando en una tarde en lugar de en una semana. Y para mucha gente que no programa, es la primera vez que puede construir algo propio, lo cual tiene un valor enorme.

Cuándo es peligroso: casos documentados

Los problemas empiezan cuando lo que era un prototipo se conecta a datos reales o lo usa gente de verdad. Estos casos están documentados con fuentes; no son hipótesis.

La base de datos borrada de Replit (julio de 2025)

Jason Lemkin, fundador de la comunidad SaaStr, documentó en X un experimento de varios días creando una aplicación con el agente de Replit. En pleno «congelamiento de código», con instrucciones explícitas de no tocar nada, el agente borró la base de datos de producción. Según contó Business Insider, se perdieron los registros de más de 1.200 directivos y más de 1.100 empresas, y el agente había generado antes datos de personas que no existían. «Se lo dije explícitamente once veces en MAYÚSCULAS», escribió Lemkin (The Register). Al día siguiente descubrió que la restauración de Replit sí recuperaba los datos, aunque el agente le había asegurado que era imposible. El consejero delegado de Replit, Amjad Masad, respondió que era «inaceptable y no debería ser posible» y anunció la separación automática entre bases de datos de desarrollo y de producción.

La lección no es que un agente concreto sea malo. Es que una instrucción en el chat no es una barrera: si el agente tiene acceso a producción, puede romperla.

Las bases de datos abiertas de Lovable (2025)

En marzo de 2025, el ingeniero Matt Palmer analizó 1.645 aplicaciones creadas con Lovable y encontró que 170 de ellas (un 10,3 %) tenían mal configurados los permisos de su base de datos (la llamada Row Level Security de Supabase). Cualquiera podía leer, y en algunos casos escribir, nombres, correos, datos de pago y claves de API (declaración de Palmer). El fallo se registró como CVE-2025-48757. Lovable lo discute: sostiene que cada cliente es responsable de proteger los datos de su aplicación. Y hay que decir que Palmer trabaja en Replit, competidor de Lovable.

Más allá de quién tenga razón, el patrón es el importante: aplicaciones que «funcionan» perfectamente para su creador y dejan los datos de sus usuarios a la vista de cualquiera.

Moltbook (principios de 2026)

El fundador de Moltbook, una red social para agentes de IA, presumió en X de no haber escrito «ni una sola línea de código». La empresa de seguridad Wiz descubrió que su base de datos daba acceso completo de lectura y escritura a cualquiera: 1,5 millones de tokens de API, 35.000 correos y mensajes privados. Lo arreglaron en horas tras el aviso, pero el fallo era el mismo que el de Lovable.

Agentes que borran lo que no deben

Los agentes con acceso a la terminal también se equivocan con tus archivos. Hay denuncias de usuarios documentadas en los repositorios públicos de las herramientas: en julio de 2025, un usuario de Gemini CLI contó que el agente perdió sus archivos al moverlos (issue 4586); en octubre de 2025, otro denunció que Claude Code borró su directorio personal (issue 10077); y en noviembre de 2025, un usuario de Google Antigravity contó que el agente vació una unidad entera de su disco al pedirle que limpiara una caché (TechRadar). Son relatos de los afectados, sin análisis oficial publicado, pero todos comparten una causa: el agente podía ejecutar comandos destructivos sin pedir confirmación.

Lo que dicen los estudios

  • Seguridad. Veracode probó más de 100 modelos y en 2025 el 45 % del código generado fallaba sus pruebas de seguridad e introducía vulnerabilidades del OWASP Top 10 (Veracode, julio de 2025). En su informe de 2026, la tasa media de código seguro sigue en el 56 %: «no se ha movido» (Veracode, 2026).
  • Productividad. En un experimento de METR de 2025, 16 programadores expertos tardaron un 19 % más en sus tareas con IA, aunque creían haber ido un 20 % más rápido (METR, julio de 2025). La propia METR marca hoy ese resultado como desfasado: con datos de finales de 2025 estima que la IA ya acelera el trabajo, aunque lo considera «evidencia muy débil» (METR, febrero de 2026). La lección que sigue vigente: la sensación de ir rápido no es una medida.

Herramientas típicas de vibe coding

Cualquier asistente de código sirve para hacer vibe coding, pero hay una familia de herramientas pensadas para que no tengas que abrir un editor: describes la aplicación en un chat y la ves funcionando en el navegador, con base de datos y publicación incluidas.

Lovable crea webs y aplicaciones web completas desde un chat, con base de datos (Supabase). Bolt.new, de StackBlitz, hace aplicaciones web en el navegador con el código editable. La de Vercel, v0, genera interfaces y apps web completas a partir de un chat. Replit es un entorno completo en la nube con agente, base de datos y publicación. El modo Build de Google AI Studio genera apps web con Gemini. Y Base44, de Wix, crea apps sin código a partir de un chat.

Sus precios oficiales, en dólares y sin impuestos, a 8 de octubre de 2026:

HerramientaGratisPrimer plan de pago
Lovable5 créditos al día, hasta 30 al mesPro: 25 $/mes (21 $ anual)
Bolt.newSí, con límite de tokens diario y mensualPro: 25 $/mes
v0Sí, con créditos diariosPlus: 30 $/mes por usuario
ReplitStarter, con créditos limitadosCore: 20 $/mes (18 $ anual)
Google AI StudioSí, gratuitoSolo con una clave de API de pago
Base4425 créditos de mensajes al mesStarter: 16 $/mes con pago anual

Es un negocio enorme: Lovable cerró en agosto de 2026 una ronda con una valoración de 13.300 millones de dólares y asegura ingresos anualizados de 500 millones (TechCrunch). Ojo con Firebase Studio, de Google: su web anuncia que cierra el 22 de marzo de 2027 y ya no deja crear espacios de trabajo nuevos.

Si prefieres trabajar con un agente sobre tu propio código (Claude Code, Cursor, Codex o Copilot), la comparativa de cuál elegir tiene precios y diferencias.

Cómo hacer vibe coding con cabeza

Nada de lo anterior significa que no debas hacerlo. Significa hacerlo sabiendo dónde están los riesgos. Estas reglas evitan los fallos de los casos de arriba:

  1. Decide antes de empezar qué te juegas. Si el proyecto va a tocar datos de otras personas, pagos o cuentas de usuario, no es un proyecto para vibe coding puro.
  2. Git desde el primer minuto. Un commit cada vez que algo funciona. Cuando la IA rompa tres cosas al arreglar una, vuelves atrás en un segundo.
  3. Nunca le des acceso a producción. Trabaja con datos de prueba y una base de datos aparte. Lo de Replit pasó porque el agente podía tocar la base de datos real.
  4. Permisos y confirmaciones. Si usas un agente en tu ordenador, que pida permiso antes de borrar o ejecutar comandos fuera del proyecto. Los modos que se saltan todas las comprobaciones, solo dentro de un contenedor.
  5. Activa la seguridad de la base de datos. Si tu app usa Supabase (como Lovable o Bolt), comprueba que cada tabla tiene Row Level Security activada y reglas por usuario.
  6. Ninguna clave en el navegador. Las claves de API que cuestan dinero (OpenAI, Stripe, Google Maps) van en el servidor, nunca en el código que descarga el usuario. Si se te escapa una, revócala.
  7. Pide una auditoría antes de publicar. Una sesión nueva, con este prompt:
Revisa este proyecto como si fueras un atacante. Busca: tablas de la
base de datos que se puedan leer o modificar sin iniciar sesión,
claves de API visibles en el código del navegador, formularios que
no validan lo que reciben y rutas que deberían exigir permisos y no
lo hacen. Para cada problema, dime archivo, riesgo y cómo arreglarlo.
No cambies nada todavía.

No sustituye a una persona que sepa de seguridad, pero detecta lo obvio, que es justo lo que falló en Lovable y en Moltbook.

Cuando el prototipo empieza a tener usuarios

Si algo hecho a base de vibe coding empieza a usarlo gente de verdad, no hace falta tirarlo. Hace falta cambiar de modo:

  • Lee el código, o pide a la IA que te lo explique archivo por archivo hasta que lo entiendas.
  • Añade tests de lo que no puede fallar: el registro, el pago, los permisos.
  • Revisa la seguridad con la lista de arriba, y si hay datos personales, con alguien que sepa.
  • Ordena antes de crecer. Es mucho más barato reorganizar mil líneas que diez mil.

A partir de ahí ya no es vibe coding: es programar con IA, con los hábitos que mantienen el control. Y si lo que quieres es sacar a internet una web pequeña hecha así, en publicar una web gratis tienes las opciones.

Preguntas frecuentes

¿Cómo se dice vibe coding en español?

No hay una traducción asentada. A 8 de octubre de 2026, la FundéuRAE no ha publicado ninguna recomendación sobre el término, y en los medios se usa casi siempre en inglés. Si lo explicas, «programar a base de sensaciones» o «programar sin mirar el código» transmiten la idea.

¿Hace falta saber programar para hacer vibe coding?

Para un prototipo o una herramienta personal, no. Para cualquier cosa que maneje datos de otras personas, pagos o cuentas de usuario, sí: alguien tiene que poder leer el código, entender qué datos expone y responder por él.

¿Puedo publicar una app hecha con vibe coding?

Puedes, pero antes de abrirla a otros conviene revisar la seguridad: que la base de datos tenga permisos por usuario, que no haya claves en el código del navegador y que los formularios validen lo que reciben. Los fallos más conocidos del vibe coding vienen de saltarse esa revisión.

Escrito por

Equipo editorial

No te pierdas nada.

Lo importante de la semana en IA, en un email que se lee en cinco minutos.