TinyTroupe: 13 clientes simulados con IA que encontraron bugs reales

¿Por qué un test verde no te salva de errores de usabilidad?

Cristian Tala montó una batería de pruebas automatizadas con todos los checks en verde, desplegó el producto y luego creó 13 clientes simulados con inteligencia artificial. En una sola tarde, esos simuladores encontraron problemas que ningún script automático había detectado: un chatbot que proponía el producto equivocado, uno que repetía la misma respuesta cuatro turnos seguidos mientras el usuario escribía su correo electrónico, y otro que mostraba un catálogo desactualizado.

La conclusión es directa y útil para cualquier founder: un test verifica lo que ya sabías que había que verificar, pero no dice nada sobre lo que se te pasó por alto. Cuando construyes algo, conoces el nombre técnico de cada pieza — sabes qué es un «acuerdo de confidencialidad», qué flujo es el «onboarding» o qué hace cada botón. Tu cliente no. Si tu producto solo funciona cuando alguien escribe el término correcto, entonces funciona para quien ya sabe usarlo, que es justo quien menos ayuda necesita.

Los clientes simulados atacan ese punto ciego. Son perfiles definidos por un modelo de lenguaje con edad, ocupación, rasgos y situación concreta, que conversan directamente con tu producto real sin conocer la jerga interna del equipo.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

¿Qué encontraron los simuladores que los tests automáticos ignoraron?

Los hallazgos reportados siguen un patrón que se repite en cualquier producto digital:

Contradicción entre diagnóstico y solución. Un cliente simulado llegó con un caso claro. El chat le explicó correctamente 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.

Bucles invisibles para scripts. Después de arreglar un error donde el chat cerraba con un «te contacto» que no llevaba a ninguna parte, la misma persona recibió la respuesta correcta cuatro turnos seguidos de forma textual, mientras ella intentaba escribir sus datos en el chat. Nadie escribe un test para «no repitas lo mismo cuatro veces». Se ve leyendo la conversación.

Problemas conocidos que se redescubren solos. Una de las personas simuladas se topó con un desajuste de catálogo que ya estaba registrado en una nota interna días antes. No descubrió nada nuevo; descubrió algo que ya sabían y habían dejado pasar.

Funcionalidades no pedidas pero demandadas. En un segundo pase, en vez de pedir evaluación de pantallas, se les preguntó qué le pedirían al negocio que el flujo actual no permitía hacer. Cuatro perfiles distintos solicitaron la misma función. Eso no sale de un test determinista.

¿Qué es TinyTroupe y cómo se configura?

TinyTroupe es una librería open source de Microsoft diseñada específicamente para simular personas. Defines un TinyPerson con edad, ocupación, rasgos de personalidad y situación contextual, y esa persona conversa con tu producto o reacciona a una idea. Es la pieza que convierte un prompt genérico de «actúa como cliente» en algo con ficha, historia y comportamiento consistente entre turnos.

La segunda pieza es dónde piensa esa persona. Aquí hay buena noticia: sirve cualquier proveedor de modelos. OpenRouter, la API que ya pagas, o un modelo local corriendo en hardware propio. La configuración requiere dos variables de entorno porque el SDK de OpenAI las lee automáticamente:

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

El autor corre sus pruebas contra un modelo local (Qwen3.6 de 35B en un DGX Spark) por una razón práctica: ya tenía la máquina montada para otras tareas, así que cada corrida no tiene costo marginal. Pero eso es un tema de infraestructura, no de capacidad. Con un proveedor en la nube funciona igual de bien.

Y no necesitas el modelo más caro. Un cliente simulado no tiene que razonar como un doctorado; tiene que escribir como escribe alguien apurado que no conoce tu jerga. Cualquier modelo que rinda decente en benchmarks conversacionales cumple el trabajo.

¿Cuánto cuesta y qué rendimiento esperar?

Una corrida típica genera entre 30 y 60 turnos de conversación. El valor está en repetir: cambias una respuesta del producto, vuelves a correr, ves si el bucle desapareció o si lo cambiaste por otro. Si cada ejecución duele en la factura del proveedor, la haces una vez y guardas el script en un cajón.

Hay un detalle técnico importante: el modo de razonamiento activo puede ser contraproducente. En las mediciones del autor, cada turno tardaba 21 segundos con reasoning activado y muchas veces devolvía texto vacío porque el presupuesto de tokens se agotaba pensando y no quedaba nada para la respuesta. Lo desactivó y bajó a 0,8 segundos por turno, priorizando volumen de conversaciones sobre refinamiento de cada frase.

Un dato relevante: cuando midió el razonamiento forzado en su benchmark mensual, 8 de 9 modelos rindieron peor en tareas conversacionales de varios turnos. Esto sugiere que para validación de usabilidad, la velocidad importa más que la profundidad analítica de cada respuesta.

¿Qué significa esto para tu startup?

Lo que describe Tala es un fragmento de una tendencia más amplia. Las empresas están invirtiendo millones en infraestructura de pruebas con entornos simulados. Patronus AI levantó US$50 millones en Serie B en junio de 2026, liderada por Greenfield Partners con participación de Lightspeed Venture Partners, Notable Capital, Datadog y Samsung Ventures, específicamente para crear entornos simulados donde stress-testear agentes de IA antes de ponerlos en producción. Según Glenn Solomon, Managing Director de Notable Capital, la demanda por estos entornos simulados es «insaciable» y la empresa aumentó sus ingresos 15 veces en el último año.

Paralelamente, Synthesized anunció en agosto de 2026 su Test Data Agent, una capa de validación para agentes empresariales que genera datos y contextos realistas para probar agentes antes de desplegarlos en sistemas reales. Estas inversiones reflejan una convicción del mercado: los benchmarks estáticos ya no bastan.

Para founders hispanohablantes, esto tiene implicaciones concretas. En ecosistemas donde el acceso a usuarios beta puede ser limitado o costoso, tener un mecanismo para explorar fallos de usabilidad antes de mostrarle el producto a un cliente real representa una ventaja significativa. No se trata de reemplazar entrevistas con clientes, sino de eliminar el momento incómodo en que vas a mostrarle una pantalla sin haberla mirado con los ojos de nadie que no seas tú.

Dos acciones que puedes implementar este lunes

Elige un flujo por el que pase dinero — el que cotiza, el que cobra o el que entrega. Escribe tres perfiles sacados de tus tres últimos clientes reales, usando sus palabras exactas, no las tuyas. Que ninguno sepa el nombre técnico de lo que necesita. Pásales la URL real del producto, six turnos cada uno, y lee las tres conversaciones completas de principio a fin.
Convierte cada hallazgo en un test fijo el mismo día. Si un simulador encuentra algo, congélalo como guión en tu batería de pruebas automatizadas. Sin esa conversión, el hallazgo vuelve a desaparecer en la próxima iteración.

¿Cuáles son las reglas para que funcione y no sea teatro?

Saltarte estas condiciones convierte la herramienta en un generador de consejos genéricos con formato bonito:

Los perfiles salen de clientes reales, no de tu imaginación. Los míinos se armaron con tres cosas disponibles: clientes que efectivamente compraron, las conversaciones que tuvieron con ellos y los productos que adquirieron. 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. Si el flujo es web, congela el despliegue mientras recorren: si publicas cambios en el medio, cada perfil describe una versión distinta y no puedes cruzar datos.

Cita textual o no se reporta. Sin la frase exacta que prueba el hallazgo, un agente devuelve recomendaciones vagas como «mejorar la jerarquía visual». Eso es ruido con formato.

Ninguno sabe cómo se llama lo que necesita. Esta es la regla que más hallazgos produce. El cliente llega con un problema descrito en sus propias palabras, no con terminología técnica.

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.

¿Dónde falla este enfoque?

Hay límites claros que conviene reconocer:

Falsos positivos silenciosos. 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.

Antes de creer un hallazgo, abre la conversación y léela. Si la persona no habló, el fallo es tuyo, no del producto.

No reemplaza hablar con clientes de verdad. Lo que hace este enfoque es reemplazar 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ú. Es un filtro previo, no un sustituto.

Variabilidad inherente. El mismo código, el mismo despliegue, dos resultados distintos: la batería conversacional dio 33 de 33 dos veces y 31 de 33 un rato después sin cambiar nada. Casi diagnostica una regresión inexistente. De ahí la regla: un verde no es una garantía, es una corrida. Y una regresión se confirma repitiendo dos o tres veces, no con un solo punto de datos.