Qué es Jev y cómo aplicarlo: el modelo de juicio de TypeSafe

Jev es el modelo de juicio de TypeSafe, lo que la compañía llama su modelo System One: una IA que no genera texto, sino que responde preguntas cerradas y devuelve probabilidades. Existe para resolver la pregunta que aparece en casi todos los proyectos de IA que se atascan y casi nunca se formula en voz alta: quién decide. No quién escribe el prompt ni quién elige el modelo. Quién decide si este ticket escala, si esta factura pasa, si esta solicitud sigue.

Durante tres años la respuesta por defecto ha sido pedirle a un modelo generativo que devuelva un JSON con la decisión dentro y confiar en que el formato aguante. Suele aguantar. Lo que no aguanta es la auditoría.

Jev es la propuesta contraria, y el nombre no es decorativo: System One remite al pensamiento rápido, esa respuesta que una persona con criterio da en un segundo sin necesidad de deliberar. En vez de prosa, devuelve una distribución de probabilidad sobre las opciones que tú definiste de antemano. La versión vigente es jev-1.13 y la documentación de primitivas es la fuente de todo lo que sigue.

Tres formas de respuesta, y ninguna más

Esa es toda la superficie del modelo. La brevedad es deliberada.

• Choice: la respuesta es una de un conjunto conocido y sin orden interno, como la categoría de un ticket. El código actúa con una rama por opción.
• Score: la respuesta es una posición en un espectro que puedes describir por niveles, como la gravedad de una incidencia. El código actúa con un umbral, un orden o un peso.
• Noul: la respuesta es un sí o un no limpio y lo que interesa es la probabilidad, no la etiqueta. El código actúa con un if.

Las tres devuelven siempre algo que tu código consume sin tener que interpretar prosa, que es la propiedad que de verdad importa aquí, porque elimina de un plumazo toda la capa defensiva de lectura, reintentos y validación de formato que acompaña a cualquier integración seria con un modelo generativo. Un Choice devuelve la opción elegida, las probabilidades de todas y una confianza. Un Score devuelve la media ponderada de los niveles. Un Noul devuelve un número entre cero y uno.

La regla de diseño que ordena todo lo demás cabe en una frase: una buena pregunta para Jev es una que una persona con conocimiento respondería en un segundo si tuviera delante el contexto adecuado. ¿Transmite urgencia este mensaje? Vale. Analiza este mensaje y decide qué hacer, no vale. Eso segundo no es una pregunta. Es un encargo, y hay que partirlo en preguntas pequeñas y recomponer las respuestas en código.

La diferencia con pedirle la decisión a un LLM

Está en dónde vive la política. Suena a matiz de arquitectura. Es lo que decide si el sistema se puede auditar seis meses después.

Cuando le pides a un modelo generativo que clasifique y decida, la regla de negocio acaba escrita dentro del prompt, mezclada con la instrucción, el formato de salida y las excepciones que se fueron añadiendo con el tiempo. Cambiar un umbral significa entonces reescribir un párrafo en prosa y volver a evaluarlo todo desde cero, sin ninguna garantía de que el cambio no haya movido de paso el comportamiento de otros tres casos que nadie estaba mirando, y el resultado es que nadie sabe con seguridad qué hace el sistema, porque el sistema es un texto.

El reparto de Jev es explícito: el modelo aporta el juicio, el código se queda el control de flujo, la aritmética y la política. Los pesos y los umbrales viven en el código. La documentación insiste en un punto que conviene subrayar porque contradice el instinto de casi todo el mundo: cuando la decisión final es incorrecta pero cada respuesta individual es correcta, lo que está mal es la política, así que se cambian los pesos y se dejan las preguntas en paz.

Hay un segundo contraste, menos filosófico y más operativo. Jev no cuenta. Tampoco suma, ni compara fechas. La documentación lo dice sin rodeos y ofrece el patrón de sustitución: para contar elementos se lanza un Noul por elemento en la misma petición y se suman en código las respuestas que superan el umbral. Quien haya visto a un modelo generativo fallar un recuento de siete líneas reconocerá el problema al instante.

Cuatro patrones que cubren casi todo

El primero es el abanico especulativo. Todas las preguntas que comparten el mismo estado viajan en una sola petición, incluidas las que solo importan en algunas ramas. Se responden en paralelo, así que preguntar de más añade muy poca latencia y muy pocos tokens al coste total de la petición, y el código sencillamente ignora las respuestas que en esa rama concreta no necesita. Una segunda petición solo se justifica cuando la respuesta de la primera determina qué datos hay que ir a buscar.

El segundo es el enrutado por confianza, y es el que más se parece a dirigir un equipo. La respuesta dice qué. La confianza dice si actuar.

Esos valores son los que maneja la documentación de confianza como punto de partida, con el encargo explícito de empezar conservador y ajustarlos contra tus propios datos.

El tercero es el scoring compuesto. Un juicio complejo, de esos que en una reunión se resuelven diciendo que depende, se parte en un Score por cada dimensión que de verdad pesa en la decisión, cada uno se normaliza por su número de niveles y luego se combinan con los pesos que tú fijas en el código. Cuando cambian las prioridades del negocio, se toca un peso. No se reescribe una pregunta.

El cuarto es el recorrido de taxonomía: un Choice por cada nivel del árbol, recorrido en código, dando a cada opción como criterio lo que cuelga de ella para que el modelo vea qué hay debajo de cada rama antes de elegirla, y siguiendo más de una rama a la vez cuando las probabilidades salen parecidas.

De dónde sale ese estado es una decisión aparte, y hay equipos que la resuelven con Model Context Protocol por delante, para que el contexto llegue ya filtrado desde los sistemas que lo tienen.

Conviene decir también qué no arregla ninguno de los cuatro. Si la precisión cae cuando crecen los datos de entrada, el problema es que el estado lleva detalle irrelevante y hay que filtrarlo antes en código. Si una pregunta reformulada cambia un error por otro, esa pregunta está pesando dos propiedades a la vez y hay que partirla. Y el estado no se trata como hostil por defecto: el texto que le mandas puede orientar la respuesta, así que los casos adversos se prueban antes de desplegar.

Qué cambia para el talento tech que colabora por proyectos

Aparece una capacidad nueva, y no es saber usar una herramienta. Esa distinción separa a quien cobra por horas de quien cobra por criterio.

Diseñar un programa de Jev son cinco pasos, y ninguno se resuelve escribiendo prompts más largos:

1. Enumerar las decisiones que el sistema tiene que tomar, cada una como rama, umbral u orden.
2. Escribir una pregunta atómica por juicio, y partir cualquiera que pese dos propiedades.
3. Elegir la primitiva según lo que el código vaya a hacer con la respuesta.
4. Construir el estado mínimo que responde a todas, calculando en código lo que el código pueda calcular.
5. Componer las respuestas en código: ramas, pesos y puertas de confianza.

Eso es análisis de decisión y diseño de sistema. Es un músculo de ingeniería, no de redacción, y es continuidad directa de lo que ya exige montar un agente de IA de principio a fin: la diferencia es que aquí la parte de juicio deja de estar escondida dentro de un prompt y pasa a ser una pieza que se puede enseñar, medir y defender.

La parte que más se subestima es la evaluación. La documentación es tajante: se revisan una o dos preguntas por iteración, nunca más, porque las probabilidades se mueven de forma difícil de anticipar, y ninguna revisión se da por buena sin datos etiquetados detrás. Una confianza más alta, por sí sola, no demuestra que la pregunta haya mejorado. Quien sepa montar ese banco de pruebas, elegir los casos que de verdad discriminan y defender los resultados delante de un comité que pregunta por el riesgo antes que por la tecnología, tiene un argumento comercial que casi nadie puede sostener todavía con evidencia encima de la mesa.

El mercado español da una pista de por dónde va esto, aunque todavía no nombre a Jev. Según el análisis de mercado de Shakers, 881 de 27.814 ofertas tech con skills etiquetadas en España nombran LangChain, frente a 9.704 que nombran Python (n=33.139 ofertas activas, 27.814 con skills etiquetadas, de junio a septiembre de 2026). La orquestación de modelos ya tiene demanda declarada y nombre propio dentro del texto de las ofertas, que es el primer sitio donde una capacidad nueva se vuelve visible antes de que nadie le ponga etiqueta formal en un catálogo de roles. La capa de juicio dentro de esa orquestación es la pieza que todavía no tiene etiqueta.

Ese número mide menciones en el texto de las ofertas, no requisitos contrastados uno a uno. Y el denominador honesto es el de las ofertas con skills etiquetadas, no el corpus entero, porque el resto no tiene skills asignadas y contarlo inflaría el porcentaje.

Qué cambia para una empresa

La pregunta de comité deja de ser cuál es el mejor modelo. Pasa a ser otra: qué decisiones estamos delegando, y con qué umbral. Eso es gobierno, no compras, y es la conversación que falta en la mayoría de los despliegues de agentes de IA en empresas.

Tres consecuencias prácticas. La política se vuelve legible, porque los umbrales están en el código y versionados como cualquier otra decisión de ingeniería, de modo que se puede responder con exactitud, y con el historial delante, a qué se automatizó, bajo qué condición y desde qué fecha exacta. Aparece un camino de salida diseñado y no improvisado, porque el enrutado por confianza obliga a definir desde el principio qué ocurre cuando el modelo no está seguro, que es justo el escenario que las demostraciones nunca enseñan. Y baja el coste de cambiar de opinión: si mañana el negocio decide que la gravedad pesa más que la urgencia, eso es un peso en una línea de código.

Merece la pena situar esto en el problema de fondo. El estudio de BCG sobre más de 1.250 empresas cifra el hueco con crudeza: solo el 5% obtiene valor a escala y el 60% no obtiene valor material pese a una inversión sustancial (BCG, septiembre de 2025). Buena parte de ese implementation gap no es un problema de modelo. Es que nadie definió qué decisión se estaba automatizando, ni con qué confianza mínima, ni quién responde cuando la respuesta es dudosa.

Un modelo de juicio no resuelve eso por sí solo. Obliga a escribirlo, que es bastante más de lo que consigue la mayoría de las herramientas, y el patrón se repite en cualquier sistema que llega a producción de verdad: lo mismo pasa al llevar una arquitectura RAG a producción, donde la recuperación rara vez es el cuello de botella y lo que falla es no haber decidido qué se hace con lo recuperado.

Los límites, antes de que los descubras en producción

• No genera texto. Si necesitas una respuesta redactada, eso es otro modelo. Jev va delante para decidir cuál, o detrás para verificar lo que salió.
• No razona en pasos. Un problema que exige encadenar tres inferencias se parte en tres preguntas literales y se une en código.
• No hace aritmética, recuentos ni comparación de fechas. Para fechas, el patrón documentado es extraer cada parte con un Choice sobre opciones enumeradas, incluida una para el caso de que no conste, y ensamblar y comparar en código.
• Su escala no es una magnitud continua. Un Score de 1,0 puede significar certeza en el nivel 1 o un empate entre los niveles 0 y 2, así que hay que leer las probabilidades junto al número y usar el resultado para aplicar un umbral o para ordenar, nunca para deducir una cantidad.
• El contexto tiene tope. El estado y todas las preguntas comparten 64.000 tokens, y el estado más la pregunta más larga tienen que caber en 32.000.

Todo esto está descrito para jev-1.13. La propia documentación avisa de que varios de estos límites cambiarán en versiones posteriores, así que la página de irregularidades del modelo se vuelve a leer cada vez que cambie la versión. No una sola vez al empezar.

Por dónde empezar esta semana

Coge una decisión que hoy tome una persona de forma repetitiva, muchas veces al día y casi siempre igual, y cuyo criterio sepas describir en una sola frase sin tener que recurrir a un diagrama ni a una excepción que solo conoce quien lleva cinco años en el equipo. Ponla por escrito como pregunta cerrada. Elige la primitiva según lo que tu código vaya a hacer con la respuesta, que es el criterio de selección y no la elegancia del formato. Junta treinta casos ya resueltos con su respuesta correcta, pásalos y mira las probabilidades de los fallos.

Si el modelo falla con confianza alta, casi siempre es que leyó tu instrucción de forma estrictamente literal, atendiendo a cada palabra que pusiste y a ninguna de las que diste por supuestas, mientras tú querías decir algo ligeramente distinto que nunca llegaste a escribir. La explicación que darías al ver ese error es, literalmente, la mitad que faltaba de la instrucción. Ponla dentro.

Preguntas frecuentes sobre Jev

¿Jev sustituye a un LLM generativo?

No. Cubre una función distinta: decidir entre opciones que tú defines, no producir texto. Lo habitual es combinarlos, con Jev clasificando y decidiendo la ruta por delante, y un modelo generativo redactando por detrás cuando hace falta redactar.

¿Qué es un Noul?

Una de las tres primitivas de respuesta de Jev. Devuelve un número entre 0 y 1 para una condición que admite un sí o un no limpio, y la señal está en la propia probabilidad. Un 0,5 significa que el modelo no está seguro, no que la respuesta sea intermedia. Para medir un grado se usa un Score.

¿Se puede auditar una decisión tomada con Jev?

Más que una tomada dentro de un prompt. Las preguntas, los criterios de cada opción, los umbrales y los pesos son artefactos de código versionados, y cada respuesta trae su distribución de probabilidad completa.

¿Cuántas preguntas conviene mandar juntas?

Todas las que compartan el mismo estado, en una sola petición, incluidas las que solo se usan en algunas ramas. Se responden en paralelo, así que preguntar de más añade poca latencia y pocos tokens.

¿Hay demanda de esto en el mercado español?

De la capa de orquestación, sí y con nombre propio: 881 de 27.814 ofertas tech con skills etiquetadas nombran LangChain, según el análisis de mercado de Shakers (n=33.139 activas, de junio a septiembre de 2026). De Jev en concreto, todavía no: es un modelo reciente y ninguna oferta lo nombra.