Clientes simulados con IA: encontraron lo que mis tests no

Tenía la batería de tests en verde y todo desplegado. Monté 13 clientes simulados con IA, les di la URL real y en una tarde encontraron cosas que ningún test iba a encontrar: el chat proponía el producto equivocado, repetía la misma respuesta cuatro turnos seguidos mientras la persona escribía su correo, y ofrecía un catálogo desactualizado. Los tests dicen si el sistema hace lo que el código dice. No dicen si una persona entiende lo que está mirando.

Por qué un test verde no te salva

Un test verifica lo que ya sabías que había que verificar. Escribiste la aserción, así que el agujero que te preocupa está cubierto. El problema es el otro: lo que no se te ocurrió.

Y ahí no hay malicia ni descuido. Cuando construyes algo, sabes cómo se llama cada pieza. Sabes que eso es un “acuerdo de confidencialidad”, que ese flujo se llama “onboarding”, que ese botón hace lo que hace. Tu cliente no. Tu cliente llega con un problema descrito en sus palabras y con una urgencia, y si tu producto solo funciona cuando alguien escribe el nombre técnico correcto, entonces funciona para quien ya sabe. Que es justo quien menos ayuda necesita.

Los clientes simulados atacan ese punto ciego. Son personas definidas con un LLM (edad, ocupación, rasgos, situación, problema concreto) que conversan con tu producto real o recorren tu flujo real, sin saber cómo se llaman las cosas.

Qué encontraron que yo no veía

Los números son míos y no vienen al caso. El tipo de hallazgo sí, porque se repite en cualquier producto:

Decía una cosa y proponía otra. Una persona llegó con un caso claro. El chat le explicó bien cuál era el problema y acto seguido le propuso resolverlo con el producto equivocado. Un test que verifica “responde y ofrece algo” pasa en verde. La conversación completa muestra la contradicción.

Arreglé un bucle y creé otro. En la primera corrida el chat cerraba con un “te contacto” que no llevaba a ninguna parte. Lo arreglé. En la segunda corrida, la misma persona recibió la respuesta correcta cuatro turnos seguidos, textual, mientras ella escribía sus datos en el chat:

Señor, ya les di nombre y correo arriba. Por favor, no me hagan repetir.

Nadie escribe un test para “no repitas lo mismo cuatro veces”. Se ve leyendo la conversación.

Un problema que ya estaba anotado y sin arreglar. Una de las personas simuladas se topó sola con un desajuste de catálogo que ya estaba registrado en una nota interna días antes. Nadie le contó nada; lo encontró conversando. No descubrió nada nuevo. Descubrió algo que ya sabíamos y habíamos dejado pasar.

Y el hallazgo que no salió de criticar. Después de la primera pasada hice un segundo pase distinto: en vez de pedirles que evaluaran la pantalla, les pedí que dijeran qué le pedirían al negocio que el flujo no permite hacer. Ahí salió una función que los cuatro querían y que el flujo no permitía. Ese pase me rindió tanto como el primero.

Esto no es un test, y confundirlo sale caro

Es lo que más me costó entender.

El mismo código, el mismo despliegue, dos resultados distintos: mi batería conversacional dio 33 de 33 dos veces, y 31 de 33 un rato después. No cambié nada. Casi diagnostico una regresión inexistente en mi propio cambio; lo pillé corriendo lo mismo contra el despliegue anterior, que también falló.

De ahí salen tres reglas que uso hoy:

• Un verde no es una garantía, es una corrida. Si vas a afirmar “quedó verde”, di contra qué corrida y cuándo.
• Una regresión se confirma repitiendo dos o tres veces, o comparando contra el despliegue anterior. Diferencias de una o dos comprobaciones son ruido del modelo, no señal.
• Un simulador con un LLM adentro nunca puede ser el semáforo. Cambiaría de color sin que cambie el código, y un rojo que aparece solo le enseña al equipo a ignorar los rojos.

El simulador explora. Corre fuera del build, a mano, cuando quieres buscar agujeros. Y lo que encuentra se congela como guión fijo en la batería de siempre, que sí es determinista y sí decide si algo sale a producción. Son dos herramientas distintas y hacen falta las dos.

Cómo se monta: TinyTroupe y el modelo que ya estés usando

TinyTroupe es una librería open source de Microsoft para simular personas. Defines un TinyPerson con edad, ocupación, rasgos y situación, y esa persona habla. Es la pieza que convierte “un prompt que actúa de cliente” en algo con ficha, historia y comportamiento consistente entre turnos.

La otra pieza es dónde piensa esa gente, y acá quiero ser claro para que nadie crea que necesita comprar hardware: sirve cualquier proveedor. OpenRouter, la API que ya pagas, lo que tengas. Se configura con dos variables de entorno, porque el SDK de OpenAI las lee del entorno:

OPENAI_BASE_URL=<el endpoint de tu proveedor>
OPENAI_API_KEY=<tu llave>

Yo las corro contra un modelo local (Qwen3.6 de 35B en un DGX Spark) por una razón simple: ya tenía montada esa máquina para otras cosas, y así una corrida no me cuesta nada. Es el mismo argumento de siempre a favor de las herramientas de IA self-hosted: cuando el uso es intensivo y repetido, tener el modelo en casa cambia lo que te atreves a probar. Eso importa porque una corrida son entre 30 y 60 turnos de conversación, y el valor está en repetirla muchas veces: cambias una respuesta del producto, vuelves a correr, ves si el bucle desapareció o si lo cambiaste por otro. Si cada corrida te duele en la tarjeta, la haces una vez y guardas el script en un cajón. Pero eso es un tema de costo, no de capacidad: con un proveedor en la nube funciona igual de bien.

Y no hace falta el modelo más caro. Una persona simulada no tiene que razonar como un doctorado: tiene que escribir como escribe alguien apurado que no conoce tu jerga. Cualquiera de los que rinden decente en el benchmark de modelos que corro todos los meses hace este trabajo, igual que me pasó cambiando el cerebro de mi coding agent a modelos open source.

Ahí hay algo que se me ocurrió después y que solo puedes hacer si las personas no comparten cerebro: darle un modelo distinto a cada perfil. Un gateway que enrute a varios proveedores lo hace trivial. No lo he probado a fondo todavía, pero tiene sentido: trece personas pensando todas con el mismo modelo escriben más parecido entre sí de lo que escriben trece clientes reales, y esa diferencia de estilos es justo lo que quieres simular.

Lo que no es negociable: el producto del otro lado tiene que ser el real. No estás simulando tu producto, lo estás probando. Si simulas los dos lados, estás viendo una obra de teatro.

Dos cosas prácticas antes de que te tropieces

El razonamiento no molesta; el presupuesto de tokens sí. Con el modo de razonamiento activo cada turno me tardaba 21 segundos y muchas veces devolvía texto vacío. La causa no era pensar: era que el presupuesto de tokens se agotaba pensando y no quedaba nada para la respuesta. Yo lo apagué (0,8 segundos por turno) porque quería iterar rápido y me importaba más el volumen de conversaciones que el refinamiento de cada frase. Si prefieres el camino contrario, súbele el máximo de tokens y déjalo razonar, que es lo correcto si te importa más la calidad de cada respuesta que el volumen. Un aviso antes de darlo por hecho: cuando medí el razonamiento forzado en mi benchmark, 8 de 9 modelos rindieron peor en tareas conversacionales de varios turnos, que es exactamente la forma que tiene esto. No lo probé con clientes simulados, así que no sé cuál de los dos gana acá. Si lo dejas activado, compara contra una corrida sin él en vez de asumir que mejoró. Si decides apagarlo, ojo con esto: se hace pasando extra_body: {chat_template_kwargs: {enable_thinking: false}} y hay que aplicarlo tanto a Completions.create como a Completions.parse, porque TinyTroupe usa la segunda para salida estructurada, que es casi siempre. Escribirlo en el prompt no funciona.

Tu propio CDN puede bloquear a tus clientes simulados. Cloudflare me devolvía 403 al primer mensaje porque el script no mandaba un User-Agent de navegador. Casi me paso la tarde probando mi bloqueo de bots en vez del producto, y el reporte habría dicho, con toda seriedad, que el chat no responde. Vale para cualquier herramienta que le pegue a tu sitio desde fuera del navegador.

Las reglas que hacen que sirva (y sin las cuales es teatro)

Sáltate estas y tienes un generador de consejos genéricos con formato bonito.

Los perfiles salen de clientes reales, no de tu imaginación. Los míos los armé con tres cosas que ya tenía guardadas: clientes que efectivamente me compraron, las conversaciones que tuve con ellos y los productos que terminaron adquiriendo. Nada inventado. Un cliente ideal inventado produce feedback inventado, y eso es peor que no tener nada, porque suena a validación.

Que recorran el flujo vivo. Si le cuentas a un agente cómo es tu pantalla y le pides opinión, opina sobre tu cuento. Hay que pasarle la URL real y que la traiga. Y si el flujo es web, congela el despliegue mientras recorren: si publicas en el medio, cada uno describe una versión distinta y ya no puedes cruzar nada.

Cita textual o no se reporta. Sin la frase exacta que lo prueba, un agente devuelve “mejorar la jerarquía visual” y cosas así. Eso es ruido con formato.

Ninguno sabe cómo se llama lo que necesita. Ya lo dije arriba, pero es la regla que más hallazgos produce.

Lánzalos en paralelo y busca el cruce. Lo que reportan dos perfiles distintos es un problema del producto. Lo que reporta uno solo es una característica de ese perfil. Sin esa distinción terminas arreglando cosas que solo le pasan a una persona que no existe.

Versiona todo: fichas, bitácora y conversaciones. Las conversaciones se guardan en el repositorio porque son la evidencia de por qué cambiaste algo. En un archivo temporal se borran y con ellas se va el motivo. Además, una persona que nunca encuentra nada es una persona que hay que cambiar, y eso solo se ve con historial.

Vale la pena separar dos cosas que se confunden: el segmento de cliente es el grupo; la persona es alguien concreto de ese grupo. Dos fundadores levantando capital no escriben igual, y ahí está la gracia. Varias personas pueden compartir segmento.

Dónde falla, dicho de frente

Dos personas simuladas se quedaron sin escribir una sola palabra, y el resumen automático de la corrida lo reportó como “el chat no respondió nada”. Un simulador que le anota al producto un fallo propio es peor que no tenerlo: te manda a arreglar algo que funciona.

Así que antes de creerle a un hallazgo, abre la conversación y léela. Si la persona no habló, el fallo es tuyo, no del producto. Y si la corrida completa se ve rara, córrela de nuevo antes de tocar código.

Y tiene un techo: esto no reemplaza hablar con clientes de verdad. Reemplaza el momento en que ibas a mostrarle una pantalla a un cliente real sin haberla mirado con los ojos de nadie que no seas tú.

Qué hacer el lunes

Elige un flujo por el que pase dinero: el que cotiza, el que cobra, el que entrega. Escribe tres personas sacadas de tus tres últimos clientes reales, con sus palabras, no con las tuyas. Que ninguna sepa el nombre técnico de lo que necesita. Pásales la URL real, seis turnos cada una, y lee las tres conversaciones completas de principio a fin.

Vas a encontrar algo. Y lo que encuentres, conviértelo en un test fijo el mismo día, porque si no, vuelve.

Si te quedas con ganas de más, el paso siguiente es montar esto sobre un framework de agentes y dejarlo corriendo solo. Pero eso viene después. Primero lee las tres conversaciones.