Hay una escena que cualquier persona de producto reconoce: tienes una idea clara, sabes exactamente cómo se vería la pantalla, sabes qué información tendría y qué pasaría cuando alguien hace clic. Lo único que te falta es el código. Y para conseguir ese código, dependes de un equipo de ingeniería que tiene su propia agenda, sus propios sprints y diez prioridades por encima de tu mockup. La idea queda flotando en una presentación, en un Figma, en un documento. Cuando finalmente alguien la construye, la oportunidad de validarla con usuarios ya pasó.
Esa brecha entre tener una idea de producto y tener algo funcional para mostrar es la que vibe coding está cerrando. Y lo está haciendo más rápido que casi cualquier otra práctica nueva en la industria. El tema pasó de no existir a tener decenas de miles de búsquedas mensuales en español en menos de un año. La adopción se sostiene porque resuelve un problema concreto: personas que no programan están construyendo cosas que funcionan.
Este artículo cubre qué es vibe coding y de dónde salió el término, cómo funciona en la práctica, las herramientas que lo están haciendo posible, por qué es una habilidad de producto y no de ingeniería, qué se puede construir realmente con esto hoy, dónde están sus límites, y cómo empezar si nunca lo hiciste.
Qué es vibe coding y de dónde sale el término
El término vibe coding lo acuñó Andrej Karpathy, ex director de IA de Tesla y miembro fundador de OpenAI, a principios de 2025. En un tweet que se volvió la referencia obligada para definir la práctica, lo describió como una nueva forma de programar donde "te entregas a las vibras, abrazas las exponenciales y te olvidas de que el código siquiera existe". La frase suena casual, pero captura un cambio profundo: la actividad central se desplaza desde escribir sintaxis hacia describir intención.
Vibe coding es construir software describiendo en lenguaje natural lo que quieres que haga, y dejando que un modelo de IA escriba (y reescriba) el código por ti. Tú no abres un editor para leer líneas de JavaScript. Tú dices "quiero una landing page con tres secciones, hero arriba, tres beneficios al medio y un formulario de email abajo, fondo crema, tipografía serif". El modelo lo construye, lo despliega y te devuelve un link. Si algo no te gusta, dices "el botón es muy chico, hazlo el doble de grande" y se ajusta. El bucle de iteración es conversacional.
Conviene distinguir vibe coding de prácticas vecinas con las que a veces se confunde. El autocompletado de código, lo que hace GitHub Copilot en su modo clásico, sugiere líneas mientras un programador escribe dentro de su editor. Los AI Coding Agents como Cursor (en modo agent o Composer), Claude Code y sus alternativas open source operan sobre un codebase con autonomía: leen archivos, escriben código, ejecutan comandos, debuggean. Viven dentro de un entorno de desarrollo y asumen literacia técnica de quien los maneja. Vibe coding ocurre en un plano distinto a esas dos categorías: el código sigue existiendo, pero queda relegado al fondo. Tu interfaz primaria con el sistema pasa a ser la conversación, y lo que sale es un producto desplegado y compartible, no un repositorio que después hay que deployar.
Esa distinción importa porque cambia quién puede hacer la actividad. Para escribir código, hace falta saber escribir código. Para hacer vibe coding, hace falta saber describir lo que quieres con la suficiente claridad como para que una máquina lo pueda construir. Esa segunda habilidad la gente de producto ya la entrena todos los días: cuando escribe specs, cuando dibuja flujos en Figma, cuando describe un comportamiento esperado a un equipo.
Cómo funciona en la práctica: describir, generar, iterar
La mecánica de vibe coding es un bucle de tres pasos que se repite hasta que el resultado te conforma. Entender el bucle es entender la práctica.
Describir. Empiezas con un prompt en lenguaje natural. La calidad de ese prompt es proporcional a la calidad del resultado, igual que con cualquier otro uso de LLMs. Decir "construye una app de tareas" da un resultado genérico y poco útil. Decir "construye una app de una sola pantalla, fondo blanco, donde haya una lista de tareas a la izquierda con checkboxes circulares, un input arriba para agregar tareas nuevas con tecla enter, y un contador de tareas pendientes en la esquina superior derecha; usa tipografía Inter y colores neutros" da un resultado mucho más cercano a lo que estás imaginando.
La regla práctica acá: vale la pena describir layouts, interacciones, datos y restricciones, no solo el "qué" general. Cada pieza de claridad que pones en el prompt es una decisión que el modelo no tiene que adivinar.
Generar. El sistema produce el código, monta el entorno, despliega la aplicación y te da un link funcional. El resultado es una aplicación real corriendo en una URL, con sus inputs operativos, su navegación funcional y sus formularios enviando datos. La diferencia con un mockup estático en Figma es de naturaleza: lo que ves es el producto en una versión simple pero ejecutable. Figma muestra cómo se vería; vibe coding muestra cómo funciona.
El tiempo entre el prompt y la app con los cambios realizados se mide en decenas de segundos para casos simples, en algunos minutos para casos más complejos. Esa velocidad es lo que vuelve viable la siguiente parte del bucle.
Iterar. Acá es donde el flujo se aleja por completo de la programación tradicional. Tú no abres el código a corregir nada. Le dices al sistema en lenguaje natural lo que quieres cambiar: "el contador no está bien posicionado, movelo al header"; "agregale un estado vacío con una ilustración cuando no hay tareas"; "quiero que las tareas completadas pasen a una sección distinta colapsada por defecto". El modelo lee el código que él mismo generó, identifica dónde tiene que tocar y reescribe lo necesario. Tú validas en el browser y sigues iterando.
Este bucle puede correrse cinco veces o cincuenta. Lo que define cuándo parar es un criterio de producto: ¿este prototipo me sirve para validar lo que necesito validar? Si la respuesta es sí, paras. Si todavía hay algo que no comunica bien, sigues iterando.
Las herramientas que dominan el mercado hoy
El espacio de vibe coding se está consolidando rápido alrededor de algunas herramientas. Cada una tiene un foco distinto, y elegir bien según el caso ahorra mucho tiempo.
Lovable. Es la herramienta de referencia hoy para construir aplicaciones completas con vibe coding. Apunta al caso amplio: frontend, backend, base de datos, autenticación y despliegue, todo construido desde una conversación. En 2026 se consolidó como la opción favorita de PMs y fundadores no técnicos que quieren validar productos completos sin tocar código, con más de 8 millones de usuarios y un ritmo de adopción que la convirtió en uno de los productos de software de mayor crecimiento de la industria. Si tu caso es construir una app de extremo a extremo y quieres un solo lugar donde todo viva, este es el punto de entrada.
v0 (de Vercel). Empezó como generador de componentes de UI puro y en 2026 sumó runtime de servidor, conexiones a bases de datos y despliegues con un click. Genera componentes en React con Tailwind, despliega en segundos y tiene una calidad visual notablemente alta. Brilla cuando el corazón del prototipo es la capa de UI o cuando ya estás trabajando dentro del stack de Next.js.
Bolt (de StackBlitz). Corre íntegramente en el navegador, sin necesidad de infraestructura externa. Es muy rápido para iteración en frío y útil cuando estás explorando ideas a alta velocidad sin querer ensuciar tu workspace de proyectos.
Replit Agent. El más generalista. Soporta múltiples lenguajes y casos más allá del frontend web (scripts, automatizaciones, backends simples). La curva es un poco más alta pero el techo es mayor cuando lo que quieres construir se sale del molde de la app web tradicional.
La regla práctica que vale para casi todos los casos de producto: empezar por Lovable si quieres validar un producto completo de extremo a extremo sin involucrar a un equipo técnico, y considerar v0 si lo que necesitas es UI de muy alta calidad o ya estás trabajando dentro del ecosistema de Next.js. Probar dos o tres herramientas antes de comprometerse con una está bien, pero el mayor retorno está en dominar una a fondo.
AI Coding Agents: cuándo te conviene esta otra rama
La segunda categoría que mencionamos al principio merece su propio espacio porque está creciendo casi tan rápido como vibe coding y se confunde con él todo el tiempo. Los AI Coding Agents también construyen software con instrucciones en lenguaje natural, pero el operador sigue trabajando dentro de un entorno de desarrollo: archivos visibles, terminal abierta, código a la vista. Las dos referencias dominantes hoy:
Cursor. Un editor de código (un fork de VS Code) con IA integrada. En modo agent o Composer, el modelo construye features completas a partir de descripciones en lenguaje natural y opera sobre múltiples archivos a la vez. El flujo de trabajo, aun así, asume que quien lo usa lee, edita y ejecuta código. Útil para PMs con alguna familiaridad técnica que quieren una herramienta que los acompañe en ambos modos.
Claude Code. Un agente de programación de Anthropic, originalmente lanzado como herramienta de terminal y hoy disponible en varias superficies: CLI, app de escritorio, extensión para VS Code (con más de 2 millones de instalaciones), aplicación móvil iOS y apps para Slack y GitHub. La versión de escritorio integra terminal, edición de archivos y diff viewer en una sola ventana; la app móvil permite despachar tareas y revisar resultados desde el teléfono, lo que se acerca bastante al territorio del vibe coding. Es probablemente la herramienta más potente del segmento para construir software real, y con la extensión de VS Code o la app de escritorio la curva de entrada bajó mucho respecto a la terminal pura. La diferencia con vibe coding se mantiene: el flujo natural sigue pasando por leer diffs y entender la estructura de un proyecto. Existen alternativas open source con un encuadre similar, como OpenCode y Aider, para quien prefiere ese camino.
La regla simple para ordenar las tres categorías: el autocompletado (Copilot clásico) ayuda a un desarrollador a tipear menos; los AI Coding Agents (Cursor en modo agent, Claude Code) construyen software dentro de un entorno de desarrollo, asumiendo literacia técnica; el vibe coding (Lovable, v0, Bolt, Replit) construye y despliega productos desde una conversación, sin que quien lo usa tenga que abrir un editor. Confundirlas lleva a frustración predecible. Para el resto del artículo, cuando hablamos de vibe coding, hablamos de la tercera.
Vibe coding para PMs: por qué no es "aprender a programar"
Hay un viejo argumento en la industria del producto que dice que los PMs deberían aprender a programar. La idea tiene buenas intenciones: cerrar la distancia con el equipo técnico, entender mejor las restricciones, ganar autonomía. En la práctica, casi nadie lo hace, y los pocos que lo intentan terminan en una zona gris donde no son ni PMs efectivos ni programadores competentes.
Vibe coding cambia los términos del problema. La pregunta cambia de "¿debería un PM aprender a programar?" a "¿debería un PM aprender a construir prototipos funcionales describiendo lo que quiere?". La segunda formulación tiene una respuesta mucho más clara: sí, porque el costo de adquirir esa habilidad es bajo, el retorno es inmediato, y no requiere convertirse en una persona técnica.
La razón profunda por la que vibe coding es una habilidad de producto y no de ingeniería tiene que ver con dónde está el valor. El valor de un prototipo no está en el código. Está en la decisión que el prototipo permite tomar: ¿este flujo es claro?; ¿este copy convierte?; ¿esta forma de presentar el problema resuena con el usuario?. Un buen prototipo te ayuda a tomar esa decisión con evidencia, antes de invertir semanas de ingeniería. Eso siempre fue trabajo de producto, lo que cambia es la herramienta para hacerlo.
Lo que sí necesitas para hacer vibe coding bien es lo que un buen PM ya entrena. Necesitas pensar con claridad en el usuario, el flujo, los datos y las restricciones. Necesitas saber describir interacciones. Necesitas tener buen criterio visual (o saber pedir que alguien lo aporte). Y necesitas la disciplina de iterar contra una hipótesis concreta, no construir hasta que "se vea bonito". Todas son habilidades de producto que se transfieren directamente.
Si vienes del mundo tradicional y nunca tocaste código, la curva de entrada a vibe coding es de horas, no de meses. La fricción más grande es mental: desinstalar la creencia de que construir software requiere primero entender cómo funciona internamente. Cuando esa creencia cae, todo lo demás fluye.
Qué se puede construir realmente con vibe coding hoy
Hay mucho hype y bastante fantasía alrededor de lo que se puede hacer con estas herramientas. Conviene ser concreto sobre qué tipo de cosas funcionan bien hoy y cuáles todavía no.
Landing pages. Es el caso más maduro. En una tarde puedes construir una landing completa con hero, secciones de beneficios, testimonios, FAQ, formulario de captura de leads y tracking básico. La calidad visual de v0 en este terreno es difícil de distinguir de la de un diseñador profesional con experiencia. Es ideal para validar mensajes de marketing, posicionamiento o nuevas líneas de producto antes de invertir en producción.
Dashboards y reportes. Otro terreno donde las herramientas brillan. Un dashboard que toma datos de una API pública (por ejemplo, métricas de tu propio producto, datos abiertos de gobierno o información de un tercero), aplica filtros, muestra gráficos y permite exportar. Construirlo desde cero hace dos años requería un sprint completo. Hoy se hace en una sesión de trabajo.
Herramientas internas. El caso más subestimado y posiblemente el de mayor impacto operativo. Equipos de operaciones, ventas o soporte llenos de gente que vive en planillas hechas a mano y procesos manuales pueden tener herramientas a medida construidas por la persona de producto en una semana, en lugar de esperar el siguiente trimestre de roadmap. Esa diferencia transforma equipos completos.
Prototipos funcionales para validación. El caso clásico de discovery. Quieres testear si un nuevo flujo de onboarding mejora la activación. En lugar de mockups en Figma con notas adhesivas, despliegas un prototipo funcional al que un usuario real puede entrar, navegar, registrarse, y darte feedback sobre la experiencia completa. La fidelidad del aprendizaje es muchísimo más alta.
MVPs para validar mercado. El caso más ambicioso. Algunos fundadores están lanzando sus primeras versiones de producto enteramente con vibe coding, capturando los primeros 100 usuarios y validando demanda real antes de involucrar ingeniería. Funciona para productos relativamente simples y con tráfico moderado. No funciona todavía como solución definitiva para productos en escala, pero como herramienta de validación es transformadora.
Hay un caso más, intermedio entre prototipo y producción, que vale la pena nombrar aparte: prototipos de funcionalidad de IA. Si lo que estás validando es un asistente que responde preguntas sobre tu base de conocimiento, una búsqueda con contexto o cualquier feature donde el corazón del producto es un LLM, vibe coding te resuelve la capa de UI alrededor pero no te exime de pensar la pieza técnica que está debajo. Para entender esa parte, conviene cruzarlo con los fundamentos de RAG aplicado a producto: el código que genera v0 puede llamar a una API que tú armaste con un servicio de retrieval, pero la calidad de la respuesta depende de decisiones que no son de UI.
Si quieres ver cómo encaja todo esto con la operación de un producto de IA más adelante (cuando lo que prototipaste con vibe coding tiene que pasar a producción), nuestro artículo sobre qué hace un AI Product Manager cubre el ciclo completo.
Limitaciones y cuándo NO usar vibe coding
Por todo lo anterior, sería tentador concluir que vibe coding sirve para todo. No es así, y la diferencia entre una persona que lo usa con criterio y una que lo usa indiscriminadamente está exactamente en saber dónde están los límites.
Sistemas de producción con cargas reales. Las herramientas actuales generan código que funciona, pero no necesariamente código que escala bien, que es seguro a nivel enterprise, o que se mantiene en el tiempo. Si tu prototipo va a recibir miles de usuarios concurrentes con datos sensibles, lo que tienes en las manos es una validación, no un producto final. Pasarlo a un equipo de ingeniería para una reescritura limpia es lo correcto.
Entornos regulados. Salud, finanzas, sectores con compliance estricto. El código generado por vibe coding hoy no pasa auditorías sin trabajo significativo encima. Puedes prototipar para entender el problema, pero la implementación final tiene que vivir bajo procesos formales.
Lógica de negocio compleja con invariantes críticos. Si tu producto tiene reglas de negocio donde un error introduce daño irreversible (cobros incorrectos, transferencias mal calculadas, decisiones automatizadas con consecuencias legales), no quieres confiar la corrección únicamente en lo que generó un modelo. Esos casos exigen tests deterministas, revisiones de código humanas y, en muchos casos, evals específicos sobre el comportamiento.
Sistemas que tu equipo de ingeniería va a mantener por años. Si lo que estás construyendo es una pieza permanente de tu plataforma, vibe coding es la herramienta para diseñar y validar la solución, no para parir el código final. La razón es simple: el código generado tiende a tener decisiones arquitectónicas que un equipo profesional no habría tomado, y reescribirlo después de un año puede ser más caro que escribirlo bien desde el principio.
Productos donde la profundidad técnica es el diferencial. Si estás construyendo un sistema con requerimientos serios de performance, distribución, almacenamiento o algoritmia (un motor de búsqueda, una infraestructura de pagos, un sistema de tiempo real), vibe coding no es la herramienta correcta para el corazón del producto. Sí puede serlo para la capa de UI o las herramientas internas alrededor, pero el núcleo necesita gente que entienda esos dominios.
El encuadre que conviene tener: vibe coding es la herramienta más poderosa que existe hoy para prototipos, validaciones, herramientas internas y MVPs en estado temprano. Cuando algo de eso pasa a ser un producto real con tracción, el handoff a ingeniería sigue siendo el camino correcto. La diferencia es que ahora ese handoff llega con muchísima más evidencia detrás: el equipo de ingeniería arranca desde un "ya validamos que esto funciona, construyámoslo con calidad de producción" en lugar del clásico "construyamos esto a ver qué pasa".
Cómo empezar: tu primer prototipo en una tarde
Si llegaste hasta acá pensando "esto me serviría", la mejor manera de probarlo es exactamente eso: probarlo. La curva de entrada es corta y el primer resultado real cambia bastante la conversación contigo mismo.
Una buena primera vez se ve así. Eliges una herramienta (Lovable es la apuesta más segura para empezar). Eliges un caso pequeño y concreto: una landing page para una idea de producto que tienes dando vueltas, un dashboard simple con datos de una API pública, un formulario para capturar feedback de tus usuarios actuales. No intentes construir tu próximo producto entero en la primera tarde. Intentas construir una pieza pequeña, completa, y compartible.
El prompt inicial debería ser específico. Layout, secciones, tono visual, datos. No tienes que clavarlo perfecto la primera vez, pero cuanto más claridad pongas adelante, menos iteraciones perdidas pasas después. Cuando aparezca la primera versión, mírala con ojo crítico y pide cambios concretos, uno por uno. Después de tres o cuatro iteraciones, vas a tener algo desplegable y compartible. Mándaselo a alguien de tu equipo, a un usuario, a un stakeholder. Mide qué reacción genera. Eso es vibe coding funcionando.
A partir de ahí, lo que hace la diferencia es el volumen de prácticas. Cuanto más casos resuelves con esta herramienta, más rápido reconoces qué prompts funcionan, qué patrones se repiten, dónde están los atajos. Es exactamente la misma curva que cualquier otra habilidad de producto: empieza siendo lenta y específica, y se vuelve fluida con repetición.
Si quieres acelerar esa curva con estructura y trabajar contra casos reales de discovery, descubrimiento de mercado y validación con usuarios, nuestro Flash Workshop Vibe Coding Essentials (VCE) está diseñado exactamente para eso. Son cuatro horas en vivo, cero código, donde construyes desde una landing page simple hasta una mini-app multi-pantalla con integración de APIs en vivo. Salimos del workshop con prototipos desplegados, links compartibles y un método claro para incorporar la práctica al día a día. Es el punto de entrada que recomendamos a PMs, POs y diseñadores que quieren agregar vibe coding a sus herramientas de trabajo sin pasar por una transición técnica completa.
La adopción de vibe coding está corriendo más rápido que casi cualquier otra práctica nueva en producto. La pregunta práctica acá es de timing: entrar ahora, mientras todavía es un diferencial, o más adelante, cuando ya sea condición de base. Cuanto antes empieces el bucle de describir, generar e iterar, antes vas a sentir cómo cambia tu relación con tus propias ideas.