¿Deberías hacer tu propio agente de demos con IA con vibe coding?

¿Puedes hacer tu propio agente de demos con IA con vibe coding? Puedes montar uno que funcione en un fin de semana. Ponerlo delante de compradores reales, sobre tu producto real, todos los días, es otro proyecto. Y tu pipeline depende de ese segundo proyecto.

Esto es lo que implica ese segundo proyecto y lo difícil que es cada parte:

Aspecto	Qué exige	Dificultad
Manejar tu producto en vivo	Logins, códigos de autenticación, protección antibots y flujos que sobrevivan a los cambios de interfaz	Muy difícil
Latencia	Escuchar, pensar, hablar y hacer clic en un segundo, más o menos	Muy difícil
Tecnología de voz	Una voz natural, turnos de palabra, interrupciones, acentos y ruido	Difícil
Sandboxes	Datos de demo realistas que se reinician tras cada sesión y se mantienen al día con tu producto	Difícil
Prompting y guardrails	Ceñirse al mensaje y no inventarse nunca precios, funcionalidades ni afirmaciones de seguridad	Difícil
Evals	Puntuar conversaciones y detectar regresiones tras cada cambio de prompt o de modelo	Difícil
Traspaso al CRM y al pipeline	Captación y enriquecimiento de leads, sincronización con HubSpot o Salesforce y seguimiento	Media
Mantenimiento	Volver a revisar todo lo anterior con cada versión del producto y cada cambio de modelo	Nunca se acaba

Lo oímos mucho de los equipos que evalúan Karumi: «alguien del equipo podría hacer esto con vibe coding». El instinto tiene sentido. Los agentes de programación ya son muy buenos. Conecta un LLM a un navegador headless, añade una API de voz, apúntalo a tu aplicación y el domingo por la noche tendrás algo que habla y hace clic por tu producto.

También hemos visto cómo acaba. Los equipos que construyeron el suyo volvieron a nosotros cuando vieron lo difícil y caro que es poner en marcha el sistema y mantenerlo funcionando. Este artículo recoge con qué se encontraron después de que el prototipo funcionara.

¿Qué hace bien un agente de demos hecho con vibe coding?

El bucle básico es realmente fácil hoy en día. Un LLM puede leer una página, decidir dónde hacer clic y explicar lo que ve. Una API de voz puede hacerlo hablar. Un agente de programación te monta la estructura de todo en unas horas.

Eso basta para una demo interna. No basta para un comprador, porque a un prototipo le basta con funcionar una vez, para alguien que quiere que funcione.

	Prototipo de fin de semana	Agente ante compradores
Público	Tu equipo, aplaudiendo	Compradores escépticos que se van al primer fallo
Estado del producto	Una sesión iniciada en un portátil	Miles de sesiones, cada una con su propio login, sus datos y sus tiempos
Conversación	Preguntas del camino feliz	Precios, competidores, seguridad, «¿puede hacer X?»
Cuando falla	Unas risas	Una oportunidad perdida y una mala primera impresión
Vida útil	Una demo	Todos los días, en cada versión
Responsable	Quien lo montó el sábado	Necesita uno, de forma permanente

La distancia entre esas dos columnas es el verdadero proyecto. Y una demo es un sitio donde no te puedes permitir fallar en producción: cuando se rompe, se rompe delante del comprador al que más querías impresionar.

¿Qué tienes que dominar para tener uno en marcha?

Un agente de demos en producción no es una sola tecnología. Son al menos cuatro, y cada una es una especialidad en sí misma:

• Tecnología de voz. Voz a texto, texto a voz, turnos de palabra, interrupciones, acentos y ruido de fondo. Conseguir que una voz suene natural, y que sepa cuándo el comprador ha terminado de hablar, es una disciplina en sí misma.
• Sandboxes. Una copia de tu producto con datos realistas que se reinicia tras cada sesión, se mantiene al día con lo que lanzas y nunca expone a un cliente real.
• Prompting. Instrucciones que mantienen al agente en el mensaje, centrado en tu producto y dentro de tus guardrails a lo largo de miles de conversaciones que nunca ha visto.
• Evals. Una forma de puntuar conversaciones y detectar regresiones, para saber que un cambio de prompt o de modelo ha mejorado las cosas y no las ha empeorado.

Y luego está la latencia, que atraviesa las cuatro. En una conversación hablada, una pausa de más de un segundo, más o menos, parece un fallo, y el agente tiene que escuchar, pensar, hablar y hacer clic en un producto en vivo dentro de ese margen. Reducirla implica hacer streaming en cada etapa, elegir modelos tanto por velocidad como por calidad y precargar páginas antes de que el comprador las pida. Es crítica, y es una de las partes más difíciles de hacer bien.

¿Por qué lo difícil es manejar un producto en vivo?

Aquí se va la mayor parte de nuestro propio tiempo de ingeniería, no en el chat. Mostrar tu producto real, y no una grabación, significa resolver todo esto:

• Logins que se resisten. SSO, pantallas que piden primero el email, enlaces mágicos, códigos de autenticación y sesiones que caducan a mitad de la demo. El fallo a menudo parece un éxito: el agente cree que ha entrado mientras sigue en una página de login.
• Protección antibots. Cloudflare, Akamai y herramientas similares existen para bloquear navegadores automatizados. Lanza un script contra tu propia aplicación demasiadas veces y te pueden bloquear la cuenta de demo.
• Datos de demo seguros. Los compradores no deberían ver registros de clientes reales ni romper una cuenta compartida. Necesitas un sandbox que parezca real, se reinicie limpiamente y nunca toque producción.
• Una interfaz que no para de cambiar. Cada versión mueve botones y renombra páginas. Los clics programados a mano se rompen sin avisar, así que necesitas comprobaciones que detecten un flujo roto antes que el comprador.
• Velocidad. Una demo que espera ocho segundos en cada página parece rota. Precargar, cachear y sincronizar la narración con la carga de las páginas son, cada uno, un trabajo en sí mismo.
• Interrupciones. Los compradores reales interrumpen con un «espera, vuelve atrás». El agente tiene que parar, responder y retomar donde lo dejó.

Nada de esto aparece en el vídeo de un prototipo. Todo aparece delante de un comprador.

¿Qué hace falta para que la conversación sea fiable?

Un agente de demos habla en nombre de tu marca. Uno que se inventa cosas sobre tu producto, delante de un comprador, hace más daño que no tener agente. Mantenerlo fiable es un trabajo continuo:

• Respuestas fundamentadas. Debe responder a partir de tu documentación, tus casos de éxito y tu posicionamiento, y pasar la conversación a tu equipo en lugar de improvisar sobre precios o el roadmap.
• Guardrails. Las preguntas sobre competidores, descuentos, temas legales o afirmaciones de seguridad, y los intentos de hacerle jailbreak, necesitan un tratamiento deliberado.
• Voz natural. Baja latencia, interrupciones, silencios y una narración que vaya sincronizada con lo que hay en pantalla.
• Idiomas. Si vendes en más de un mercado, cada guion, flujo y respuesta tiene que funcionar en cada idioma.
• Revisión. Alguien tiene que leer conversaciones, puntuarlas y corregir las respuestas flojas cada semana. Si no, la calidad se degrada y nadie se da cuenta.
• Preguntas de seguridad. Tu equipo de seguridad preguntará adónde van las transcripciones y qué proveedores de modelos las ven. Necesitas las respuestas antes de que pregunten.

¿No es el agente todo el producto?

No. El valor de un agente de demos está en lo que hace por tu pipeline, y los bots hechos en casa suelen quedarse en la conversación. Ventas y marketing necesitan todo lo que la rodea:

• Puntos de entrada por campaña, para que LinkedIn, los eventos, tu web y el outbound tengan cada uno su propio enlace, saludo y flujo inicial, y puedas ver qué canal funciona.
• Captación y enriquecimiento de leads: quién es el visitante, de qué empresa y si encaja en tu ICP.
• Traspaso a tus herramientas: las sesiones cualificadas llegan a HubSpot o Salesforce con un resumen, se avisa al comercial adecuado y el seguimiento sale solo.
• Insights: las preguntas que más hacen los compradores, dónde abandonan y qué objeciones aparecen.
• Edición sin código, para que marketing y los preventas cambien guiones y flujos sin abrir un ticket.

Cada una de estas piezas es un pequeño producto en sí misma. Si las construyes internamente, tu bot de demos se convierte en una plataforma interna con su propio roadmap.

¿Cuánto cuesta de verdad construir el tuyo?

El vibe coding hace que la primera versión sea casi gratis. No hace gratis las cien versiones siguientes, y ahí es donde está el coste.

• Cada actualización del producto es una actualización de la demo. Cada versión puede mover un botón, renombrar una página o cambiar un flujo. Alguien tiene que volver a revisar los recorridos, refrescar el sandbox, actualizar los guiones y volver a pasar las evals, cada vez que lanzas.
• Alguien tiene que hacerse cargo. Cuando la persona que lo construyó vuelve al producto principal, o se va, el bot se rompe sin hacer ruido. El código generado que nadie entiende del todo es difícil de traspasar.
• La tecnología de base no para de moverse. Los proveedores de LLM, voz y automatización de navegadores cambian modelos, precios y APIs cada pocos meses. Cada cambio supone otra ronda de pruebas y, a menudo, reescribir código.
• Compite con tu roadmap. Cada semana de ingeniería dedicada al bot de demos es una semana que no dedicas al producto que de verdad vendes.
• Tiempo hasta obtener valor. Una versión interna que funciona suele estar a meses de ser segura para enseñársela a compradores. Mientras tanto, el pipeline que justificaba el proyecto espera.

Así que la comparación honesta no es una suscripción frente a un fin de semana programando. Es una suscripción frente a un equipo de ingeniería a tiempo parcial, de forma indefinida, más las oportunidades que pierdes mientras se construye.

¿Cuándo tiene sentido construirlo tú mismo?

Construirlo es la decisión correcta cuando se cumplen estas tres condiciones:

1. Un agente de demos con IA es parte central de lo que vendes, no un canal para vender otra cosa.
2. Puedes dedicarle un equipo de forma permanente, no durante un sprint.
3. Te parece bien esperar meses antes de que lo vean los compradores.

Si no, lo más útil que tu equipo puede hacer con vibe coding es un prototipo de lo que quiere. Pasa esa lista de deseos a una plataforma que ya resuelve logins, sandboxes, guardrails, voz, analítica y el traspaso al CRM, y dedica tu tiempo de ingeniería a tu propio producto.

Eso es lo que hace Karumi. El agente aprende tu producto explorándolo, lo maneja en vivo mientras habla con el comprador y envía cada sesión a tu CRM. La mayoría de los equipos están en marcha en dos semanas, y nosotros nos encargamos del mantenimiento.

Preguntas frecuentes

¿No podemos empezar con un prototipo y cambiar más adelante?

Se puede, y un prototipo es una buena forma de definir lo que quieres. Eso sí, presupuesta el cambio: el trabajo posterior al prototipo es donde está la mayor parte del coste, y los compradores que ven una demo rota no vuelven para echar un segundo vistazo.

¿Y si nuestro producto cambia cada semana?

Ese es el argumento más fuerte contra los flujos programados a mano. Karumi vuelve a aprender tu producto a medida que cambia, así que una página renombrada o un botón movido no tumban la demo.

¿Perdemos el control si no lo construimos nosotros?

No. Tu equipo escribe los guiones, elige los flujos y define los guardrails. Lo que delegas es la infraestructura: navegadores, logins, voz, sandboxes y las integraciones.

¿Cómo comparamos las dos opciones de forma justa?

Elige un flujo clave que les importe a tus compradores y prueba ambos durante una semana: tu prototipo y un agente de Karumi, con las mismas preguntas. Cuenta cuántas veces cada uno completa la demo sin un fallo.