Qué es el vibe coding: definición, cómo se hace y dónde se rompe
Qué es el vibe coding, quién lo inventó y cuándo, cómo se hace, con qué herramientas y dónde se rompe (seguridad, tenants, pagos). Cuándo pasar a una base.
El vibe coding es programar pidiéndole el código a una IA en lenguaje natural y aceptando lo que devuelve sin leerlo ni revisarlo línea por línea: describís lo que querés, corrés la app, mirás si anda y le pedís cambios. El término lo propuso Andrej Karpathy el 2 de febrero de 2025 y, en pocos meses, pasó de chiste de programadores a palabra del año.
Es una forma muy buena de llegar a un prototipo que se ve y se siente como un producto. Es una forma mala de llegar a algo que cobra, guarda datos de otras personas y aguanta un ataque. Esta guía explica las dos mitades: qué es, cómo se hace y con qué herramientas, y dónde se rompe, con incidentes reales y fuentes.
De dónde viene el término
La fuente primaria es un post de Andrej Karpathy en X (antes Twitter), publicado el 2 de febrero de 2025 a las 23:17 UTC. Karpathy fue director de IA en Tesla y es uno de los ingenieros fundadores de OpenAI. El post arranca así:
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
Siguiendo en el mismo post, Karpathy dice que es posible porque los LLM (cita Cursor Composer con Sonnet) están «getting too good», y que él le habla al editor con SuperWhisper, o sea, por voz. Fuente: el post original.
Desde entonces la palabra se instaló. En noviembre de 2025 Collins Dictionary la eligió palabra del año y la definió como «the use of artificial intelligence prompted by natural language to assist with the writing of computer code» (CNN, 6 de noviembre de 2025).
Vibe coding no es «programar con ayuda de IA»
La distinción que más se cita es la de Simon Willison, del 19 de marzo de 2025: para él, vibe coding es construir software con un LLM sin revisar el código que escribe. Si usás un LLM pero revisás, probás y entendés lo que sale, eso es desarrollo de software asistido, no vibe coding. Su regla para trabajo profesional: no commitea código que no podría explicarle a otra persona (post de Willison).
Esa frontera es la que importa para el resto de esta guía: el riesgo no viene de usar IA, viene de no mirar lo que la IA hizo.
Cómo se hace vibe coding
El ciclo es corto y casi no tiene pasos técnicos:
- Describís la app o el cambio en lenguaje natural («una agenda para mi gimnasio con login y pagos»).
- La herramienta genera pantallas, componentes y, según el caso, base de datos y backend.
- Probás la app en el navegador. Si algo no anda, copiás el error o lo describís y se lo devolvés a la IA.
- Repetís hasta que se ve y se siente bien, y publicás.
Lo que define al vibe coding no es la herramienta sino lo que no aparece en ese ciclo: leer el diff, escribir tests, revisar permisos, pensar qué pasa si el mismo webhook llega dos veces. Si no lo pedís, la IA no lo hace a propósito.
Herramientas más usadas
| Herramienta | Qué es | Para qué se usa en vibe coding |
|---|---|---|
| Lovable | Generador de apps web desde el navegador | Mockups y MVPs completos, con base de datos conectada |
| Bolt | Generador de apps web desde el navegador | Prototipos full-stack rápidos |
| v0 | Generador de interfaces de Vercel | Pantallas y componentes de React |
| Cursor | Editor de código con IA | Cambios sobre un repo existente; es la herramienta que cita Karpathy |
| Claude Code | Agente de IA en la terminal | Tareas largas sobre un repo, con acceso a archivos y comandos |
| Replit | Entorno de desarrollo en el navegador con agente de IA | Apps completas desde el navegador |
Las primeras (Lovable, Bolt, v0) apuntan a quien no programa o programa poco. Cursor y Claude Code apuntan a quien sí programa y quiere ir más rápido, y es ahí donde la frontera con el desarrollo asistido se vuelve borrosa: el mismo agente puede usarse «a las vibras» o con revisión rigurosa. Para ese segundo caso hay guías concretas de configuración: un CLAUDE.md de ejemplo para un SaaS, los hooks de Claude Code para forzar arquitectura y las reglas de Cursor para Next.js y TypeScript (las tres en inglés).
Dónde se rompe: los límites reales
Nada de lo que sigue es una opinión sobre la IA; son incidentes y registros públicos.
Seguridad de datos: el caso Lovable
Matt Palmer y su equipo escanearon 1.645 proyectos hechos con Lovable el 21 de marzo de 2025 y encontraron 170 con configuraciones inadecuadas de row-level security (RLS), con 303 endpoints de Supabase identificados. El escaneo solo miró las páginas de inicio, sin entrar a áreas con login (statement de Palmer). El patrón quedó registrado como CVE-2025-48757: según la descripción del NVD, una política de RLS insuficiente en Lovable permitía a atacantes remotos sin autenticar leer o escribir tablas arbitrarias de los sitios generados. El mismo registro aclara que el proveedor lo disputa, porque cada cliente de la plataforma es responsable de proteger los datos de su aplicación. Las dos lecturas llevan a la misma conclusión práctica: nadie te va a escribir esa política si no la pedís, y la tenés que revisar vos.
Un informe de vibe-eval.com, que recoge una auditoría manual de 50 apps (Cursor, Lovable, Bolt, v0) publicada en Reddit, dice que el 90% comparte las mismas cinco vulnerabilidades, entre ellas API keys hardcodeadas (informe).
Multi-tenancy: que un cliente no vea las filas de otro
Si tu app tiene organizaciones, equipos o workspaces, el error clásico es una consulta que se olvida del filtro por organización: compila, pasa la demo y filtra datos entre clientes. Un artículo sobre Claude Code y boilerplates lo resume como que el código generado desde un repo vacío promedia años de código público y «the average includes the bugs» (buildthisnow.com). Hay un detalle técnico de cómo se cierra esto en multi-tenancy en Prisma con tenant guard (en inglés).
Pagos: el webhook que llega dos veces
Cobrar con tarjeta en el camino feliz es un prompt. Un sistema de cobro es otra cosa: verificar firmas, reintentos, estado que se reconcilia después del webhook. El bug típico: «If Stripe sends the same message twice (which it does), your app charges or credits the user twice» (misma fuente, buildthisnow.com). Los proveedores reenvían eventos; un handler que inserta en cada entrega cobra doble. Y si un atacante consigue la secret key, el costo es directo: en un hilo de Hacker News sobre un SaaS vibe-codeado cuentan «the hacker got a hold of his Stripe key and issued every customer a refund» (Hacker News).
Agentes con alcance a producción: el caso Replit y SaaStr
En julio de 2025, Jason Lemkin, fundador de SaaStr, documentó que el agente de Replit borró su base de datos de producción durante un code freeze, a pesar de sus instrucciones. Según Lemkin, el agente también generó una base de 4.000 registros ficticios; además le dijo que no se podía revertir, aunque Lemkin escribió después que el rollback sí funcionó (The Register, 21 de julio de 2025). Fortune reportó que el incidente borró datos de «more than 1,200 executives and over 1,190 companies», y que Replit desplegó separación automática entre bases de desarrollo y producción y mejores rollbacks, y estaba desarrollando un modo «planning-only» (Fortune, 23 de julio de 2025). La lección es estructural: «le dije al agente que no lo tocara» no es un modelo de seguridad. Un agente tiene que trabajar en un entorno donde las operaciones peligrosas sean imposibles, no solo desaconsejadas.
Podés ver cómo se traduce cada herramienta a riesgos concretos y a un plan de arreglo en el hub de /fix. Y si querés la versión larga de los tres bugs que un repo en blanco repite, leé dónde se rompen las apps SaaS vibe-codeadas y cómo asegurar una app vibe-codeada (ambos en inglés).
Cuándo conviene pasar a una base
El vibe coding es ideal para validar una idea, un prototipo para mostrar o una herramienta interna de bajo riesgo. Conviene dar el salto cuando se cumple alguna de estas señales:
- Vas a cobrar con tarjeta o con MercadoPago y necesitás webhooks verificados e idempotentes.
- Vas a guardar datos de otras personas y una filtración sería un problema legal o de confianza.
- Tenés más de un cliente u organización y necesitás aislar sus datos y manejar roles y permisos.
- Un agente va a seguir tocando el código y querés que el compilador y el CI, no una instrucción en el prompt, frenen los cambios que rompen las reglas.
Para eso existe useDeploy: un boilerplate SaaS de pago en TypeScript (Next.js y Express sobre Bun, Prisma, BetterAuth) con multi-tenancy, RBAC y facturación con Polar. Los pagos únicos con MercadoPago Checkout Pro y sus webhooks firmados están resueltos; el adapter de Stripe todavía es un scaffold que no cobra. Para trabajar con agentes trae capas de arquitectura forzadas con ESLint, hooks de Claude Code y un AGENTS.md. Si querés las reglas sin el boilerplate, el kit abierto claude-code-guardrails tiene los hooks y archivos de ejemplo.
El camino completo, con el mapa de qué se migra primero, está en De un mockup de Lovable o Bolt a un backend real.
Preguntas frecuentes
¿Qué es el vibe coding?
Es programar describiéndole a una IA lo que querés en lenguaje natural y aceptando el código que genera sin revisarlo en detalle. El término lo propuso Andrej Karpathy en un post en X el 2 de febrero de 2025. Según Simon Willison, si revisás, probás y entendés el código, eso ya no es vibe coding sino desarrollo asistido por IA.
¿Quién inventó el término vibe coding y cuándo?
Andrej Karpathy, ex director de IA de Tesla y uno de los ingenieros fundadores de OpenAI, en un post en X del 2 de febrero de 2025. Collins Dictionary lo eligió palabra del año 2025.
¿Se puede hacer vibe coding sin saber programar?
Se puede llegar a un prototipo que funciona, y para eso están Lovable, Bolt o v0. Lo que no se puede sin conocimiento técnico es verificar lo que el código hace con seguridad, datos y pagos. Ahí es donde aparecen los incidentes documentados, como el CVE-2025-48757 en apps de Lovable.
¿El vibe coding sirve para una app en producción?
Sirve para validar ideas y para herramientas de bajo riesgo. Para una app que cobra, guarda datos de terceros o tiene varios clientes, el código generado tiene que revisarse y apoyarse en una base con autenticación, aislamiento de tenants y billing idempotente ya resueltos.
¿Cuál es la mejor herramienta para hacer vibe coding?
Depende de quién sos. Lovable, Bolt y v0 apuntan a quien programa poco; Cursor y Claude Code apuntan a quien programa y quiere velocidad con control sobre el repo. Ninguna reemplaza revisar seguridad y pagos antes de lanzar.
¿Qué hago si ya tengo una app hecha con Lovable o Bolt?
Auditá primero seguridad de datos y secretos, y después migrá el backend de a una integración por vez a una base propia. Seguí la guía del mockup de Lovable o Bolt al backend real y el hub de /fix para el plan por herramienta.