Vibe coding y el espejismo de la velocidad (2)
El vibe coding podría convertirse en la mayor amenaza para la actividad de descubrimiento de problemas en product management, pero los mejores equipos de producto transformarán la IA en un motor de descubrimiento en lugar de una fábrica de características.
Como vimos, una consecuencia indeseada del vibe coding es la facilidad con la que seduce a los equipos de producto para que pasen por alto el espacio del problema. La IA crea algo muy potente: la fuerza gravitatoria de la solución.
El vibe coding crea un campo gravitatorio alrededor de la solución
La gestión de productos de software abarca fundamentalmente dos ámbitos distintos:
- El espacio del problema: El entorno donde residen los puntos de dolor del cliente, las necesidades del mercado, la fricción operativa y los incentivos económicos. Es un ámbito caótico, ambiguo, humano y difícil de cuantificar.
- El espacio de la solución: El entorno donde residen las funcionalidades, las características y la experiencia de usuario. En productos software es el dominio de la arquitectura, los patrones de UX y el código. Es un ámbito estructurado, predecible, controlable y gratificante.
Por qué nos enamoramos del espacio de la solución
La psicología humana anhela una resolución. Pero descifrar un problema complejo del cliente exige lidiar con la ambigüedad, participar en entrevistas de descubrimiento incómodas y gestionar prioridades empresariales contrapuestas. El vibe coding ofrece una recompensa instantánea. Le das una instrucción a la IA: «Crea un panel de control para que los gerentes de cadena de suministro monitoricen los retrasos en el inventario». Treinta segundos después, aparece una interfaz elegante con gráficos, métricas y filtros.
Luego, la IA te invita naturalmente a profundizar más: «¿Quieres añadir alertas automáticas por correo electrónico? ¿Qué tal un sistema de previsión de la demanda basado en IA?». De repente, el gestor de producto pasa tres días perfeccionando el código, ajustando temas visuales y configurando gráficos sintéticos. El cliente, mientras tanto, ha abandonado la escena discretamente.
Requisitos frente a especificaciones: una distinción olvidada
Esta dinámica agrava un problema crónico en el desarrollo de producto: confundir los requisitos con las especificaciones.
- Los requisitos definen quién tiene el problema, qué fricción experimenta y por qué resolverlo genera valor económico o estratégico.
- Las especificaciones definen cómo nuestro producto resolverá el problema: funcionalidades, características, prestaciones.
Cuando los gestores de producto pasan directamente al vibe coding, escriben especificaciones disfrazadas de prototipos. Se saltan la definición del problema porque la herramienta hace que construir la solución sea extremadamente sencillo. Sin embargo, un desarrollador junior (ya sea un ingeniero humano o un modelo de lenguaje) no puede crear un producto exitoso sin comprender las dinámicas subyacentes del mercado.
Si nuestra comprensión del problema fundamental del cliente es errónea, el vibe coding solo nos permite construir lo incorrecto en tiempo récord. Hablamos de AI slop en el ámbito de los contenidos; esto es lo que esa «basura de IA» significa para el desarrollo de productos.
El dilema entre el espacio del problema y el espacio de la solución
La gestión de productos tradicional distingue dos elementos: el descubrimiento del problema (comprender las necesidades de los usuarios, la dinámica del mercado y los puntos de fricción) y el descubrimiento de la solución (comprobar si el enfoque propuesto satisface dichas necesidades). El error fundamental que propicia la creación de prototipos de IA es tratar cada prototipo como una solución que debe validarse, en lugar de como una herramienta para explorar cómo se realiza el trabajo en la realidad.
Cuando desarrollar es rápido y económico, surge la tentación de realizar más demostraciones de soluciones en lugar de profundizar en el descubrimiento del problema. Los equipos caen en un ciclo impulsado por las reacciones a las demostraciones: presentan prototipos funcionales, recopilan opiniones, iteran sobre la interfaz de usuario y optimizan funcionalidades, todo ello sin llegar nunca a confirmar si están resolviendo un problema que realmente merece la pena solucionar.
Entonces, ¿qué deberían hacer de forma diferente los gestores de producto? La respuesta no es «usar menos IA». Es «usar la IA en la secuencia correcta».
Las ventajas del vibe coding son reales: velocidad, accesibilidad e iteración
Nada de esto es un argumento en contra de la IA. Más bien al contrario. Las ganancias en productividad son extraordinarias:
Democratización de la creación. los product managers sin perfil técnico ahora pueden construir prototipos funcionales sin esperar a los sprints de ingeniería, lo que reduce los cuellos de botella y aporta ventajas de rapidez y reducción de costes.
Reducción radical del coste de iteración. Se pueden crear y descartar prototipos desechables sin consumir capacidad de ingeniería, reservando el tiempo de los desarrolladores para tareas de nivel de producción. Pero el mayor avance es reducir el coste de equivocarse. Los equipos pueden probar diez conceptos en lugar de dos, las variaciones de UX se vuelven desechables y los experimentos se multiplican. Esto aumenta la opcionalidad, lo que constituye una enorme ventaja estratégica.
Mejor comunicación entre áreas. El software funcional actúa como una «especificación viva» que alinea a las partes interesadas de manera más eficaz que los documentos estáticos, reduciendo las malas interpretaciones. Los prototipos funcionales eliminan la ambigüedad porque, en lugar de debatir especificaciones, ingenieros, diseñadores, equipos de ventas y clientes reaccionan ante algo tangible. Las conversaciones se enriquecen porque todos hablan sobre el mismo elemento concreto.
Ciclos de aprendizaje más rápidos. La filosofía Lean Startup hacía hincapié en el ciclo Construir-Medir-Aprender. El ciclo de retroalimentación entre la idea y el producto tangible se reduce de semanas a horas, permitiendo a los equipos probar más hipótesis en menos tiempo. En teoría, esto debería acelerar drásticamente el aprendizaje. La frase clave es «en teoría» porque muchos equipos sustituyen accidentalmente el aprendizaje por el lanzamiento.
Las desventajas ocultas: sesgo cognitivo y optimización prematura
Los riesgos son más sutiles que las alucinaciones o el código con errores. Son de naturaleza cognitiva.
La trampa de la confianza. Los prototipos visualmente atractivos generan una falsa sensación de certeza. Los seres humanos sobreestiman sistemáticamente las ideas una vez que se materializan. Una maqueta en Figma parece más real que las notas de una entrevista. Una aplicación funcional resulta más creíble que una investigación etnográfica. Una vez que existe un prototipo, el anclaje cognitivo dificulta abandonarlo, incluso cuando la investigación con usuarios sugiere que el problema subyacente es distinto al que se había asumido. La IA amplifica este sesgo al permitir crear elementos pulidos sin apenas esfuerzo. Esta ilusión de progreso, oculta el hecho de que no se ha producido ningún aprendizaje real sobre las necesidades del cliente.
Inflación de funcionalidades. Cuando construir resulta casi gratuito, es más difícil mantener la contención. En lugar de preguntarse «¿Cuál es el experimento más sencillo posible?», los equipos se preguntan «¿Qué más podemos añadir?». Los equipos pasan horas ajustando la ubicación de los botones, las combinaciones de colores y los detalles del flujo de trabajo antes de confirmar si los usuarios realmente desean esa funcionalidad. Irónicamente, un desarrollo de bajo coste suele dar lugar a productos más complejos.
Pérdida de competencias en la fase de descubrimiento. Quizás el mayor riesgo a largo plazo sea lo que los economistas llaman deskilling (pérdida de cualificación): perder experiencia porque las herramientas realizan la tarea por nosotros. Preocupaciones similares están surgiendo en el ámbito del trabajo intelectual, donde la IA puede crear la ilusión de competencia al tiempo que debilita el criterio subyacente. Los product managers junior pueden llegar a ser expertos en redactar prompts antes de convertirse en observadores excepcionales. Sabrán cómo generar funcionalidades, pero no cómo identificar necesidades insatisfechas: son habilidades muy diferentes. Y si nuestra comprensión del problema es confusa, la IA generará un trabajo confuso mucho más rápido y con mejor formato.
Dejemos de tratar la IA como un atajo para obtener respuestas
Usémosla para mejorar la fase de descubrimiento.
El descubrimiento nunca ha consistido en generar artefactos como personas o árboles de oportunidades. Se trata de desarrollar empatía hacia clientes reales y reducir la incertidumbre mediante el aprendizaje continuo. La IA debería potenciar ese proceso, no reemplazarlo.
La IA puede acelerar drásticamente el descubrimiento de productos, pero solo si los equipos la utilizan para profundizar en su comprensión de los clientes, y no para fabricar una falsa sensación de certeza. El papel más valioso de la IA es actuar como un copiloto de investigación: ayudando a los equipos de producto a recopilar, estructurar, cuestionar y sintetizar evidencias basadas en el comportamiento real de los clientes, al tiempo que se preserva el criterio humano.
En el siguiente post hablaremos de cómo utilizar la IA para el descubrimiento de problemas.
El post “Vibe coding y el espejismo de la velocidad (2)” se publicó primero en “Marketing & Innovación”.
[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]
