Jev AI Demos: explora 6 demos interactivas del modelo Jev

Si buscas Jev AI demos o Jev model demos, la pregunta útil no es solo si Jev puede escoger una opción plausible. También importa saber qué estado recibió, qué alternativas tenía, qué respuesta devolvió y qué acción ejecutó realmente el software que lo rodea. Los seis escenarios de la página de demos de Jev están diseñados alrededor de esa inspección.

La colección incluye un sitio de vuelos que cambia tras cada paso, una carrera entre enlaces de una enciclopedia, un carrito de compra, el triaje de soporte, una revisión de cuentas por pagar y una alerta de seguridad. Los sitios, tickets, precios, facturas e incidentes son simulados. Las páginas describen decisiones de Jev en directo y permiten inspeccionar solicitudes y respuestas al iniciar un escenario con la sesión abierta. Resultan útiles para conocer la interfaz, pero una simulación bien presentada no demuestra que la misma política funcione igual de bien con tus propios datos.

Esta guía explica qué observar en cada demo, dónde se sitúa el límite de la decisión y cómo convertir una demostración en una evaluación pequeña y medible. Las descripciones corresponden a las páginas públicas consultadas el 27 de septiembre de 2026; no afirman que una ejecución concreta llegara a completarse con éxito.

Índice

• Respuesta rápida
• Qué tienen en común las seis demos
• Las seis demos del modelo Jev de un vistazo
• Demos de acciones en el navegador
• Triaje de soporte con tres juicios por ticket
• Revisión de facturas con pruebas antes de decidir
• Alerta de seguridad con pruebas antes de responder
• Cómo evaluar una ejecución de la demo
• De la simulación a un flujo de trabajo real
• Preguntas frecuentes

Respuesta rápida

Las demos muestran al modelo tomando decisiones delimitadas dentro de flujos de software. En los escenarios de navegador, la página cambia después de cada acción aprobada, por lo que Jev debe escoger entre los controles disponibles en ese momento. En los de soporte, finanzas y seguridad, juzga pruebas estructuradas que el código puede usar para asignar una ruta o pedir revisión. Las páginas ofrecen modo manual y automático con temporizador, muestran un panel de decisiones y requieren iniciar sesión para ejecutar el escenario. Empieza por el modo manual si quieres leer cada solicitud y respuesta antes de aprobar la siguiente acción.

Qué tienen en común las seis demos

El patrón recurrente es observar → decidir → revisar → actuar → volver a observar. Una interfaz simulada expone controles o registros. Una solicitud a Jev describe el estado actual y plantea una pregunta concreta. El panel de decisiones muestra solicitud, respuesta y acción posterior. El nuevo estado de la página alimenta el siguiente paso. La respuesta del modelo no pulsa por sí sola un botón, no emite un reembolso ni aísla un dispositivo: la aplicación decide si debe aplicarla y cómo.

Esa separación es la principal enseñanza de diseño. El modelo puede elegir el siguiente control o puntuar la gravedad de un ticket, mientras el código convencional sigue imponiendo permisos, umbrales y transiciones de estado. El límite resulta especialmente claro en las demos que especifican que no hay compra, pago, mensaje ni intervención de seguridad reales.

Los tipos de pregunta de Jev también explican por qué estos ejemplos son distintos de una transcripción de chat:

Tipo	Forma de la respuesta	Uso en una demo
Choice	Una opción predefinida, con probabilidades	Elegir una acción visible o una cola de soporte
Score	Posición en una escala ordenada, con distribución	Valorar gravedad del ticket o riesgo de la alerta
Noul	Probabilidad de que una proposición concreta sea verdadera	Decidir si una persona debe revisar el caso

La documentación oficial para desarrolladores indica que un estado puede incluir varias preguntas tipadas en una misma solicitud. También señala que las entradas admitidas actualmente son texto, objetos JSON y listas de texto; las entradas directas de imagen, audio y vídeo aún no están disponibles. En estas demos, la aplicación convierte la página o el registro en un estado que el modelo pueda evaluar. Que el visitante vea una interfaz parecida a un navegador no significa que el modelo esté viendo sus píxeles directamente.

Las seis demos del modelo Jev de un vistazo

Demo	Qué se le pide a Jev	Qué conviene inspeccionar	Límite importante
Búsqueda de vuelos	Elegir acciones en un formulario y resultados cambiantes	Controles actuales, objetivo elegido, nuevo estado	Vuelos y precios de ejemplo
Carrera de enlaces wiki	Escoger enlaces visibles para acercarse a un tema	Candidatos, camino recorrido, artículo siguiente	Enciclopedia ficticia; sin búsqueda ni URL directa
Triaje de soporte	Clasificar tema, puntuar gravedad y estimar revisión humana	Tres respuestas y regla de asignación	Sin reembolsos, respuestas ni cambios de cuenta
Carrito de compra	Buscar productos que cumplan condiciones exactas	Comparación, contenido del carrito, condición de parada	Sin compra real
Revisión de facturas	Consultar registros relacionados y elegir tratamiento	Pruebas consultadas antes de la decisión final	Registros ficticios; sin pagos
Alerta de seguridad	Revisar pruebas y juzgar autorización, riesgo y respuesta	Cobertura de pruebas y regla de respuesta	Incidente simulado; sin cambios en dispositivos

Son demostraciones de distintas formas de decisión, no una clasificación de rendimiento. Una acción de navegador puede ser correcta en un estado y equivocada después de que la página cambie. Una clasificación puede tener el tipo de salida correcto y aun así escoger la cola equivocada. Conviene separar ambos sentidos de «correcto» al observarlas.

Demos de acciones en el navegador

Tres escenarios hacen tangible el ciclo de observar, decidir y actuar. Cada uno parte de una tarea acotada y un sitio simulado. El modelo elige entre los controles o enlaces que expone la página actual. La aplicación aporta valores incluidos en la tarea y ejecuta acciones aprobadas. En cada paso, pregunta si la acción estaba disponible y si acercó el proceso a su objetivo.

Búsqueda de vuelos con un formulario que cambia

La demo de vuelos ofrece rutas como Zúrich–Londres y Singapur–Tokio. La tarea inicial consiste en encontrar un vuelo de ida de Zúrich a Londres el 20 de octubre de 2026 para un adulto en clase turista. La página simulada de AeroFinder comienza con controles de búsqueda y puede mostrar resultados después. La demo divide el proceso en leer página, elegir acción, revisar y ejecutar. Aclara que los valores de ciudad y fecha vienen de la tarea; Jev elige la acción y su objetivo.

No es lo mismo seleccionar el campo adecuado que inventar su valor. Una traza útil debería mostrar los controles numerados del estado actual, el elemento elegido por Jev, el valor procedente de la tarea y el estado siguiente. Si cambian el diseño o las opciones, la próxima decisión debe basarse en el nuevo estado, no en una secuencia fija de clics. Los precios de ejemplo no son tarifas aéreas actuales y no sirven para planificar un viaje.

Carrera wiki sin atajos

La carrera empieza en «Rubber duck» y pretende llegar a «Machine learning». Se prohíben la búsqueda y las URL directas. El artículo simulado de OpenAtlas presenta únicamente enlaces visibles en la página actual, y Jev debe escoger uno en cada salto. La página inicial ofrece, entre otros, «Rubber duck debugging», «Waterfowl» y «Toy», que abren distintos caminos dentro de la enciclopedia ficticia.

Es una prueba compacta de planificación con información local. En cada salto, comprueba si el enlace elegido era visible, si parecía relacionado con el destino y si el camino progresó. Un enlace prometedor también puede acabar en un callejón sin salida. El resultado depende tanto del juicio del modelo como del grafo de páginas de la simulación. El recorrido visible explica más que una simple etiqueta de «éxito».

Carrito con coincidencia exacta y regla de parada

La demo de compra pide exactamente una leche entera de 1 L, un paquete de doce huevos de gallinas camperas y un pan integral de 600 g por menos de cuatro dólares. Jev busca en la tienda simulada, compara productos parecidos y llena el carrito. La instrucción exige detenerse cuando la lista esté completa y no pasar por caja.

No basta con encontrar un artículo de nombre parecido. Importan tamaño, tipo, cantidad, precio y posibles duplicados en el carrito. Al revisar una ejecución, compara cada producto con todas las condiciones. Comprueba también que el sistema se detenga con los tres artículos requeridos y no inicie una compra no autorizada. Precios y existencias son datos de ejemplo; lo relevante es la traza de acciones y el contenido final del carrito.

Triaje de soporte con tres juicios por ticket

La demo de triaje de soporte usa tres tickets de ejemplo. Según la página, Jev devuelve en una sola solicitud tres juicios por ticket: Choice para el tipo de problema, Score para la gravedad y Noul para la probabilidad de revisión humana. Después de que el visitante examine las respuestas, el servicio simulado aplica una regla definida en código.

La regla publicada es concreta: gravedad crítica, probabilidad de revisión humana igual o superior al 50 %, o confianza en la clasificación del tema inferior al 55 % envían el ticket a una persona. Son umbrales de la demo, no cifras universales. El primer ticket trata sobre cobros duplicados reiterados y una consulta de facturación del mes anterior que quedó sin respuesta. Los otros se refieren a un error de la API en producción y a una pregunta normal sobre exportación. Las diferencias ayudan a ver si los tres juicios captan dimensiones separadas en lugar de aplastarlas en una etiqueta vaga.

Anota la categoría, la distribución completa de gravedad, la probabilidad de revisión y la rama que tomó el código. Si la cola final sorprende, determina si el problema vino de la respuesta del modelo o de la regla que la interpretó. La página aclara que no envía mensajes, no concede reembolsos y no modifica cuentas. La asignación de cola es el resultado simulado.

Revisión de facturas con pruebas antes de decidir

La demo de revisión de facturas ofrece tres casos: documentos coincidentes, una factura ya pagada y datos bancarios modificados. En el escritorio ficticio LedgerFlow, Jev puede consultar factura, orden de compra, registro de entrega, perfil del proveedor e historial de pagos antes de escoger el tratamiento. La factura inicial muestra proveedor, referencia de compra, concepto, total y cuenta de pago parcialmente oculta. También se ve cuántos de los cinco registros se han revisado.

Esto hace visible la cobertura de pruebas. Una decisión basada solo en la factura podría pasar por alto un pago duplicado o una cuenta modificada. Observa qué registro abre Jev después, qué dato nuevo obtiene y si la ruta final se justifica con el conjunto de pruebas. Los tres casos permiten comparar comportamientos: un caso coincidente podría continuar, uno ya pagado requiere atención al duplicado y un cambio de datos bancarios necesita otra vía de revisión. La demo usa registros ficticios y no realiza ningún pago; no demuestra la eficacia de controles de pago reales.

Alerta de seguridad con pruebas antes de responder

La demo de seguridad empieza con un acceso inusual a producción o con actividad de despliegue en staging. La tarea consiste en examinar una alerta y tres paneles de pruebas, y luego juzgar autorización, riesgo y próxima respuesta en una solicitud. Las alternativas incluyen cerrar la alerta, enviarla a un analista o contener el activo y avisar a la persona de guardia, siempre dentro de la consola simulada.

La pregunta central es si la respuesta es proporcional a las pruebas observadas. Un inicio de sesión administrativo desconocido seguido de un intento de acceder al almacén de credenciales de un servidor de producción no equivale a un despliegue esperado en staging. Comprueba qué pruebas se abrieron realmente, qué dicen las respuestas tipadas y qué regla permitió la reacción final. Una puntuación alta de riesgo es una señal para el código y los analistas, no una autorización para modificar un dispositivo de producción. La página indica que el incidente es ficticio: no se aísla ningún equipo ni se cierra una alerta real.

Cómo evaluar una ejecución de la demo

Empieza en modo manual. Las páginas también anuncian un modo automático con pasos cada tres segundos, pero el manual deja tiempo para leer la solicitud antes de la acción siguiente. Se necesita iniciar sesión para ejecutar los escenarios públicos. En cada paso, conserva cuatro observaciones: estado, opciones permitidas, respuesta de Jev y transición ejecutada. Una tarjeta de resultado sin ellas puede ocultar el origen de un error.

Usa esta lista en vez de fijarte solo en si el escenario acaba:

1. Fidelidad del estado: ¿Incluía la solicitud la información necesaria y solo hechos disponibles en ese momento?
2. Validez de la acción: ¿Se ofrecía realmente el control, enlace o tratamiento elegido?
3. Cumplimiento de condiciones: ¿Se respetaron fecha, cantidades, presupuesto y acciones prohibidas?
4. Cobertura de pruebas: ¿Se consultaron los registros relacionados antes de una decisión financiera o de seguridad?
5. Gestión de incertidumbre: ¿Cambiaron la ruta una confianza baja o una probabilidad alta de revisión, tal como dice la política?
6. Límite de ejecución: ¿Aplicó el código solo la acción aprobada e impidió compra, pago, reembolso o contención real?
7. Reproducibilidad: ¿Producen estados parecidos juicios parecidos, y se puede auditar una bifurcación distinta?

Una ejecución es un recorrido por el producto, no una estimación de precisión. Para evaluar tu flujo, reúne casos etiquetados, incluye situaciones ambiguas y adversarias, utiliza las mismas preguntas en todos y compara juicios con resultados. En Choice, mide precisión y confusiones entre categorías. En Score, examina errores entre niveles vecinos de gravedad. En Noul, agrupa las predicciones en bandas de probabilidad y compara la tasa predicha de revisión con la necesidad real. Mide también el porcentaje derivado a personas: un sistema aparentemente preciso puede conseguirlo enviando casi todo a revisión manual.

Mantén la política de decisión separada del modelo. El umbral del 50 % de la demo es fácil de entender, pero el adecuado para tu organización depende del coste de omitir una escalada frente al de revisar casos innecesarios. Fíjalo con un conjunto de evaluación reservado, documenta la compensación y revísalo cuando cambien el flujo o los clientes. Si faltan datos de origen, una regla determinista de «pruebas ausentes → revisión» puede activarse antes de consultar cualquier probabilidad.

De la simulación a un flujo de trabajo real

Trata las demos como patrones de referencia. Empieza con una decisión de producción estrecha, como asignar una cola de soporte o decidir si un documento necesita revisión. Escribe las respuestas admitidas, los campos de estado, la acción que puede desencadenar cada respuesta y la alternativa para la incertidumbre. Después consulta la documentación de la API de Jev para probar estado y preguntas tipadas con tus propios casos. Guarda credenciales en el servidor, valida respuestas y deja todos los efectos en manos del código de la aplicación.

Para un flujo de navegador, expón primero un pequeño conjunto verificado de controles disponibles. No permitas que el modelo invente selectores arbitrarios ni ejecute acciones invisibles. En finanzas y seguridad, separa la recopilación de pruebas de la decisión final y exige los registros obligatorios según tu política. En soporte, empieza por asignación o prioridades antes de conceder autoridad para contactar clientes o modificar cuentas.

Por último, registra una auditoría breve: versión de la pregunta, referencia del estado, opciones disponibles, respuesta y probabilidades, versión de la política, estado de aprobación y acción ejecutada. Así el equipo podrá explicar un resultado sorprendente y comparar cambios con el tiempo. Una demo ayuda a comprender las piezas; un despliegue exige una tasa de error medida, una política de revisión explícita y responsables operativos.

Preguntas frecuentes

¿Se pueden ver gratis las demos de Jev AI?

Las páginas públicas muestran la descripción de cada escenario y su estado inicial simulado sin ejecutarlo. Para la interacción aparece «Sign in to start». Consulta en el sitio las condiciones actuales de acceso y uso antes de dar por hecho un plan o cuota concretos.

¿Controlan sitios reales o efectúan transacciones?

No. Las páginas describen el sitio de vuelos, la enciclopedia, la tienda, el escritorio financiero y la consola de seguridad como simulaciones. No hay compra, pago, aislamiento de dispositivos ni mensaje a clientes reales. Muestran decisiones y transiciones controladas por la aplicación.

¿Lee Jev capturas de pantalla en estas demos?

La documentación actual de Jev enumera texto, objetos JSON y listas de texto como entradas de estado, y señala que todavía no admite imágenes. La interfaz puede enseñar una página visual a las personas mientras la aplicación pasa a Jev una representación textual o estructurada de controles y registros.

¿Qué demo del modelo Jev pruebo primero?

Prueba triaje de soporte si quieres entender Choice, Score y Noul juntos en una solicitud. Elige búsqueda de vuelos para observar decisiones repetidas mientras cambia la página. Usa revisión de facturas si te interesa comprobar si se reúnen pruebas suficientes antes de sugerir un tratamiento.

¿Qué demostraría que Jev sirve para mi caso?

Necesitas casos reservados de tu propio flujo, etiquetas humanas de referencia claras, una política documentada y mediciones de errores, calibración, volumen de revisión y acciones fallidas o bloqueadas. La traza de la demo explica el mecanismo; tu evaluación demuestra si satisface tus necesidades operativas.

Notas sobre las fuentes: los detalles de los escenarios se comprobaron en las páginas públicas de demos y documentación de Jev AI el 27 de septiembre de 2026. También se contrastó la interfaz con la guía oficial de inicio de TypeSafe AI. Jev AI declara que opera de forma independiente y no está afiliado a TypeSafe ni es operado o respaldado por ella. Verifica credenciales, endpoints y condiciones de cada proveedor antes de integrar sus servicios.