El vibe coding es construir software describiendo en lenguaje natural lo que quieres y aceptando el código que genera la IA sin revisarlo a fondo. Sirve para llegar a algo que funciona en horas. Deja de servir en el momento en que ese algo toca dinero, datos personales o accesos de usuarios reales.
Esa es la respuesta corta. La larga tiene matices, porque el término se ha convertido en trinchera: o eres un creyente que enseña capturas de una app montada en un fin de semana, o eres el que dice que todo esto es un desastre. Ninguna de las dos posturas es útil si tu trabajo consiste en entregarle algo a un cliente.
¿De dónde viene el término “vibe coding”?
Lo acuñó Andrej Karpathy en febrero de 2025 en un mensaje en X. Su descripción era deliberadamente provocadora: dejarse llevar por las vibraciones, abrazar las exponenciales y “olvidar que el código siquiera existe”. Hablaba de proyectos de fin de semana, de cosas desechables, de no leer los diffs. La recopilación de fuentes y coberturas del término está en la entrada de Wikipedia sobre vibe coding (consultada en septiembre de 2026).
El matiz que se perdió por el camino es importante: Karpathy describía una forma de trabajar para cosas que no importan si se rompen. Un año y medio después, “vibe coding” se usa para describir la construcción de productos que sí importan. Ahí es donde empieza el problema.
Y ojo, el término se ha institucionalizado rápido: diccionarios lo han recogido como palabra del año. Eso dice mucho de la velocidad de adopción y nada de la calidad del resultado.
¿Qué herramientas se usan para hacer vibe coding?
Conviene separarlas, porque no hacen lo mismo y las agencias las mezclan en la misma frase.
| Herramienta | Qué es, según su documentación oficial | Dónde encaja |
|---|---|---|
| Lovable | Entorno que genera una app completa y la publica en una URL en vivo, con integración de base de datos y escáneres de seguridad integrados | Demo funcional con backend real |
| Bolt.new | “Una herramienta de IA que convierte tus ideas en webs y apps reales”, con base de datos y publicación propias | Demo funcional, iteración rápida |
| v0 (Vercel) | “Un agente de IA que ayuda a cualquiera a crear código real y apps full-stack”, con Next.js, Tailwind y shadcn/ui | Interfaces y prototipos que luego entran en un repo |
| Figma Make | “Herramienta de prompt-a-app impulsada por IA” que convierte ideas y diseños de Figma en prototipos funcionales publicables | Prototipo de diseño con comportamiento real |
| Cursor | Editor con agente para “construir software ambicioso”, con revisión de diffs y ejecución de comprobaciones | Trabajo continuado sobre un repositorio |
(Fuentes: documentación de Lovable, soporte de Bolt, documentación de v0, centro de ayuda de Figma y documentación de Cursor, todas consultadas en septiembre de 2026.)
Fíjate en la línea que separa la tabla por la mitad: las cuatro primeras te llevan de cero a una demo desplegada. La última asume que ya hay un proyecto y te ayuda a trabajar dentro de él. Son fases distintas del mismo problema, y confundirlas es la causa del 80% de los atascos que veo.
¿Por qué el vibe coding funciona tan bien al principio?
Porque la primera versión de cualquier software es, en su mayor parte, trabajo repetitivo. Formularios, tablas, rutas, estilos, un CRUD, una pantalla de login que parece una pantalla de login. Todo eso está escrito millones de veces en internet y un modelo lo reproduce con una fidelidad altísima.
Así que sí: en una tarde tienes una app con su navegación, su diseño decente y sus datos de prueba. Para una agencia esto es un cambio enorme. Puedes enseñarle al cliente algo que se toca en vez de un Figma estático, y puedes hacerlo dentro del presupuesto de la fase de propuesta. Eso es valor real, no humo.
El problema es que ese 80% visible es el 20% del trabajo. Lo que queda fuera de la demo es precisamente lo que hace que un software sea un producto: quién puede ver qué, qué pasa cuando el pago falla, dónde están los datos, quién se entera cuando algo se rompe a las tres de la mañana.
¿Dónde brilla el vibe coding?
Estos son los casos donde lo usaría sin dudarlo, y donde de hecho tiene todo el sentido del mundo para un equipo creativo:
- Prototipos para vender. Enseñar el flujo real en una reunión en vez de describirlo. Convierte muchísimo mejor que un PDF.
- Validar una idea antes de presupuestarla. Si el flujo no se sostiene ni en una demo, no se va a sostener en un proyecto de seis semanas.
- Herramientas internas de un solo uso. Un panel para que el equipo revise entregas, un conversor, un visor de datos que solo usáis vosotros y que no contiene nada sensible.
- Explorar una interfaz. Cinco variantes de una pantalla en el tiempo que antes costaba maquetar una.
- Aprender el terreno. Ver cómo se estructura una app de verdad es una forma rapidísima de entender de qué se habla en las reuniones técnicas.
En todos estos casos el coste de que el resultado esté mal por dentro es cero, porque nada depende de que esté bien.
¿Dónde te la juegas?
Aquí es donde toca ser claro, sin dramatizar. El riesgo no está repartido por igual: se concentra en cuatro sitios.
1. Permisos y control de acceso
Es el punto número uno. El control de acceso roto es la primera categoría del OWASP Top 10:2025 (consultado en septiembre de 2026), y es exactamente lo que una demo no puede enseñarte: en la demo tú eres el único usuario, así que todo lo que ves es lo que deberías ver.
Cuando la app usa una base de datos accesible desde el navegador, el modelo por defecto es peligroso. La propia documentación de Supabase sobre Row Level Security lo dice sin rodeos: “una tabla en un esquema expuesto sin RLS es legible y escribible por cualquier rol que tenga permiso sobre ella” (consultado en septiembre de 2026). Traducido: si nadie activó y escribió las políticas, cualquiera con la clave pública de tu app puede leer la tabla de clientes entera.
2. Secretos y configuración
Claves de API en el código del navegador, variables de entorno que acaban en el bundle, configuraciones de desarrollo publicadas tal cual. Es la segunda categoría del Top 10:2025, configuración de seguridad incorrecta. Una demo no falla por esto. Una app publicada, sí.
3. Dinero
Cobrar es la parte del software donde los errores no se pueden deshacer con un despliegue. Un webhook de pago que se procesa dos veces, un acceso que no se revoca cuando la suscripción caduca, un precio que se calcula en el navegador en vez de en el servidor. Nada de eso se ve en una demo porque en una demo nadie paga.
4. Lo que no existe hasta que se rompe
Logs, alertas, copias de seguridad, límites de uso. El fallo en el registro y las alertas de seguridad está en el Top 10:2025 por una razón: sin eso, no es que no puedas arreglar el problema, es que no te enteras de que existe.
¿Las propias herramientas no resuelven esto?
En parte, y hay que reconocérselo: lo están trabajando en serio. Lovable, por ejemplo, incluye escaneos que revisan políticas de RLS, el esquema de base de datos, dependencias con vulnerabilidades conocidas, secretos expuestos y control de acceso.
Pero su propia documentación pone el límite con una honestidad que agradezco: “estas herramientas ayudan a identificar problemas de seguridad comunes, pero no pueden garantizar una seguridad completa” y “no sustituyen una revisión de seguridad exhaustiva”. Y añade la frase que debería estar enmarcada en toda agencia: “eres responsable de asegurar que tu app cumple los requisitos de seguridad apropiados para su caso de uso” (documentación de seguridad de Lovable, consultada en septiembre de 2026).
Eso no es letra pequeña defensiva. Es una descripción exacta de dónde acaba la herramienta y dónde empieza el criterio. Un escáner estático encuentra lo que ya sabe buscar; no sabe que en tu modelo de negocio un usuario del plan básico no debería poder descargar el informe completo.
Vibe coding con criterio de ingeniero
La postura que defiendo no es “no uses IA”. Es la contraria: úsala a fondo, y cambia dónde pones tu atención.
Construir sin entender es fracaso con buena pinta. Una app generada que funciona en la demo y se cae en el primer cliente real no es un ahorro de tiempo, es una deuda con intereses y con tu nombre encima. Y si la agencia es la cara ante el cliente final, la factura emocional la pagas tú, no el modelo.
Lo que cambia con la IA no es que trabajes menos. Es qué parte del trabajo es tuya:
- Antes: escribir el código era el cuello de botella; revisar era barato en comparación.
- Ahora: generar es casi gratis; juzgar es el cuello de botella. Decidir qué está bien, qué falta y qué no puede salir así.
Esto no es una metáfora bonita. Es un cambio de reparto de horas en un presupuesto. Si vendes un proyecto asumiendo que la IA te ahorra el 70% del tiempo y no reservas horas para revisión, arquitectura y puesta en producción, ese proyecto va a perder dinero.
¿Qué hago con la demo que ya tengo?
Si has llegado hasta aquí probablemente ya tienes una app generada, funciona, y la pregunta no es filosófica sino práctica: qué le falta.
La lista corta, que desarrollo entera en de prototipo con IA a producción:
- Autenticación y permisos de verdad, verificados en el servidor.
- Una base de datos con dueño, copias de seguridad y una restauración probada.
- Pagos y accesos que se sincronizan solos, incluidos los fallos.
- Límites de uso y protección contra abuso.
- Logs y alertas en todo lo que toque dinero o datos.
- Costes previsibles.
- Propiedad del código y del stack a nombre de quien corresponde.
Y antes de nada, una revisión del código que ya existe: qué mirar y en qué orden está en cómo revisar el código generado por IA.
Si lo que descubres al revisar es que el prototipo no aguanta y hay que reconstruir la parte crítica, ese camino tiene su propio recorrido, muy parecido al de pasar de no-code a software a medida: no se tira todo, se sustituye la pieza que ya no aguanta.
Lo que le diría a una agencia que acaba de descubrir esto
Tres cosas.
Una: seguid usándolo. Es la mejor herramienta de venta y de validación que habéis tenido nunca. Un prototipo que se toca cierra proyectos.
Dos: no vendáis la demo como producto. Vended la demo como demo y el producto como producto, con dos presupuestos, dos plazos y dos alcances. La conversación honesta con el cliente es más fácil de tener antes que después.
Tres: decidid quién hace la parte que la demo no cubre. Puede ser alguien de vuestro equipo, puede ser un socio técnico. Lo que no puede es no estar decidido, porque el día que el cliente pregunte “¿esto está listo para lanzar?” alguien va a tener que responder.
¿Te has quedado atascado en la demo?
Si tienes un prototipo hecho con Lovable, Bolt, v0 o Figma Make que funciona y no sabes qué le falta para poder facturarlo, eso es exactamente el trabajo que hago: coger lo que ya existe, decirte qué se aprovecha y qué no, y llevarlo a producción con permisos, pagos, datos y observabilidad de verdad. También en white label, de forma que la agencia sigue siendo la cara ante su cliente.
Cuéntame en qué punto está tu prototipo y te digo sin rodeos qué falta. Si lo que buscas es que alguien construya la versión sólida, está en software a medida; si lo que necesitáis es un equipo técnico detrás de forma continuada, en partner tecnológico.
Preguntas frecuentes
¿Qué significa vibe coding exactamente?
Describir en lenguaje natural lo que quieres que haga un programa y dejar que un modelo de IA escriba el código, aceptándolo sin revisarlo línea a línea. El término lo acuñó Andrej Karpathy en febrero de 2025 y describe una actitud ante el código, no una herramienta concreta.
¿El vibe coding sirve para producción?
Sirve para llegar a algo que funciona muy rápido. No sirve, por sí solo, para sostenerlo cuando toca dinero, datos personales o accesos. Ahí hacen falta permisos reales, control de errores, observabilidad y alguien que entienda por qué funciona lo que se ha generado.
¿Lovable, Bolt, v0, Figma Make y Cursor son lo mismo?
No. Lovable, Bolt, v0 y Figma Make son entornos de prompt-a-app que generan y alojan una aplicación completa; Cursor es un editor de código con agente, pensado para trabajar sobre un repositorio existente. Los primeros te llevan a la demo; el segundo te acompaña en el mantenimiento.
¿Es peligroso publicar una app hecha con vibe coding?
Depende de qué toque. Una landing o una demo interna, no. Una app con login, base de datos o pagos publicada sin revisar permisos y secretos sí es un riesgo real: la propia documentación de estas herramientas avisa de que sus escaneos automáticos no sustituyen una revisión de seguridad.
¿Entonces no hay que usar estas herramientas?
Al contrario. Son excelentes para lo que son: explorar una idea, validar un flujo con un cliente o enseñar algo tangible en una reunión. El error no es usarlas, es confundir la demo que producen con un producto listo para facturar.
