Vibe coding para Product Managers: ¿trampa o superpoder?

El vibe coding permite a los Product Managers crear prototipos en cuestión de horas de lo que antes llevaba semanas. Un potente acelerador para la fase de discovery... siempre y cuando no confundamos velocidad de ejecución con calidad del producto.

En febrero de 2025, Andrej Karpathy publicó un post en X que acabaría marcando el año. El antiguo director de IA de Tesla describía su forma de programar con LLM: dictaba en lenguaje natural lo que quería construir, aceptaba el código generado sin apenas leerlo e iba iterando hasta conseguir que funcionara. A esto lo llama «vibe coding». Lo llamó vibe coding. Pocos meses después, Collins Dictionary lo eligió como palabra del año.

Lo que podría haber quedado en una simple curiosidad de desarrolladores ha adquirido una dimensión totalmente diferente. A principios de 2026, el 63% de los usuarios activos del vibe coding no eran desarrolladores, según un análisis de Solveo realizado entre 1.000 usuarios de Reddit. Entre ellos: fundadores, especialistas en marketing y, sobre todo, Product Managers. La promesa resulta atractiva: crear prototipos funcionales, herramientas internas e incluso MVP sin escribir ni una sola línea de código.

Índice

• ¿Qué es exactamente el vibe coding?
• ¿Por qué los Product Managers son los principales afectados?
• Casos de uso en los que el vibe coding marca la diferencia
• Los límites que nadie quiere ver
• Vibe coding y product craft: la línea que no debemos cruzar
• Un marco práctico para practicar el vibe coding con criterio
• Preguntas frecuentes

¿Qué es exactamente el vibe coding?

El vibe coding es un enfoque de desarrollo de software en el que se describe lo que se quiere conseguir en lenguaje natural y un modelo de IA genera el código correspondiente. Se itera mediante indicaciones sucesivas, se corrige el resultado visualmente y se vuelve a ejecutar. El término lo acuñó medio en broma Karpathy, que lo describía como "dejarse llevar por las vibraciones, olvidarse de que el código existe y aceptar cosas que van mucho más allá de tu nivel habitual de comprensión".

Detrás de esta definición deliberadamente provocadora hay una realidad técnica muy sólida. Las herramientas que hacen posible el vibe coding (Cursor, Replit, Lovable, Bolt, v0) se apoyan en modelos multimodales capaces de procesar texto, voz e imágenes para generar código funcional. Replit alcanzó una valoración de 9.000 millones de dólares a principios de 2026, frente a los 3.000 millones que valía apenas seis meses antes. La infraestructura existe, está madura y evoluciona a gran velocidad.

La diferencia con el no-code tradicional se resume en una palabra: portabilidad. Con herramientas como Bubble o Webflow seguimos dependiendo de la plataforma. El vibe coding genera código fuente real que se puede recuperar, versionar en GitHub y confiar a un equipo de ingeniería para que lo desarrolle. En un contexto profesional, esta distinción lo cambia todo.

Pierre Carpentier, «Product Builder» en Thiga, lo ha experimentado de primera mano en una misión con un cliente. Necesitaban una interfaz de vídeo para un chatbot ya operativo: un front-end a medida que ninguna solución del mercado ofrecía.«Yo no soy desarrollador front-end. El cliente me dijo: "Necesito esto en tres semanas". Utilicé Cursor y llegué a tiempo. Sin eso, habría tenido que buscar especialistas o probablemente seguiría todavía con ello», cuenta. El vibe coding no solo aceleró su trabajo: hizo posible algo que antes no lo era.

¿Por qué los Product Managers son los principales afectados?

Los Product Managers siempre han sido traductores entre las necesidades del usuario y la ejecución técnica. El vibe coding acorta esta cadena de traducción de forma espectacular. Jackie Bavaro, autora de "Cracking the PM Interview", resume bien la situación: las habilidades que se desarrollan al trabajar con ingenieros (formular objetivos claros, identificar los casos extremos, redactar especificaciones precisas) son exactamente las que te hacen eficaz haciendo vibe coding.

Hasta ahora, un PM que quisiera validar una idea tenía tres opciones: diseñar un wireframe en Figma, redactar un PRD y esperar a que un ingeniero tuviera disponibilidad, o improvisar un prototipo limitado con herramientas no-code. El vibe coding abre una cuarta vía: describir lo que queremos construir, obtener un prototipo interactivo en unas horas y ponerlo en manos de los usuarios ese mismo día. El ciclo de feedback, que antes llevaba semanas, puede reducirse a una sola jornada.

La tendencia no deja de acelerarse. GitLab ya informaba en 2024 de que el 78% de los equipos de desarrollo utilizaban código asistido por IA. Las previsiones apuntan a que, en 2027, el 80% de los desarrolladores necesitarán competencias relacionadas con la IA. Para los Product Managers, mantenerse al margen significa ignorar un cambio de paradigma en la forma de crear productos.

El PM que crea prototipos: una ventaja para todo el equipo (siempre que adopte la actitud adecuada)

El principal beneficio del vibe coding para un PM va mucho más allá del ahorro de tiempo personal. Cuando un Product Manager llega a una reunión con un prototipo funcional en lugar de un deck de diapositivas, la conversación cambia por completo. Ya no se discuten hipótesis abstractas, sino algo que se puede tocar, probar y criticar de forma concreta. El tipo de feedback que que genera un prototipo interactivo no tiene nada que ver con el de un wireframe estático.

En RedMonk, la analista Rachel Stephens observa que los PM que utilizan vibe coding ya no se conforman con "definir requisitos en documentos escritos y diseños anotados". Llegan con ideas listas para debatir y las iteraciones comienzan antes en el ciclo, cuando su coste es menor. Cualquiera que esté familiarizado con la metodología del Design Thinking reconocerá el principio: crear prototipos pronto, fracasar rápido y aprender antes de comprometer recursos.

Tener un prototipo a mano ayuda a hacerse una idea del producto. Pero Pierre Carpentier invita a la prudencia respecto a esta actitud. "Desde el punto de vista de un desarrollador, ves llegar a un PM que se ha adelantado a parte de tu trabajo". Y que te dice: “Mira, es sencillo, lo he hecho en tres horas”. Esa relación no empieza precisamente con buen pie.", advierte el Product Builder. La forma en la que presentamos un prototipo creado mediante vibe coding al equipo técnico es tan importante como el propio prototipo.

Casos de uso en los que el vibe coding marca la diferencia

Prototipado rápido para la fase de discovery

El caso de uso más natural y, probablemente, aquel en el que la relación beneficio/riesgo es más favorable. Un PM identifica una oportunidad, formula una hipótesis y construye un prototipo que se puede probar en cuestión de horas. El objetivo no es generar código listo para producción, sino materializar una idea lo suficiente como para validarla con usuarios reales. De hecho, están surgiendo agentes de IA destinados específicamente a acelerar la fase de Discovery, conectando Figma con el código para dar forma rápidamente a una aplicación.

Este enfoque funciona especialmente bien para los flujos de usuario, las interfaces de entrada de datos y los paneles de visualización. Un PM puede describir en lenguaje natural el recorrido que imagina, obtener una aplicación funcional con estados de desplazamiento del cursor y función de arrastrar y soltar, y compartirla con su equipo con un solo clic. El coste de explorar una idea pasa de varios días de trabajo de ingeniería a unas pocas horas de prompting.

Herramientas internas y automatizaciones

El segundo gran terreno donde el vibe coding demuestra todo su potencial son las herramientas internas. Paneles de análisis, interfaces de administración o pequeñas automatizaciones entre herramientas SaaS son necesidades que suelen acabar acumulándose en el backlog de ingeniería sin llegar nunca a ser prioritarias. Un PM que domina el vibe coding puede resolver estas situaciones por sí solo, sin necesidad de movilizar recursos técnicos.

Además, las exigencias en materia de seguridad y escalabilidad suelen ser menores que en un producto orientado al cliente. La herramienta se utiliza dentro de un entorno controlado, por una audiencia conocida y con un alcance limitado. Es, probablemente, el mejor campo de experimentación para un Product Manager que empieza a trabajar con este enfoque.

Hackatones y POC para convencer

En las organizaciones en las que la decisión de invertir en un nuevo producto pasa por un comité, disponer de una prueba de concepto funcional cambia radicalmente la conversación. Un PM que presenta un prototipo interactivo consigue un nivel de atención y comprensión que difícilmente puede lograr un business case en PowerPoint. Al reducir drásticamente el coste de "mostrar en lugar de contar", el vibe coding devuelve a los Product Managers una capacidad de influencia mucho mayor en la toma de decisiones.

Los límites que nadie quiere ver

El muro de la seguridad

Empecemos por el tema que el entusiasmo general suele pasar por alto sistemáticamente. Según el informe GenAI Code Security de Veracode publicado en 2025, cerca del 45% del código generado por la IA contiene vulnerabilidades de seguridad. Cuando un LLM tiene que elegir entre una solución segura y otra más arriesgada para resolver un problema, opta por la segunda casi una de cada dos veces.

Los tipos de vulnerabilidades son los de siempre (inyecciones SQL, falta de validación de entradas, sistemas de autenticación deficientes), pero su frecuencia aumenta debido al enorme volumen de código que estos modelos son capaces de producir. Un investigador de la Universidad de Columbia ha documentado un patrón recurrente: los agentes de código optimizan para que el programa funcione, no para que sea seguro. Para un LLM, un control de seguridad que genera un error se asemeja a un bug que hay que corregir. No distingue entre "el código falla" y "el código está protegido".

El ejemplo más ilustrativo data de principios de 2026: la empresa de seguridad Wiz reveló una filtración masiva en el ecosistema Moltbook. Una base de datos de Supabase mal configurada había expuesto 1,5 millones de claves API y 35.000 direcciones de correo electrónico. ¿La causa principal? Código generado mediante vibe coding que funcionaba correctamente, pero carecía de las medidas de seguridad más básicas. Pierre Carpentier resume el problema: "Cuando tienes un producto con miles de usuarios y constituye el núcle de tu negocio, si falla en producción, estás en un buen lío". Su respuesta consiste en integrar el vibe coding dentro de un sistema que incorpore desde el principio las guías, estándares de calidad y buenas prácticas de la empresa durante la generación del código. Que todo lo que se produzca esté documentado, sea seguro y pueda desplegarse en producción.

La deuda técnica invisible

El código generado por la IA tiene una característica especialmente engañosa: es sintácticamente correcto. Se compila, funciona y tiene aspecto de código profesional. Sin embargo, acumula deuda técnica de una forma que el código escrito por humanos rara vez hace. Un artículo de investigación publicado en arXiv a finales de 2025 describe lo que denominan el "flow-debt trade-off": la facilidad con la que se genera código oculta la acumulación de incoherencias arquitectónicas, dependencias frágiles y lógica difícil de mantener.

El problema sale a la luz cuando se quiere hacer evolucionar el producto. Los desarrolladores que heredan un código creado mediante vibe-coding deben comprender decisiones arquitectónicas que nadie ha tomado realmente, depurar una lógica que nadie entiende del todo y refactorizar unos cimientos que nunca se concibieron para perdurar. Varios testimonios hablan incluso del llamado "muro de los seis meses": el momento en el que la deuda técnica acumulada hace que la aplicación sea ingobernable.

El riesgo de confundir "funciona" con "está bien hecho"

Este es, probablemente, el riesgo más sutil para un Product Manager. El vibe coding genera la ilusión de competencia técnica. Construimos algo que funciona, lo enseñamos, recibimos comentarios positivos y acabamos creyendo que sabemos desarrollar software. Brian de Haaff, CEO de Aha!, distingue acertadamente entre vibe coding y PM coding. El primero consiste en lanzarse sin un plan, mientras que el segundo integra la disciplina de producto (comprensión del problema, definición de los criterios de éxito, reflexión sobre la mantenibilidad) antes de dejar que la IA acelere la ejecución.

Pierre Carpentier plantea una analogía muy ilustrativa: "Es un poco como decir: Lo hice en Excel, me llevó cinco minutos. Muy bien. Ahora ve a hacerlo dentro de una empresa, que pueda desplegarse, mantenerse estable y utilizarse en producción. Ahí es donde se va el 80% del tiempo. Con la IA, diría incluso: un 2% para conseguir que funcione y un 98% para escalarlo correctamente". Un PM que entrega un prototipo generado mediante vibe coding creyendo que ya ha construido un producto coloca a su equipo en una situación imposible. Ingeniería tiene entonces dos opciones: rehacer completamente el código (a menudo más costoso que empezar desde cero), o bien validar una base técnica frágil bajo la presión del clásico "pero si ya funciona".

Vibe coding y product craft: la línea que no debemos cruzar

En Thiga llevamos años defendiendo una idea: la calidad de un producto depende tanto del rigor del proceso como de la calidad de la ejecución. El vibe coding no cambia esa convicción. Lo que sí cambia es la velocidad con la que podemos explorar el abanico de posibilidades antes de comprometernos con una solución. Y eso es una verdadera ventaja.

La línea divisoria está clara: el vibe coding es una herramienta de discovery, no de delivery. Sirve para validar hipótesis, probar recorridos de usuario o demostrar la viabilidad de una idea. En el momento en que empezamos a confundirlo con un proceso de desarrollo orientado a producción, empiezan a aparecer los problemas. La IA generativa aplicada al Product Management funciona de la misma manera: potencia la calidad del razonamiento humano cuando este existe y también amplifica los errores cuando falta.

El perfil emergente del Product Builder, que Thiga está contribuyendo a definir, encarna esta evolución: un Product Manager capaz de crear prototipos rápidamente con IA, comprender las implicaciones técnicas de sus decisiones y de saber exactamente cuándo pasar el relevo al equipo de ingeniería. En este sentido, Pierre Carpentier defiende una visión exigente: "Un Product Builder que no sabe nada de tecnología y que no sabe evaluar la calidad de lo que produce, se va a atascar. En cambio, alguien que tenga nociones de programación y que entienda lo que hace, puede llegar mucho más lejos". En su opinión, el escenario ideal es un Product Builder que domine todo el ciclo de vida del desarrollo de software: calidad del código, estrategia de testing y despliegue en los distintos entorno. "Si no domina todo el ciclo, tarde o temprano acabará chocando contra un muro".

El Product Builder también pone en cuestión la tentación del one-man team. "Si el PM o el diseñador siguen entregando resultados defectuosos, al final tendrás a un desarrollador que dedica todo su tiempo a rehacer el trabajo de los demás. Le quitas la parte creativa, la parte técnica, la razón por la que eligió esta profesión. A largo plazo, eso no funciona ». Para él, la respuesta pasa por equipos en los que dos o tres perfiles complementarios se hacen mejores mutuamente, y no por crear nuevos silos donde el PM programa por su cuenta y el desarrollador limpia el código después.

Un marco práctico para hacer vibe coding con criterio

Las buenas prácticas en torno al vibe coding empiezan a consolidarse. A continuación, un marco de trabajo que cualquier Product Manager puede aplicar para aprovechar sus ventajas sin sufrir sus efectos secundarios.

Definir el problema antes de escribir el primer prompt

Parece obvio, pero precisamente porque la herramienta permite construir tan deprisa, existe la tentación de saltarse este paso. Antes de empezar a hacer vibe coding de cualquier cosa, un PM debería haber definido claramente el problema del usuario, los criterios de éxito y los límites de lo que quiere explorar. El vibe coding reduce el tiempo de ejecución, no el de reflexión. El enfoque de producto estructurado sigue siendo un requisito previo.

Adoptar una lógica de prototipo desechable

Jackie Bavaro recomienda trabajar en dos iteraciones. La primera versión debe entenderse como un borrador exploratorio que, desde el principio, damos por hecho que acabaremos descartando.Su objetivo es hacer aflorar las verdaderas preguntas de diseño y ayudarnos a entender qué queremos construir realmente. La segunda versión, alimentada por los aprendizajes de la primera, puede ser más cuidada. Pero incluso esa segunda versión sigue siendo un prototipo, no un producto.

Revisar la seguridad antes de compartir

Si el prototipo maneja datos (aunque sean ficticios), comprueba los aspectos básicos de seguridad: no dejar claves API escritas directamente en el código, evitar accesos públicos a las bases de datos, comprobar que no haya credenciales expuestas. Son verificaciones que apenas llevan cinco minutos y que pueden evitar incidentes como el documentado por Wiz. Para los PM menos familiarizados con este tipo de comprobaciones, herramientas como GitGuardian o TruffleHog automatizan la detección de secretos expuestos.

Documentar la frontera entre prototipo y producción

Cuando el prototipo valida la hipótesis y el equipo decide desarrollar el producto, el PM debe dejar muy claro qué elementos son reutilizables y cuáles no. Lo que sí puede transferirse:  el diseño, los flujos de usuario, los aprendizajes obtenidos durante la validación. Lo que no debería reutilizarse directamente: el código generado mediante vibe coding. Preparar un paquete de documentación que incluya el stack tecnológico utilizado, el esquema de datos, los contratos de las APIs y los tests identificados facilita enormemente el trabajo del equipo de ingeniería. El código generado por IA nunca debería llegar a producción sin una revisión técnica completa.

Integrar los estándares dentro del sistema operativo del Product Builder

Es probablemente la práctica más importante y la que permite pasar del simple vibe coding al desarrollo asistido por IA de manera profesional. Pierre Carpentier describe el flujo de trabajo que su equipo implementa en un cliente: "El PM utiliza Cursor o Claude Code para desarrollar su funcionalidad. Cuenta con agentes que le ayudan en el diseño del producto teniendo en cuenta el contexto de discovery del cliente, y otros centrados en la concepción técnica. Y, antes de hacer el merge, pasa por una checklist: documentación actualizada, estándares de arquitectura respetados, cobertura de tests y código listo para desplegarse en producción". En definitiva, un marco completo que convierte el vibe coding en un proceso industrializable.

Formar a todo el equipo, no solo a los Product Managers

El vibe coding modifica la forma de colaborar dentro de los equipos. Los ingenieros deben saber que van a recibir prototipos para evaluar, no para aceptarlos tal cual. Los diseñadores deben comprender que el PM ahora puede materializar un flujo de usuario sin pasar por Figma, lo que cambia el orden habitual de la colaboración. Y los managers deben asumir que una mayor velocidad para crear prototipos no implica necesariamente una mayor velocidad de entrega del producto..

FAQ

¿Hace falta saber programar para hacer vibe coding?

No, y ahí radica precisamente el interés. El vibe coding se basa en describir en lenguaje natural lo que queremos construir. Herramientas como Replit, Lovable o Bolt se encargan de generar el código. Sin embargo, comprender los conceptos básicos (qué es una API, una base de datos, la diferencia entre front-end y back-end) permite iterar de forma mucho más eficiente y evitar los errores más habituales.

¿El vibe coding va a sustituir a los desarrolladores?

No. El vibe coding destaca en las fases de exploración y creación de prototipos. Construir un producto capaz de funcionar en producción, superar auditorías de seguridad y seguir siendo mantenible con el paso del tiempo continúa siendo un trabajo de ingeniería en toda regla. De hecho, los propios desarrolladores que trabajan con herramientas de IA son más productivos que nunca: el 84% de ellos utiliza o tiene previsto utilizar herramientas de IA en 2026.

¿Qué herramientas de vibe coding debería utilizar un Product Manager?

Para empezar, Lovable y Replit son las opciones más accesibles. Lovable genera tanto el código como la interfaz a partir de descripciones en lenguaje natural, sin necesidad de instalación local. Replit ofrece un entorno más completo, con la posibilidad de aprender un poco de programación al mismo tiempo. Para los PM que ya tienen conocimientos técnicos, Cursor ofrece un mayor control sobre la calidad del código generado. Los precios oscilan entre 15 y 100 euros al mes, dependiendo del plan contratado, a lo que hay que añadir el coste asociado al consumo de modelos de IA.

¿El vibe coding es compatible con la normativa (RGPD, sectores regulados, etc.)?

Para la creación de prototipos con datos ficticios o anonimizados, no hay ningún problema. La situación cambia cuando se trabaja con datos personales reales o dentro de sectores regulados, como la salud, la banca o los seguros. En esos casos, el vibe coding por sí solo no es suficiente. El código generado por la IA debe pasar por los mismos procesos de validación, pruebas y revisión de seguridad que cualquier código destinado a producción. Sobre este tema, la guía completa sobre agentes de IA publicada por Thiga profundiza en cuestiones como la gobernanza y la trazabilidad.

¿Tiene sentido utilizar vibe coding en una organización de producto madura?

Sí, siempre que se enmarque en un contexto adecuado. En una organización donde las prácticas de Product Management de IA ya están estructuradas, el vibe coding se integra de forma natural como herramienta para acelerar el discovery. La clave: establecer qué tipos de proyectos pueden utilizar este enfoque, qué normas de seguridad deben cumplirse y cómo se lleva a cabo la transición hacia el equipo de ingeniería cuando un prototipo queda validado.

Conclusión

El vibe coding ofrece a los Product Managers algo que nunca habían tenido: la capacidad de materializar una idea de producto en unas pocas horas, sin depender de un equipo técnico. Una ventaja real para la fase de discovery, la comunicación con los stakeholders y la velocidad de aprendizaje.

Pero, como ocurre con cualquier tecnología, la herramienta amplifica tanto las buenas prácticas como las malas. Un PM riguroso que utiliza el vibe coding creará mejores prototipos en menos tiempo. Un Product Manager que confunda prototipo con producto acumulará deuda técnica, vulerabilidades de seguridad y frustración para sus equipos de ingeniería. La diferencia entre ambos radica en una pregunta: ¿tengo claro qué quiero validar antes incluso de abrir la herramienta?

En Thiga, recomendamos a los Product Managers que exploren el vibe coding con seriedad. Que construyan una primera herramienta interna, que se familiaricen con la creación de prototipos, que comprendan lo que la IA es capaz de hacer y dónde falla. Y, al mismo tiempo, que refuercen su disciplina de producto: formular correctamente el problema, definir los criterios de éxito, saber identificar cuándo el prototipo ha cumplido su función y cuándo es el momento de pasar el testigo al equipo de ingeniería. El verdadero superpoder no está en la herramienta. Está en la combinación entre la herramienta y el criterio de quien la utiliza.