Si has oído hablar del revuelo de Vibe Coding pero no tienes claro qué es real y qué es solo promoción, este episodio es tu atajo hacia la claridad. Grabado en vivo durante nuestro taller práctico de Vibe Coding, este seminario de 30 minutos con Drew Falkman (Principal en Moves The Needle) desglosa lo que realmente es Vibe Coding, dónde encaja en el ciclo de vida del producto y cómo personas sin conocimientos técnicos ya lo están usando para lanzar herramientas y prototipos—sin escribir una sola línea de código.
Acompañada por la coanfitriona Katie Sanders, Hannah lidera una sesión para desmontar mitos comunes (spoiler: los ingenieros no van a desaparecer), muestra casos de uso reales de Reddit y de su propio equipo, y ofrece consejos tácticos para PMs que quieran explorar este espacio en rápida evolución de manera responsable.
Lo que aprenderás
- Qué es Vibe Coding—y qué no es
- Por qué es más una evolución que una revolución
- Dónde puede acelerar significativamente el trabajo de producto (y dónde no puede)
- Cómo experimentar de forma segura sin saltarse la estrategia o el cumplimiento normativo
- Herramientas para probar y cómo afrontar la curva de aprendizaje
Puntos clave
- Vibe Coding ≠ sustituir la ingeniería. Es una herramienta para acelerar la creación de prototipos y validación temprana, no un reemplazo completo del equipo de desarrollo—especialmente para aplicaciones listas para producción.
- Los PRD siguen siendo importantes. Incluso un “vibe PRD” de una sola página marca la dirección y mantiene alineados a los colaboradores. Sin plan = resultados caóticos.
- El cumplimiento es fundamental. Las industrias reguladas aún pueden utilizar Vibe Coding—solo no te saltes las revisiones de código y los protocolos de seguridad.
- Los wireframes son opcionales—pero la colaboración no lo es. Los PMs pueden prototipar la interfaz directamente, pero aún deben alinearse con diseño y desarrollo antes de lanzar nada.
- Aprende haciendo. Herramientas como Lovable y Cursor reducen la barrera de entrada para personas no técnicas, y hasta los “creadores de ideas” pueden poner manos a la obra.
- Sé humilde, no imprudente. Como demostró una historia de advertencia, saltarse la supervisión técnica puede hundir tu producto rápidamente.
Capítulos
- [00:00] Introducción: Para quién es (y para quién no es) este episodio
- [01:03] Conoce a tus anfitriones y ponente
- [02:35] Mito #1: Vibe Coding reemplaza a los ingenieros
- [04:04] Mito #2: Vibe Coding está separado del ciclo de desarrollo
- [05:02] Mito #3: No necesitas un PRD
- [06:14] Mito #4: Vibe Coding no es seguro para industrias reguladas
- [07:41] Casos de uso reales (app de fútbol, WorkAid)
- [09:07] ¿Pueden los PMs saltarse los wireframes ahora?
- [10:12] Caso interno: Analizador de impacto de despidos
- [12:35] Crear encuestas sin experiencia en desarrollo
- [13:54] Qué pasa sin supervisión de ingeniería
- [16:02] Curva de aprendizaje: la experiencia de Michael
- [16:27] Cómo encaja Vibe Coding en verdaderos equipos de producto
- [18:08] Ideas de producto únicas vs replicables
- [19:34] Cierre + cómo estar conectados
Conoce a nuestro invitado

Drew Falkman es Principal en Moves the Needle Product Studio, donde lidera la estrategia de producto y la consultoría en innovación para ayudar a startups a encontrar el ajuste producto–mercado mediante IA, experimentación ágil y prácticas escalables de producto. Ex CTO y cofundador de startups, Drew se apoya en más de 27 años de experiencia en liderazgo de producto en contextos web, móviles, blockchain y de IA para guiar a equipos de ingeniería y diseño hacia decisiones de impacto. También es un asesor prolífico, instructor en LinkedIn (con más de 250K líderes de ingeniería que han completado su curso para CTOs) e invitado frecuente en podcasts—ofreciendo ideas sobre liderazgo, trabajo profundo y gestión de equipos técnicos para lograr resultados reales.
Recursos de este episodio:
- Suscríbete al newsletter de The CPO Club
- Conecta con Drew en LinkedIn
- Visita Moves The Needle
Artículos y podcasts relacionados:
- Acerca del Podcast de CPO Club
- ¿Cómo deben los Product Managers utilizar wireframes?
- El plan de dieta del equipo de producto: ¿La IA se está comiendo tu hoja de ruta?
- Dominando los wireframes de alta fidelidad: Guía para crear prototipos profesionales
- ¿Qué hace un Product Manager? Un día en la vida de un PM
- He probado todos los procesos de wireframing y este es, con diferencia, el mejor
Lee la transcripción:
Estamos probando transcribir nuestros pódcasts utilizando un programa de software. Por favor, disculpa cualquier error ya que el bot no es 100% exacto.
Hannah Clark: Muy bien, chicos. Aviso para este episodio: si ya eres un experto en Vibe Coding, este episodio quizá no sea para ti. Pero si has oído hablar de Vibe Coding y quieres conocer los hechos frente a los mitos, y tienes curiosidad por saber cómo puedes usar la tecnología para avanzar en tus propios objetivos, te va a encantar esto.
Si no has estado siguiendo nuestros boletines, los que puedes suscribirte en theproductmanager.com/subscribe, no he parado de hablar del increíble taller práctico de Vibe Coding que hicimos hace unas semanas, con Drew Falkman, Principal de Moves The Needle. Este episodio del Product Manager Podcast es en realidad una grabación del seminario de 30 minutos que dimos antes de empezar nuestra sesión de prototipado en vivo. Vas a escuchar una explicación de lo que es y no es el vibe coding, casos de uso inspiradores de la tecnología y recomendaciones de herramientas para que empieces a experimentar y descubrir tus propios casos. Vamos a ello.
Ah, por cierto, tenemos conversaciones como esta todas las semanas. Así que si te interesa, ¿por qué no te suscribes? Bien, empecemos.
Soy Hannah Clark. Si no me conoces, soy la Editora Ejecutiva de The CPO Club y la conductora de The CPO Club podcast. Y tengo conmigo a mi coanfitriona, Katie.
Katie Sanders: Hola a todos, soy Katie Sanders. Soy Editora Ejecutiva en The CTO Club. Quizá también me conozcan de The QA Lead. Hay algunas personas porque fusionamos esos sitios. Así que estoy emocionada. Este es mi primer taller y realmente me hace ilusión hacerlo con Hannah, porque hay bastante mezcla entre producto y CTOs. Así que sí, tengo muchas ganas de conocer a todos. ¡Bienvenidos!
Hannah Clark: Estoy muy emocionada de trabajar con Katie en esto. Si aún no la sigues en LinkedIn, Katie Sanders, es increíble. Tiene contenido genial, así que de verdad me entusiasma que puedan conocerse.
Me gustaría presentar también a nuestro ponente destacado. Tenemos aquí a Drew Falkman. Drew es líder de producto, asesor, educador, enfocado en estrategia de producto desde pre-semilla hasta semilla. Ha agilizado equipos iniciales. Se ha enfocado en el fit del producto con el mercado.
Lo ha hecho todo. Es muy amigo de la publicación. Ha trabajado mucho con nosotros. Y ha trabajado mucho conmigo, lo que te dice que es una persona muy paciente. Así que hoy están en buenas manos. Y además, tiene mucha experiencia en productos web, móviles, blockchain y de IA. Así que tenemos a un experto increíble aquí.
Drew, ¿quieres saludar a toda la gente?
Drew Falkman: Hola a todos, muy emocionado de estar aquí. Esto va a ser divertido.
Hannah Clark: Así que vamos a empezar desmontando algunos mitos y yo daré la primera pregunta y luego mi encantadora coanfitriona, Katie, repasará algunos mitos y hará que Drew los desmienta para nosotros. Empecemos poniendo algo de contexto.
Parece que todo el mundo habla sobre vibe coding y surge en cada publicación de LinkedIn ahora mismo, incluidas muchas de las mías. Y la gente parece estar muy emocionada o muy asustada, o muy confundida. Así que hablemos de por qué el Vibe Coding es tan popular. ¿Por qué es tan importante ahora mismo? Vamos con el mito sobre eso.
Katie Sanders: De acuerdo, el primer mito: el vibe coding está reemplazando a los ingenieros. Obviamente hay mucho de que, en general, la IA está reemplazando los trabajos de todos. Eso es lo que dicen. Yo diría que eso es un mito y que quizá está cambiando el trabajo de los ingenieros y sí está creando código listo para la app, pero desde luego no está reemplazando totalmente el rol de un ingeniero.
Como siempre, con IA, queremos mantener un humano en el circuito, así que diría que nada va a enviarse sin que unos ojos humanos lo revisen, así que creo que podemos desmontar ese mito.
Hannah Clark: Drew, ¿quieres añadir algo a eso?
Drew Falkman: Sí, diría que es algo que uno debe tener en cuenta como ingeniero, es algo que se viene dentro de poco.
Simplemente podría acelerar tu proceso. Y como diseñador y gerente de producto, o fundador no técnico, ahora tienen la capacidad de crear MVPs, crear y validar prototipos, y hacer cosas, y luego pasarlas a los ingenieros. Cuando quieras llegar a código a nivel de producción, generalmente, después del MVP.
Hoy en día, por supuesto, necesitas hacer revisiones de código y asegurarte de que todo esté afinado, especialmente si hay cuestiones de cumplimiento u otras cosas que se deben tener en cuenta.
Hannah Clark: Pasamos al mito número dos. Algunas personas dicen que el vibe coding es un mundo aparte del ciclo de desarrollo.
Es decir, si creas algo en una app de vibe coding, que aún así no es realmente útil y que tienes que reconstruirlo completamente desde cero con un desarrollador que lo codifique todo desde el principio. Drew, ¿esto es realmente así?
Drew Falkman: Las herramientas han evolucionado muchísimo y es una de esas cosas donde literalmente está cambiando cada día.
Claude acaba de lanzar una nueva iteración de generación de código en el último mes más o menos, y es mucho mejor que antes. Así que mejora continuamente. Como todo lo generativo en IA. Puede alucinar, puede hacer cosas raras. Puede pasar cualquier cosa inesperada. Así que como parte del ciclo puede integrarse y puedes crear piezas de código.
Las puedes dar luego a los ingenieros, pero de verdad tienes que ser consciente de que probablemente necesitarán algo de retoques. Tal vez debas reutilizar algunos componentes, y creo que algunos ingenieros se sorprenderán del buen nivel que realmente tiene el código.
Hannah Clark: Bien. Otro mito que he escuchado mucho es que no necesitas un PRD o una estrategia de producto para hacer vibe coding en una herramienta.
Drew, Katie, ¿opiniones sobre esto?
Drew Falkman: Mira, siempre tienes que pensar. Creo que lo que ocurre, es que la gente cree que si está usando vibe coding, puede simplemente lanzarse, abrirlo y tener una app mañana. Y como con cualquier cosa, si no lo piensas antes, no será lo que deseas. Tienes que pensar en quién es tu público objetivo, mercado objetivo.
Piensa en cuál es tu propuesta de valor. Piensa en qué características y flujos principales habrá en la app. Así que realmente te conviene preparar algo. Ahora, lo bueno es que no necesitas un PRD de cinco o diez páginas que defina toda la tecnología, que diagrame los flujos y todo eso.
No tienes que pensar tanto en eso. Solo debes esquematizar tu visión, lo que estás construyendo, y de hecho, yo he creado un pequeño vibe PRD, y es solo una o dos páginas, solo para ti y quienes colaboren contigo, para que todos estén alineados y puedas trabajar con un enfoque organizado.
Y así tu código es más limpio a largo plazo.
Hannah Clark: Bien saberlo. Sigamos con el siguiente mito acerca de industrias altamente reguladas. Ahora, Katie representa al CTO Club, ¿quieres comentar el mito, Katie?
Katie Sanders: Sí, quería mencionar también otro. Que esto es nuevo y contarles que llevamos haciendo vibe coding desde hace años.
No lo llamábamos así hasta hace poco, pero copiar y pegar de GitHub o Reddit o Hacker News, donde sea, los buenos ingenieros resuelven problemas. Buscan, reconocen patrones, adaptan y construyen. Así que creo que este prompt es solo la siguiente evolución de lo que siempre ha existido. Y luego, Hannah, ¿cuál era el otro mito que querías romper?
Hannah Clark: Solo el de que si estás en una industria altamente regulada no puedes hacer vibe coding. O que no es seguro.
Katie Sanders: Sí. Obviamente, si pensamos en salud o finanzas, son industrias altamente reguladas. Así que igual que con cualquier otra industria, quieres asegurarte de que cumples con HIPAA y todas esas cosas.
Sé que los LLMs a veces pueden extraer. Sí. Así que considera los temas de cumplimiento. Pero creo que hay una barrera adicional cuando piensas en salud o finanzas o algo así.
Hannah Clark: Sí, creo que es como muchos procesos de desarrollo donde igual, las herramientas de vibe coding no reemplazan a tu personal.
Solo son un complemento para acelerar el ciclo de desarrollo. Pero sí, una buena revisión rigurosa del código, probablemente ahora sea más esencial que nunca ahora que se está externalizando parte de ese trabajo. Bien, hablemos un poco de algunos casos de uso. Será divertido explorar varias formas diferentes en que la gente está usando el vibe coding de forma efectiva ahora mismo.
Katie dirigirá esta sección y repasará algunos de los casos más interesantes.
Katie Sanders: De hecho, muchos de estos los saqué de Reddit cuando empezó a surgir el vibe coding. Quería ver ejemplos reales de esto. Todo el mundo hablaba de ello, pero no podía ver ejemplos exitosos.
Así que hice un artículo sobre esto y una de las cosas que hablamos fue de una persona que creó, creo que era algo como un organizador de partidos de fútbol, simplemente por un hobby personal. No era desarrollador, pero entendía cómo funcionaban las aplicaciones de full stack, y siempre había tenido que contratar desarrolladores para materializar sus ideas.
Pero al empezar a probar Lovable, Cursor y otras cosas. Creó esta app nicho para organizar sus partidos semanales y la lanzó con éxito. Sí, lanzó una app de IA generada de cien líneas de código, con ganancias. En semanas, creo que ganaba algo como, ¿eran $700 a la semana o algo así? Otro ejemplo que encontramos fue uno llamado Work Aid, que es una gestión de tareas gamificada con IA. Revoluciona la lista de tareas con apps para que el trabajo sea como un juego. Estos fueron un par de ejemplos exitosos que encontré en Reddit y podemos pasarles ese post.
Había algunos ejemplos más y creo que mucha gente lo está probando, pero también hay personas que lo van a explotar con mucho éxito, lo cual es genial.
Hannah Clark: Sí, es un ejemplo muy bueno. Solo quería interrumpir rápidamente porque tenemos una muy buena pregunta de Katya.
Katya pregunta: Como PM, ¿tendría que seguir creando wireframes y maquetas para el front-end o podría crearlos con vibe coding y que los desarrolladores usen mi frontend como punto de partida para su propio desarrollo?
Drew Falkman: Sí, 100%. De hecho, diría que sería más difícil con la mayoría de las herramientas de vibe coding intentar implementar un diseño preexistente.
Es difícil importar pantallas y todo eso. En realidad es más sencillo definirlo y puedes trabajar con la IA generativa para conseguir el look & feel adecuado y luego pasárselo a los devs, que pueden asegurarse de que respete tu sistema de diseño o cualquier otro sistema que uses.
Hannah Clark: Gracias por responder, Drew. Perdona, Katie, por interrumpir. ¿Quieres volver a los casos de uso? Sé que todavía tienes algunos más preparados.
Katie Sanders: Michael, ¿quieres compartir uno de los casos de uso de nuestra propia empresa? Crearon este analizador del impacto de despidos. Michael, no sé si quieras contarlo como gran ejemplo.
Michael Mordak: Por supuesto. Es un ejemplo excelente. Uno de nuestros compañeros lo usó en su sitio, donde trabaja para una publicación de RR. HH. y quiso construir una herramienta que la gente pudiera usar para analizar el impacto de un despido si lo estaban planificando. Lo que hizo fue que lo programó, o el bot lo programó, para que quienes quisieran usarla tuvieran que completar primero una encuesta.
Así recoge datos sobre quién usa la herramienta, que era algo que quería para sus propios fines. Una vez completada la encuesta, la app te lleva a la calculadora. Hay algunos ejemplos ya cargados. Si estás en una empresa manufacturera y vas a despedir a 200 empleados, por ejemplo, puedes elegir ese ejemplo para ver cómo funciona.
Básicamente, introduces varios detalles y cuestiones como cuánta experiencia tienen esas personas, cuánto tiempo tomaría capacitar a alguien para ese rol, y luego puedes calcular el impacto del despido y ver exactamente qué efecto va a tener.
Es una herramienta excelente para gente de RR. HH. que planifica despidos y la ha puesto gratis para que cualquiera la pruebe y le dé feedback. Pero ese es un ejemplo interno. El segundo ejemplo es la herramienta de encuestas que justo estábamos usando. La programé yo mismo.
No tengo experiencia programando o muy poca. Así que armé esta app de encuestas, básicamente, para que pudiéramos recibir votos en tiempo real y mostrar resultados en pantalla, en vez de pagar por otra app. Porque a menudo las apps traen esa función, pero te hacen pagar todos los extras que no vas a usar.
Solo me interesaba la encuesta, así que la armé para poder crear mis propias encuestas, ponerle el nombre que quiera, tantas opciones como quiera, previsualizar antes de publicar, y después lanzarlas, borrarlas, etc. Así es como se muestran en pantalla.
Así que ustedes están votando en la app que creé. No recojo ningún dato de ustedes. No se preocupen. Vive solo aquí. Así es como vimos los resultados. La armé literalmente 30 minutos antes de la llamada, pero en total me llevó una o dos horas darle el branding y presentarla bien.
Pero tampoco soy diseñador, no me copien en eso.
Katie Sanders: Sí, hemos hablado aquí de las ventajas. Por supuesto, hay gente que está probando estas cosas y piensa que nunca más volverán a necesitar a alguien técnico. Pero hay el ejemplo de este chico, Leo Junior.
Su post se hizo viral en X. Es el fundador de Enrich Lead, una herramienta que recoge IPs y usa un LLM para generar leads comerciales. Programó toda la app usando Cursor y dijo, muy orgulloso, que no había escrito ni una línea de código, que todo lo hizo la IA: puedes quejarte o puedes construir, con mucha arrogancia y nada de humildad.
Y, claro, Internet respondió fuerte y en 48 horas los hackers tomaron el control, saltaron las suscripciones y los costes se dispararon. El LLM empezó a inventar leads falsos. Leo tuvo que pedir auxilio en Twitter y reconocer "me están atacando, pasan cosas raras".
No soy técnico, así que me cuesta más arreglarlo. Ahora está aprendiendo a programar a la fuerza. Así que, de nuevo, la lección de siempre: siempre necesitas a un humano en el circuito y jugar como persona sin perfil técnico es divertido, pero hace falta alguien técnico que revise el código.
Hannah Clark: Michael, ¿quieres contarle a la gente cómo fue esa curva de aprendizaje para ti la primera vez que probaste estas herramientas?
Michael Mordak: Claro. Como he dicho, casi no sé programar, así que a menudo veo algo así: "soy una persona de ideas", nunca he construido nada, 100% soy de ese perfil porque siempre pienso cómo mejorar procesos internos o hacer cosas sin pagar apps de terceros, pero construirlo es difícil.
Respondiendo a Grant, preguntó cómo es la curva de aprendizaje y la herramienta que usamos hoy, Lovable, va a ser parecida en las demás apps que existen. Honestamente, la curva es suave, es muy baja porque como ves solo tienes que escribir prompts de texto.
Detallas lo que quieres ver, el objetivo de tu app, los resultados que quieres tener. Y te da ejemplos de lo que te podría construir. Puedes escribir detalles adicionales. Si tienes algo de donde partir, por ejemplo, para esta dije que quería que se pareciera a slido.com, que si lo conoces es una app de encuestas.
Entonces puede tomar ejemplos del mundo real y montar algo parecido, y luego puedes poner tu marca, requisitos, etc cuando vas a pedir la app. Cuando termina la primera versión, ahí no acaba la cosa. Puedes seguir chateando con ella.
Hay un modo chat, puedes preguntarle cosas antes de que toque el código o arme algo. Además, lo que hice cuando ya no sabía más era copiar lo que me respondía Lovable en chatGPT y pedirle: explícamelo como si tuviera 5 años.
Así que lo simplificaba para mí, que no entiendo detalles técnicos y lo explica bien. Así que fue un proceso muy fácil y muy simple para animarse a probar estas cosas.
Hannah Clark: Eso está genial. Y espero que sea alentador para quienes, como yo, estamos empezando completamente desde cero.
Quería sacar una pregunta de Tal, que va para Drew. Pregunta Tal: ¿cuál recomendarías que fuera el mejor flujo de trabajo para empresas de producto que ya existen? Soy PM en una startup que tiene sistema de diseño y producto en marcha con usuarios. ¿Para qué crees que puedo usar el vibe coding: para alguna feature concreta o idea?
¿Y cuándo volvería a diseño o salta diseño y pasa directo a dev?
Drew Falkman: Este flujo es cien por cien experimental todavía. No hay mejores prácticas. Es el salvaje oeste poniendo todo esto junto. Pero si fuera yo en una empresa, saltaría diseño, pero coordinando con el diseñador.
Harías, y ahora muestro mi vibe PRD, un documento que describe las pantallas y los elementos. Que el diseñador esté de acuerdo, incluso puede colaborar. Acuérdate de que no se debe hacer en silo. Todos vemos el mismo proyecto y trabajamos juntos.
Después lo crearía. No hay forma mágica que yo conozca, al menos en Lovable, para integrar sistemas de diseño. Otras como Cursor es una herramienta más de bajo nivel porque puedes conectar los chats, pero curras directo en el código.
En un entorno de desarrollo integrado, y a menudo tienes que correr instrucciones por línea de comandos. Es más técnico si no sabes nada de código, pero permite más interacción e integración de código. Así que puede ser mejor para ese uso. Pero si lo hago aquí, Lovable sincroniza dos vías con GitHub, intentaré mostrarlo si da tiempo.
Así puedes crear una pantalla, enviarla a GitHub, los devs la bajan, aplican componentes y sistemas de diseño y suben los cambios. Cuando tú vuelves deberías ver todo actualizado e idealmente debería funcionar genial.
Hannah Clark: Genial. Esta pregunta es de Donald para Drew. ¿Cuál es tu experiencia haciendo vibe coding para algo tipo clon (ej. otro gestor de tareas) versus algo realmente singular como una sonificación de datos de Google Trends? O sea, vibe coding para algo muy ya existente en objetivo, vs. Una idea totalmente inédita y que nadie ha hecho.
Drew Falkman: Gran pregunta. Mi experiencia usando herramientas de prototipo y vibe coding es que cualquier cosa ya existente es bastante directa. Lo entienden. Nuestro ejemplo hoy es una app de viajes. Puede hacer apps de viajes sin problema, pero al llegar a algo como sonificar datos de Google Trends va a ser más complicado.
Y añado que cuando se trata de casos fuera de lo común que piden visualizaciones muy personalizadas, distintas de menús, botones y demás elementos estándar de la UI, te va a costar con estas herramientas, al menos con Lovable y al día de hoy.
Quizá existan otras herramientas que lo resuelvan mejor, pero ahora mismo son cosas donde hay que sumar a los devs y trabajar juntos si inventas algo realmente original o diferente.
Hannah Clark: Ya se acaba el tiempo. Quiero dar un enorme agradecimiento a Katie por sumarse a esto, y por supuesto a Drew por ser tan increíble recurso, regalando su tiempo y experiencia.
Gracias por escuchar. Para más ideas, tutoriales y reseñas de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes escuchar más charlas como esta suscribiéndote a The CPO Club donde sea que escuches tus podcasts.
